From pkern@spike.0x539.de Thu Nov 1 02:10:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B82F21F8549 for ; Thu, 1 Nov 2012 02:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svzXLvMWN5O2 for ; Thu, 1 Nov 2012 02:10:01 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id EDEBA21F8543 for ; Thu, 1 Nov 2012 02:10:00 -0700 (PDT) Received: from [2001:470:720c:0:5d87:dcc4:f187:37f2] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1TTqmh-0007zy-Rp; Thu, 01 Nov 2012 10:09:56 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1TTqmg-0006IT-M4; Thu, 01 Nov 2012 10:09:54 +0100 Date: Thu, 1 Nov 2012 10:09:54 +0100 From: Philipp Kern To: Lorenzo Colitti Message-ID: <20121101090954.GA23956@spike.0x539.de> References: <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 09:10:01 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 01, 2012 at 09:35:07AM +0900, Lorenzo Colitti wrote: > Operators who want to have their routers do things like: [=E2=80=A6] > - Stateless ACL processing for security purposes [=E2=80=A6] > configure their routers to look at upper-layer headers. If the routers > cannot parse the extension header chain but only look at the next header > value in the IPv6 header, then the operators have a choice: >=20 > 1. Give up the above functionality. > 2. Drop all packets with extension headers. >=20 > It's not just the fragment header, it's all extension headers. The fragme= nt > header is just the most important one. Isn't the point that another packet will arrive later that doesn't bear the information anymore that's needed to do the filtering decision? Hence the fragmentation being the only concept that pushes information away from a per-packet point of view to one where you'd require state? (Also: To say that it wasn't forseen what would be possible in hardware today a decade ago and then argue based on the current state of technology to remove a feature does sound a tad wrong to me. Hardware does evolve.) Kind regards Philipp Kern --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQkjxiAAoJEERuJUU10FbslygIAMTR+XCh6X0OyxW46jRcPABu GxyiQPNEbz9YQzeRrgvR0x9rpU1K/yQauTdVEKNu7CygeemC2dMbL9E3nBNUKpkj 3HM3ZIkEmZKCiMq94LngvXrYd5gTb+qabZieCEjJ50BEf067vfMlbvr5JI1Ta/fo gVOMcKxJOGtAr/nUwEZgD2qoCrh7Oc6SkTiGBwwXZ4yfHuTBG8rQ39zrZOydNMDT srx3/7MduLFUjCu2owx+4g+fjx2wypIGAQtA90q2JhvYQ+FKb538d3qF3w7glNSi o14/SF/N0055vfzvWHQ4m1Bt2zu2vlNWRlDJhgIxbxqhIy6zyYKzm+NdsEK3LYM= =1IaC -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From brian.e.carpenter@gmail.com Thu Nov 1 02:35:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637A021F8509 for ; Thu, 1 Nov 2012 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phYc3O1webKx for ; Thu, 1 Nov 2012 02:35:24 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51A21F84FE for ; Thu, 1 Nov 2012 02:35:24 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so155951wib.1 for ; Thu, 01 Nov 2012 02:35:23 -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=fWbue+rGYOYKgr/uG7qOGdnyhwDUKMz//Yx1QFq16jk=; b=tA/e3lzT/WNGPvCrUfnIlOVSJKoN3M8gd3dVt8dbcikp7F0ovFXDWmT6eShU16qgPy MpUPGktUQ5IkZ06558IvgKgCO0ohcIMm3Ptpq9KqGfbX/9KdLxMKbg0r+yn6TVXXe/+0 JLGMmZIoGlghc7A+FsqLLldQ+1IBtj4SlvB+hFysk6CaAHYPP/uMpqnQFCV7KaHpjcXD M3Uvvk6MkKVvSn8CIU6sDZ4M4kkoLsAWGXEMXT7antdsUvLziREYlfWY1w8+mDxgbdeE JZjxY8F3LhqYfB1GIEwoNLHWXQmPeqHi87KCl21Ipw5ZgxykAFEGNr93+O9kVF01h2ZJ wCNA== Received: by 10.180.82.72 with SMTP id g8mr962794wiy.20.1351762523574; Thu, 01 Nov 2012 02:35:23 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-140.as13285.net. [2.102.216.140]) by mx.google.com with ESMTPS id dt9sm21226261wib.1.2012.11.01.02.35.20 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 02:35:21 -0700 (PDT) Message-ID: <50924264.7040300@gmail.com> Date: Thu, 01 Nov 2012 09:35:32 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> In-Reply-To: <509174F1.8080809@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 09:35:25 -0000 On 31/10/2012 18:58, Joe Touch wrote: > > > On 10/31/2012 11:34 AM, Fernando Gont wrote: >> On 10/31/2012 04:11 PM, Joe Touch wrote: >>> Yes, but the whole point of the IPv6 option architecture was to avoid >>> the issues seen with IPv4 options. >> >> The only thing in that IPv6 would avoid is requiring routers to parse >> *all* options, just to find the ones that need to be processed by >> routers. > > Yes. No. The only extension header that *needs* to be parsed by intermediate routers is the hop-by-hop options header, and that is the first one (if present). (You can legitimately argue that the hbh header and the routing header are effectively useless, but that doesn't break fundamental connectivity.) IPv6 routers should have nothing to do with fragmentation. The problem is due to middleboxes that break the IPv6 spec by inspecting any part of the packet beyond the hop-by-hop header and discarding what they don't understand. Brian > > However, since fragmentation is near the end of the set of possible > options, that means that ANY recommendations about how IPv6 routers > handle options will require deep option parsing. How does that help? > >> While the IPv6 extension header syntax is good in terms of extensibility >> (in principle, you can include as many options as you want, it also >> allows for pathological cases in which the header chain is split among >> multiple fragments (we're working on fixing that one), and also requires >> any box that wants to find the upper-layer header to parse the entire >> IPv6 header chain -- something that a large number of devices cannot do >> at wire speed. > > I thought we were talking more about fragmentation - which defeats > filtering on upper layer info anyway. > > The non-HBH options can be split across fragments, but not the HBH ones. > >> For filtering purposes, it'd been interesting to have a pointer to the >> upper-layer header -- although with the original specs, it might simply >> not be there. With IPv4, at the very least it's trivial to find the >> upper layer protocol: just skip the first IHL of the packet, and you're >> there. With IPv6, at leasts in theory, it might be impossible (unless >> you reassemble-filter-and-refragment). > > In both cases fragmentation defeats DPI. But then so does IPsec. > > Yes, IPv6's chained header structure is not DPI-friendly. But this isn't > news, is it? > >>> Consider that: >>> >>> - routers don't like fragments because they can't inspect them >>> >>> - so we tunnel and fragment in a higher level protocol >>> >>> the router now needs to implement the higher protocol >>> and still fragment or else we cannot have tunnels >>> >>> the routers on the path still cannot inspect the >>> higher-level fragments >>> >>> So we're back to the reason this all breaks - routers doing something >>> that we simply cannot support in the architecture. >> >> It's probably time to accept that firewalls and routers implementing >> ACLs are part of the architecture. > > We need to accept one of three things: > > DPI is part of the architecture > either don't use IPv6 options > or don't use IPv6 > > IPv6 options are part of the architecture > DPI isn't meaningful anymore > >> One might argue that the use of >> firewalls couldn't be foreseen with IPv4. But at the time IPv6 was >> designed, it was already a reality. > > So that means IPv6 was designed to inhibit the use of options, or > designed to inhibit its own deployment. > > Seems like the latter is coming to fruition. > > Joe > From otroan@employees.org Thu Nov 1 04:16:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A5821F8490 for ; Thu, 1 Nov 2012 04:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMnOKlG72aX4 for ; Thu, 1 Nov 2012 04:16:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A662D21F8485 for ; Thu, 1 Nov 2012 04:16:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANNYklCQ/khN/2dsb2JhbABEw2qBCIIfAQEEEgEnPxALEjRJDgY1h2SbQaAfkVVhA6ROgWuCcA X-IronPort-AV: E=Sophos;i="4.80,692,1344211200"; d="scan'208";a="77924614" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Nov 2012 11:16:37 +0000 Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (dhcp-lys02-vla252-10-147-117-91.cisco.com [10.147.117.91]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA1BGars021630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 11:16:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <50924264.7040300@gmail.com> Date: Thu, 1 Nov 2012 12:16:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1498) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 11:16:40 -0000 >>>> Yes, but the whole point of the IPv6 option architecture was to = avoid >>>> the issues seen with IPv4 options. >>>=20 >>> The only thing in that IPv6 would avoid is requiring routers to = parse >>> *all* options, just to find the ones that need to be processed by >>> routers. >>=20 >> Yes. >=20 > No. The only extension header that *needs* to be parsed by = intermediate > routers is the hop-by-hop options header, and that is the first one = (if > present). >=20 > (You can legitimately argue that the hbh header and the routing header > are effectively useless, but that doesn't break fundamental = connectivity.) >=20 > IPv6 routers should have nothing to do with fragmentation. >=20 > The problem is due to middleboxes that break the IPv6 spec by = inspecting > any part of the packet beyond the hop-by-hop header and discarding = what > they don't understand. quite. what stops these boxes from filtering IPsec, TLS, or anything that isn't = HTTP with a whitewashed URL? I don't see how we can build protocols to accommodate middle boxes, and we have already done RFC3514. cheers, Ole From lorenzo@google.com Thu Nov 1 04:55:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7925021F8498 for ; Thu, 1 Nov 2012 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRJVHldru7Wk for ; Thu, 1 Nov 2012 04:55:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D521F847F for ; Thu, 1 Nov 2012 04:55:29 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2644656obq.31 for ; Thu, 01 Nov 2012 04:55:29 -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:x-system-of-record; bh=A6NQPEhpurnBOAlstqS5JCzbZ9AvOrO3vg3rO2tPi7k=; b=o0NV4KpM4UunSBXyHsez70oH2BliZcoGe+/UbkEyySp75c5fBUVJEn3BWnD2NFRqvs MMLp/aVMwZIAnOqZ3oxOTPKAV0GUTOmbCvSWr/TfWHLyIiNSrNZtsyL3GCVzP7MWQHoa c2n3zaACad6lvf5jxHdjBojTEVZZO2O5s+ABfoB8GsgfQkEtOYYPir/rX9QXfTCDaQKP jfgbVLvOUNg+9aHwqBJj9lhEBBAeyCiRSoBso0ZekjhlzHye/w9RXmKj2cN5QzE5umT6 m6OGbFwaPvBDx9T6kXrTJae88zPOJepnt16Ik9DI7Vry5mOKUJKRUlrPUhRdsWWQesyq /ufw== 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-system-of-record:x-gm-message-state; bh=A6NQPEhpurnBOAlstqS5JCzbZ9AvOrO3vg3rO2tPi7k=; b=VLDSQyVV7XhsINbT4a4UCNpNjMf2IbytbIk6eOc7PPmfQTsUtaqs7KF/87ejMhN7A4 VNM7BEzOW72COz4X52mdiSWjil2mDmqJsY8IdkxPWNyKd37NM9LHEB00XYS5Oxb1/g7t 9EnUCq5YFqF0O69cqEIByvxWiIEjFERNh3bvVOEdFxjiDCWqMRTzdbebaG4Qesd0uF3G tcQiQ3KNbyruOov/4fLfhoZdKmZbYWyvmN7D0Qmk8fhfR/hAf+oOdKO/rPVNkuvQnlW7 DcCC0Y7rvUhZs2q0DPA02CNNljR+ICY/4qp7bdckM4ep/b4KSCdD3dJSa22HfG/4HXs9 ml7A== Received: by 10.60.26.72 with SMTP id j8mr34542511oeg.68.1351770929322; Thu, 01 Nov 2012 04:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Thu, 1 Nov 2012 04:55:09 -0700 (PDT) In-Reply-To: <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> From: Lorenzo Colitti Date: Thu, 1 Nov 2012 20:55:09 +0900 Message-ID: To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=e89a8fb1f8d20f597204cd6db21b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkm4dIXYjTk/QJsbvZ1cBUpvrvUkL2OULdT6IxqUUdhVMCSYL4IXyfBFaCJluERaG/qZZH1HtOquZWEbagtybDWk4xQOlEGxX0bScXKsA1kiq/aJFKmJDrh81JiqOmMKVFmLHhUK6EgmUBR3I9eUqfpO22bzeDOW92g+3XxMzWBSSY6gP81QMdhkXhyRFuKqmVmvFrG Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 11:55:30 -0000 --e89a8fb1f8d20f597204cd6db21b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Nov 1, 2012 at 8:16 PM, Ole Tr=F8an wrote: > I don't see how we can build protocols to accommodate middle boxes, and w= e > have already done RFC3514. > I'm sorry, but there are real operational needs here. Here's an example: suppose I am under attack by a TCP SYN flood and want to rate-limit it or filter it out so I can process legitimate traffic. It would be reasonable for me to want to do this on a peering router, because it's as close as possible to the source, and it's a high-capacity, scalable box that needs to process each packet anyway. I don't want to carry tens of gigabits of useless attack packets all the way the way through the network to the end host, and overwhelm it, so I can drop them there. And I also don't want to put stateful firewalls at each peering connection, because the firewalls cost a lot of money, take up space in POPs and connecting them wastes expensive ports on peering routers= . The right way to deal with this is to rate-limit or drop on the routers. You're saying the architecture doesn't allow this? Then I'm sorry, but we need a better architecture. --e89a8fb1f8d20f597204cd6db21b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu= , Nov 1, 2012 at 8:16 PM, Ole Tr=F8an <otroan@employees.org> wrote:
I don't see how we can build protocols t= o accommodate middle boxes, and=A0we have already done RFC3514.

I'm sorry, but there are real operational needs here.

Here&#= 39;s an example: suppose I am under attack by a TCP SYN flood and want to r= ate-limit it or filter it out so I can process legitimate traffic.

It would be reasonable for me to want to do this on a peering router, b= ecause it's as close as possible to the source, and it's a high-cap= acity, scalable box that needs to process each packet anyway.

I = don't want to carry tens of gigabits of useless attack packets all the = way the way through the network to the end host, and overwhelm it, so I can= drop them there. And I also don't want to put stateful firewalls at ea= ch peering connection, because the firewalls cost a lot of money, take up s= pace in POPs and connecting them wastes expensive ports on peering routers.=

The right way to deal with this is to rate-limit or drop on the routers= .=A0You're saying the architecture doesn't allow this? Then I'm= sorry, but we need a better architecture.=A0
--e89a8fb1f8d20f597204cd6db21b-- From he@uninett.no Thu Nov 1 04:59:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28B21F84D6 for ; Thu, 1 Nov 2012 04:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-NDB8iGLBHV for ; Thu, 1 Nov 2012 04:59:00 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 1382621F84D5 for ; Thu, 1 Nov 2012 04:58:59 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 0901E3D0B4; Thu, 1 Nov 2012 12:58:58 +0100 (CET) Date: Thu, 01 Nov 2012 12:58:57 +0100 (CET) Message-Id: <20121101.125857.178864472.he@uninett.no> To: lorenzo@google.com From: Havard Eidnes In-Reply-To: References: <50913A1D.6060806@inex.ie> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 11:59:00 -0000 >> > and how much of good people's time do you plan to waste on this >> > windmill, don? >> >> Randy, >> >> you're right that we appear to have backed ourselves into a corner w= here we >> expect kit to be able to handle TLV processing at wire speed. >> >> Rather than stowing thrones, do you have any constructive suggestion= s on >> how to deal with the situation? > > How about deprecate fragmentation at the IP layer and standardize a > higher-layer alternative? Would you care to venture a guess as to how long it will take for such an alternative to be standardized, implemented, and widely deployed so that it can actually be used? What do you suggest we do in the mean time? I'll venture a guess that it's going to take "too long". Regards, - H=E5vard From he@uninett.no Thu Nov 1 06:02:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6C21F9004 for ; Thu, 1 Nov 2012 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92G7cNbzdX+3 for ; Thu, 1 Nov 2012 06:02:24 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 7698D21F8FB9 for ; Thu, 1 Nov 2012 06:01:57 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9F84D3D0B4 for ; Thu, 1 Nov 2012 14:01:55 +0100 (CET) Date: Thu, 01 Nov 2012 14:01:55 +0100 (CET) Message-Id: <20121101.140155.359607824.he@uninett.no> To: v6ops@ietf.org From: Havard Eidnes In-Reply-To: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 13:02:25 -0000 Hi, I would like to pick up on section 2.2 in the draft, named "Impact on Applications". As far as I've seen so far in the discussion, there has been almost no discussion of this part of the draft. I also find the analysis and explanation of the issues faced by DNS in general and DNSSEC in particular to be ... somewhat weak. > DNS is one application that may be vulnerable when fragment > dropping occurs. "Vulnerable" is not a word I would use in this context, since it rings of "security issue". "Affected" is perhaps a better word. Secondly, who gets affected, and what is the effect? That's not mentioned, and it probably should be. Even though EDNS0 and DNSSEC is mentioned in the draft, the implications are not spelled out. It may come as a surprise to some that all currently supported versions of BIND and Unbound, as well as all Windows name servers from 2008R2 onwards, all in the role as recursive resolver by default send DNS queries with EDNS0 buffer size set at around 4096 bytes *and* set the "send DNSSEC information, if available" flag, *even if the recursive resolver is not configured to do DNSSEC validation*. In practice, this means that even if you don't use DNSSEC, unless you take steps to prevent it, your recursive resolver will increasingly need to be able to receive fragmented packets in order to work satisfactorily. > The current choices open to the operators of DNS servers in > this situation are to defer deployment of DNSSEC, fragment > responses, or use TCP if there are cases where the rrset > would be expected to exceed the MTU. This part of the draft is at best unclear. If I'm an authoritative name server, serving a zone which is DNSSEC signed, which results in large (>1500 bytes) responses to a given query received over UDP, where the querier asks for DNSSEC info and specifies a large buffer size with EDNS0, I have no choice but to respond using UDP, and if the resulting datagram is largish, I have to use fragmentation. In particular, the authoritative name server has no option to "use TCP", that initiative has to come from the recursive resolver who initiated the query in the first place. The various recursive resolver implementations have various different strategies for dealing with situations where queries sent with DO=3D1 and EDNS0 bufsize=3D doesn't make it back, among them dropping down the bufsize, dropping EDNS0 (and DO=3D1) entirely, or resorting to TCP. Meanwhile time is ticking away, since the recursive resolver typically needs to experience multiple query timeouts before engaging in alternative behaviour. Who's affected by this? Those using the recursive resolver who happily announces that it wants large packets, but which has also implemented non-initial fragment dropping in the infrastructure around its recursive resolver. "You make your bed, now you lie in it." might be a valid response. To my mind deferring DNSSEC deployment until each and every corner on the Internet won't have issues with reception of fragments is a total non-starter. I predict that there will always be a fresh supply of overly paranoid firewall administrators who insist on breaking parts of the protocols, either through ignorance, fear, or for other reasons. If we wait until this supply dries up, we will be waiting forever. The draft goes on to say: > The use of fallback to TCP will impose a major resource and > performance hit and increases vulnerability to denial of service > attacks. Here I will at least partially agree. I think RIPE Labs recently did a measurement which ended up indicating that a query over TCP takes 2 to 3 times as long as a query over UDP to complete. In addition, TCP imposes increased state load on the publishing DNS servers. "Increased vulnerability to denial of service attacks" I'm not so sure of. It's always been a requirement that publishing DNS name servers be reachable over TCP, so that should make it "the same". (Yes, I'll concede that this latter point is probably widely ignored...) So... With the steadily increasing deployment of DNSSEC and with fragmented UDP packets going with that, I think we should clearly document to avoid problems caused by both running recursive resolvers with the default configuration and at the same time configure their infrastructure surrounding their recursive resolvers to drop non-initial fragments, and that this advice is valid even if they themselves don't use DNSSEC. (Yes, that's an overly complicated senctence, but I have to dash...) Regards, - H=E5vard From otroan@employees.org Thu Nov 1 06:10:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4D21F8B6F for ; Thu, 1 Nov 2012 06:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f560mZoKDBjj for ; Thu, 1 Nov 2012 06:10:46 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 633AF21F93E8 for ; Thu, 1 Nov 2012 06:09:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFt0klCQ/khM/2dsb2JhbABEw2iBCIIeAQEBAwESAWYFCwsSNEkOBi4Hh14Gm2mgKowQhUVhA6ROgWuCcIFb X-IronPort-AV: E=Sophos;i="4.80,693,1344211200"; d="scan'208";a="9265081" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 01 Nov 2012 13:09:44 +0000 Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (dhcp-lys02-vla252-10-147-117-91.cisco.com [10.147.117.91]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA1D9hOV018216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 13:09:44 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 1 Nov 2012 14:09:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <042A1B68-33DA-47FA-8E80-4A635E405E97@employees.org> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1498) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 13:10:46 -0000 Lorenzo, > I don't see how we can build protocols to accommodate middle boxes, = and we have already done RFC3514. >=20 > I'm sorry, but there are real operational needs here. >=20 > Here's an example: suppose I am under attack by a TCP SYN flood and = want to rate-limit it or filter it out so I can process legitimate = traffic. >=20 > It would be reasonable for me to want to do this on a peering router, = because it's as close as possible to the source, and it's a = high-capacity, scalable box that needs to process each packet anyway. >=20 > I don't want to carry tens of gigabits of useless attack packets all = the way the way through the network to the end host, and overwhelm it, = so I can drop them there. And I also don't want to put stateful = firewalls at each peering connection, because the firewalls cost a lot = of money, take up space in POPs and connecting them wastes expensive = ports on peering routers. >=20 > The right way to deal with this is to rate-limit or drop on the = routers. You're saying the architecture doesn't allow this? Then I'm = sorry, but we need a better architecture.=20 yes, we need a better architecture. IPv4 and IPv6 are not different = here. I disagree that the architecture you propose is a better one though. if I understand you correctly, to solve the above problem you need: - deprecate all IPv6 extension headers - deprecate IPv4 and IPv6 fragmentation - ban use of IPsec - ban any new transport protocol, e.g. SCTP aren't there other solutions to this problem? no other attack signature? cheers, Ole= From philip_matthews@magma.ca Thu Nov 1 07:06:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCB21F8CBD for ; Thu, 1 Nov 2012 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+7zzyNqNQKL for ; Thu, 1 Nov 2012 07:06:12 -0700 (PDT) Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC221F8CB5 for ; Thu, 1 Nov 2012 07:06:12 -0700 (PDT) Received: from [74.198.165.39] (helo=[172.20.10.2]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TTvPN-0002l9-36; Thu, 01 Nov 2012 10:06:12 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 10:06:04 -0400 Message-Id: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> To: draft-ietf-v6ops-nat64-experience@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.39] Cc: "v6ops@ietf.org list" Subject: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-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, 01 Nov 2012 14:06:13 -0000 Hi authors: I read your draft with interest. I need to re-read it more carefully, = but here are some preliminary comments: 1) The title of the draft is "NAT64 Operational Experiences", but I feel = the draft reads much more like "NAT64 Deployment Considerations". I = didn't see any place where the draft says "This is what we did and it = worked well (or it didn't work well)". That is, it is not really = relating the specific experience of an operator in deploying NAT64 so = much as describing things that an operator should take into account when = planning their own NAT64 deployment.=20 2) Section 3.1 has the sentence: It is advantageous from the vantage-point of troubleshooting and traffic engineering to carry the IPv6 traffic natively for as long as possible within an access network and translates only at or near the network egress. I think it would be interesting and helpful to say more about why you = feel this is true. Can you give some specific examples? Though today I = suspect most operators will try to centralize their NAT64 boxes for cost = reasons, I can see in the future an operator that is forced to go pure = IPv6 and is planning a large rollout, and will be worried that = centralizing NAT64 will not scale well and will thus consider pushing = NAT64 to closer to the customer. 3) Section 3.2 on HA Considerations has the sentence: Given that short lived sessions account for most of the bindings, hot-standby does not offer much benefit for those sessions. Just curious if you have evidence or a reference that backs up this = claim? This is certainly frequently stated for NAT44, but I haven't seen = hard facts in the case of NAT64. I am especially wondering if the fact = that some traffic (like DNS traffic and native IPV6 traffic) doesn't go = through the NAT64 would change the situation from the NAT44 case. 4) The draft is currently organized so that section 3 discusses the = NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE = case. I suggest you consider organizing the draft differently, so that = you have a series of sections discussing a topic (e.g Load Balancing or = MTU), and within the section you first discuss the NAT64-CGN case and = then the NAT64-CPE case. I suggest that this would allow you to discuss = each topic more fully, and would emphasis the similarities or = differences between the CGN and CPE cases. Just a suggestion. - Philip= From brian.e.carpenter@gmail.com Thu Nov 1 08:06:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8409421F8DD6 for ; Thu, 1 Nov 2012 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.496 X-Spam-Level: X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFP1LmgQ3bSq for ; Thu, 1 Nov 2012 08:06:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D59B621F8DBE for ; Thu, 1 Nov 2012 08:06:43 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1240600wgb.13 for ; Thu, 01 Nov 2012 08:06:43 -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=ZOdRANw2ewV7YQ/GY+E/3hRW3ri2JgXjxQZ/XaQfafo=; b=tasqHTJl28okcrqt7KQDe55kYrJfeXPHPK0gfsUdIbmk6eyB+00/oKizAELm3u66qv wx/lvj+WhLhUl4vTRMLvQwL0PZ0yR+PfLXI5DPKziP8aq2V768f2zgtjWL150yAKOOVB eoPEsvdNtYDxa0zBF5UEEfzYtKB8Q2kqAdUqLZu3ZTv0z5a1e59JyEhoST/Go+DFnhLs 4zeRIqBMLw6iMlvhwCBS+4fW2VGmC4IsLWuplYG+1+Gi/s9RvV7hEQafLLWC4BwZgLNQ 9AAQNmeVh4aHedqwgfzSG1FMZT6Ev9xNztOKWO3VCSA6WQ1xSM0mnfHsk7Kx0WmWk5NS gLRA== Received: by 10.216.139.137 with SMTP id c9mr19530182wej.54.1351782403017; Thu, 01 Nov 2012 08:06:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-140.as13285.net. [2.102.216.140]) by mx.google.com with ESMTPS id k20sm22321775wiv.11.2012.11.01.08.06.40 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:06:41 -0700 (PDT) Message-ID: <5092900C.3090708@gmail.com> Date: Thu, 01 Nov 2012 15:06:52 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> In-Reply-To: <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 15:06:44 -0000 On 01/11/2012 11:16, Ole Tr=C3=B8an wrote: >>>>> Yes, but the whole point of the IPv6 option architecture was to avo= id >>>>> the issues seen with IPv4 options. >>>> The only thing in that IPv6 would avoid is requiring routers to pars= e >>>> *all* options, just to find the ones that need to be processed by >>>> routers. >>> Yes. >> No. The only extension header that *needs* to be parsed by intermediat= e >> routers is the hop-by-hop options header, and that is the first one (i= f >> present). >> >> (You can legitimately argue that the hbh header and the routing header= >> are effectively useless, but that doesn't break fundamental connectivi= ty.) >> >> IPv6 routers should have nothing to do with fragmentation. >> >> The problem is due to middleboxes that break the IPv6 spec by inspecti= ng >> any part of the packet beyond the hop-by-hop header and discarding wha= t >> they don't understand. >=20 >=20 > quite. > what stops these boxes from filtering IPsec, TLS, or anything that isn'= t HTTP with a > whitewashed URL? >=20 > I don't see how we can build protocols to accommodate middle boxes, and= > we have already done RFC3514. We can't; it's an arms race, because however we try to hide the good stuf= f, those boxes will eventually be "improved" to find it. All we can do is understand and document the harm. Brian From iesg-secretary@ietf.org Thu Nov 1 08:23:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6221F8DC4; Thu, 1 Nov 2012 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qhg5jCcrTJr; Thu, 1 Nov 2012 08:23:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556CD21F8DE7; Thu, 1 Nov 2012 08:23:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121101152347.4582.70873.idtracker@ietfa.amsl.com> Date: Thu, 01 Nov 2012 08:23:47 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Basic Requirements for IPv6 Customer Edge Routers' to Informational RFC (draft-ietf-v6ops-6204bis-12.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:23:48 -0000 The IESG has approved the following document: - 'Basic Requirements for IPv6 Customer Edge Routers' (draft-ietf-v6ops-6204bis-12.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ Technical Summary This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. Working Group Summary The Bis document follows quickly on the heals of the original RFC 6204 (published April 2011). This speaks both to the rapid ferment associated with transition technologies and their deployment in CPE devices as well as the impact that operational experience is now having on recommendations. Clearly in this case, perfection is the enemy of the good, and timely publication will likely result in issues that need to be revisited or resolved in future documents. The input of the design team was thoroughly discussed on the mailing list resulting in Draft 08 which passed working group last call, with draft 09 addressing issues with 6rd requirements found during and immediately after WGLC. A subsequent and shorter last call was confirmed on tuesday 5/22/2012. There is ongoing discussion around requirements related to setting MSS MTU requirements for transition technologies. Consensus in this area to the extent that it exists is still evolving. Additional work in the form of a draft or drafts may be required and several have already been proposed. Document Quality The document shepherd believes that the document is generally well written. Significant experience with RFC 6204 by implementers and operators resulted in the document that we see here. The Advice provided here is by no-means comprehensive, but with implementers using these guidelines a common expectation for CPE functionality inclusive of transition technologies is seems plausible. Personnel The document shepherd is Joel Jaeggli v6ops co-chair. The responsible area-director is Ron Bonica. RFC Editor Note Please remove unused references to RFCs 2030 and 3704 From philip_matthews@magma.ca Thu Nov 1 08:38:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450E821F8B7E for ; Thu, 1 Nov 2012 08:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P6ltEUz0ioQ for ; Thu, 1 Nov 2012 08:38:42 -0700 (PDT) Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9221F8B52 for ; Thu, 1 Nov 2012 08:38:42 -0700 (PDT) Received: from [74.198.165.47] (helo=[172.20.10.2]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TTwqv-0002ZP-0s; Thu, 01 Nov 2012 11:38:41 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 11:38:36 -0400 Message-Id: <6F920D02-6E29-42F3-9BA2-5D0B2E1EE77B@magma.ca> To: draft-ietf-v6ops-enterprise-incremental-ipv6@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.47] Cc: "v6ops@ietf.org list" Subject: [v6ops] Comments on draft-ietf-v6ops-enterprise-incremental-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 15:38:43 -0000 Hi authors: I really like this draft. I find it well written and quite insightful. Here are a few comments based on a fairly quick read: 1) Section 4.1 on external connectivity has the following paragraph: PI and PA space have additional contrasting behaviours when use such as how dual homing may work. Should an operator choose to dual home, PI space would be routed to both upstream providers and then passed on to other networks. Utilizing more then one upstream Service Provider may introduce challenges since traffic utilizing a given PA assign block would be expected to flow through the assigning provider for entry to the Internet. Should traffic flow using sources addresses which are not delegated form a given provider, reverse path forwarding rules on the operator side may reject some traffic. These considerations are quite different then those of IPv4 which relied on NAT in most cases. There seems to be a sudden jump in the discussion here starting with the = sentence "Utilizing ...". Before you were talking about PI space, then = you suddenly jump and talk about a concern with using PA space. 2) Also in section 4.1, you don't say anything about the third approach = of getting PA space from two providers and using NAT66. 3) And section 4.1 also contains the following rather interesting = sentence: On significant factor guiding how an organization may need to communist with the outside world will involve the use of PI (Provider Independent) and/or PA (Provider Aggregatable) IPv6 space. s/On/One/ s/communist/communicate/ 4) A meta-question: Some of the advice in this document is not specific = to the enterprise situation. I am wondering if it would be helpful to = pull that part out into a separate document? No strong opinion here -- = just an observation for now. - Philip From touch@isi.edu Thu Nov 1 11:25:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C00021F926A for ; Thu, 1 Nov 2012 11:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZccO+pOvYE2N for ; Thu, 1 Nov 2012 11:25:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16721F8994 for ; Thu, 1 Nov 2012 11:25:53 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA1IPN79024136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 11:25:23 -0700 (PDT) Message-ID: <5092BE93.9090809@isi.edu> Date: Thu, 01 Nov 2012 11:25:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 18:25:54 -0000 On 11/1/2012 4:55 AM, Lorenzo Colitti wrote: > On Thu, Nov 1, 2012 at 8:16 PM, Ole Trøan > wrote: > > I don't see how we can build protocols to accommodate middle boxes, > and we have already done RFC3514. > > > I'm sorry, but there are real operational needs here. > > Here's an example: suppose I am under attack by a TCP SYN flood and want > to rate-limit it or filter it out so I can process legitimate traffic. > > It would be reasonable for me to want to do this on a peering router, > because it's as close as possible to the source, and it's a > high-capacity, scalable box that needs to process each packet anyway. > > I don't want to carry tens of gigabits of useless attack packets all the > way the way through the network to the end host, and overwhelm it, so I > can drop them there. And I also don't want to put stateful firewalls at > each peering connection, because the firewalls cost a lot of money, take > up space in POPs and connecting them wastes expensive ports on peering > routers. > > The right way to deal with this is to rate-limit or drop on the > routers. You're saying the architecture doesn't allow this? Then I'm > sorry, but we need a better architecture. The "right way" is to drop them at the offending source, but I hope we all agree we cannot do that because there's no viable solution. The architecture already allows the router to shed load by dropping packets either arbitrarily or per-destination. However, you want to preferentially drop these at your ingress router, but there's no viable solution there that doesn't require stateful firewalls. So your conclusion is that the architecture is broken. If you have a better architecture - one that also supports tunnels, which are ubiquitous now too - it might be useful to disclose it. Otherwise, it might be time to admit that you can't always get what you want. Joe From touch@isi.edu Thu Nov 1 11:35:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6AE21F8B06 for ; Thu, 1 Nov 2012 11:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5U0lFsGV2Yp for ; Thu, 1 Nov 2012 11:35:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C502E21F92E1 for ; Thu, 1 Nov 2012 11:35:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA1IYY6s026158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 11:34:34 -0700 (PDT) Message-ID: <5092C0BA.4090000@isi.edu> Date: Thu, 01 Nov 2012 11:34:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> In-Reply-To: <50924264.7040300@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 18:35:19 -0000 On 11/1/2012 2:35 AM, Brian E Carpenter wrote: > On 31/10/2012 18:58, Joe Touch wrote: >> >> >> On 10/31/2012 11:34 AM, Fernando Gont wrote: >>> On 10/31/2012 04:11 PM, Joe Touch wrote: >>>> Yes, but the whole point of the IPv6 option architecture was to avoid >>>> the issues seen with IPv4 options. >>> >>> The only thing in that IPv6 would avoid is requiring routers to parse >>> *all* options, just to find the ones that need to be processed by >>> routers. >> >> Yes. > > No. The only extension header that *needs* to be parsed by intermediate > routers is the hop-by-hop options header, and that is the first one (if > present). The first one could be: A. a known HBH option indicating there are HBH options B. a known E2E option indicating there are no HBH options C. an unknown option or a pad option indicating NOTHING In the case of C, the router needs to keep looking at subsequent options until one of three things happens: 1. a known HBH option is seen indicating there are HBH options 2. a known E2E option is seen indicating there are no HBH options 3. there are no more options indicating there are no HBH options As a result, it's entirely possible that a router could need to parse the entire option chain before it can determine whether there are any HBH options. > (You can legitimately argue that the hbh header and the routing header > are effectively useless, but that doesn't break fundamental connectivity.) > > IPv6 routers should have nothing to do with fragmentation. +1 > The problem is due to middleboxes that break the IPv6 spec by inspecting > any part of the packet beyond the hop-by-hop header and discarding what > they don't understand. +1 Joe From touch@isi.edu Thu Nov 1 11:39:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31821F87EE for ; Thu, 1 Nov 2012 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3wcK1QU+NgQ for ; Thu, 1 Nov 2012 11:38:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D5F7221F9313 for ; Thu, 1 Nov 2012 11:38:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA1Ib0m7026507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 11:37:00 -0700 (PDT) Message-ID: <5092C14B.7090704@isi.edu> Date: Thu, 01 Nov 2012 11:36:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <507DAB13.2010704@inex.ie> <507DDF8A.9010607@inex.ie> <507F265E.6030000@inex.ie> <507F32DA.30600@inex.ie> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> <5091C787.6060403@isi.edu> In-Reply-To: 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" , "draft-taylor-v6ops-fragdrop@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 18:39:00 -0000 On 10/31/2012 5:58 PM, Lorenzo Colitti wrote: > On Thu, Nov 1, 2012 at 9:51 AM, Joe Touch > wrote: > > However, you've answered the key issue - this is not about > fragments, but rather about two things: > > a) DPI > DPI cannot be done on packets with any options > so this either means operators need to ignore DPI > on such packets or drop them > > > I don't think we should use the term DPI, because we don't really have > consensus on what it means. I suspect some would assert that just > looking at layer 4 headers is not DPI and that it's only DPI if you look > into layer 4 payloads as well. IMO, a router that looks beyond the IP headers is doing DPI. I realize others think DPI means looking at the E2E data. However, to avoid confusion, I'll just state that: - anything that looks only at an IP packet is a router - anything that looks at higher layer headers isn't a router anymore. it might be a firewall, filter, etc., and whether the box can do that at line rate is a question customers should ask their vendors, not a problem the IETF should solve. Joe From Fred.L.Templin@boeing.com Thu Nov 1 12:01:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0521F93F4 for ; Thu, 1 Nov 2012 12:01: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s-JOlp0hINK for ; Thu, 1 Nov 2012 12:01:00 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id AC89721F93E5 for ; Thu, 1 Nov 2012 12:01:00 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qA1J0xun001869 for ; Thu, 1 Nov 2012 14:01:00 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qA1J0wLN001856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Nov 2012 14:00:59 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 1 Nov 2012 12:00:59 -0700 From: "Templin, Fred L" To: Joe Touch , Lorenzo Colitti Date: Thu, 1 Nov 2012 12:00:57 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac24XlkhIaCtjNT0Rym0JjVszzuXZAABHYXA Message-ID: References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5092BE93.9090809@isi.edu> In-Reply-To: <5092BE93.9090809@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:01:02 -0000 > > The right way to deal with this is to rate-limit or drop on the > > routers. You're saying the architecture doesn't allow this? Then I'm > > sorry, but we need a better architecture. >=20 > The "right way" is to drop them at the offending source, but I hope we > all agree we cannot do that because there's no viable solution. Isn't ingress filtering the means by which packets are dropped as close to the offending source as possible? And, shouldn't ingress filtering be implemented by all legitimate sites? Thanks - Fred fred.l.templin@boeing.com From brian.e.carpenter@gmail.com Thu Nov 1 12:06:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898121F9424 for ; Thu, 1 Nov 2012 12:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.636 X-Spam-Level: X-Spam-Status: No, score=-101.636 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJwG+HvTkZV5 for ; Thu, 1 Nov 2012 12:06:43 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB621F9221 for ; Thu, 1 Nov 2012 12:06:36 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1349095wgb.13 for ; Thu, 01 Nov 2012 12:06:35 -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=t8DUw+f0uJQTiDSRxrocrjfuR0Y42fsGDzTpeHPZIlE=; b=BJcpcv28wHb4vS9j1Hv4+ZmLMw4yxOoWN2zI9T9Dsr97o5YFuuJ4GkTB2aesqcxx+D WIGv7/zSn+TBzWzPznL9DIhdVwv7IhVmRdJ4GPqtQxSN9Mj2ZFBXZ4F0LWfrRVSclSva MSMqGKlmIQDfe+wyxbrln48WvQFPJ7EH2gGWlfMeD3jNR6azYy6TG1B3ekdMEsTHRBdH UmJKdnvvi7yU/JHHJZr7AJIak91fLOelzR3p7h+wgCLyc+Bg8WcVdKphYgh5Dho9O7LJ Tl5KN5Mt0lD0gtKAnUfh5UJAZkwZmx7et4QdJhkAW/7G12xcuDinprNS0HJ3qoblPfSF G9Ww== Received: by 10.180.84.102 with SMTP id x6mr2864785wiy.12.1351796795815; Thu, 01 Nov 2012 12:06:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-140.as13285.net. [2.102.216.140]) by mx.google.com with ESMTPS id ay10sm171263wib.2.2012.11.01.12.06.33 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 12:06:34 -0700 (PDT) Message-ID: <5092C846.5090009@gmail.com> Date: Thu, 01 Nov 2012 19:06:46 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> In-Reply-To: <5092C0BA.4090000@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:06:44 -0000 Joe, On 01/11/2012 18:34, Joe Touch wrote: > > > On 11/1/2012 2:35 AM, Brian E Carpenter wrote: >> On 31/10/2012 18:58, Joe Touch wrote: >>> >>> >>> On 10/31/2012 11:34 AM, Fernando Gont wrote: >>>> On 10/31/2012 04:11 PM, Joe Touch wrote: >>>>> Yes, but the whole point of the IPv6 option architecture was to avoid >>>>> the issues seen with IPv4 options. >>>> >>>> The only thing in that IPv6 would avoid is requiring routers to parse >>>> *all* options, just to find the ones that need to be processed by >>>> routers. >>> >>> Yes. >> >> No. The only extension header that *needs* to be parsed by intermediate >> routers is the hop-by-hop options header, and that is the first one (if >> present). > > The first one could be: > > A. a known HBH option > indicating there are HBH options > B. a known E2E option > indicating there are no HBH options > C. an unknown option or a pad option > indicating NOTHING Actually there is another unfortunate aspect of RFC 2460 here. It would be better if it said that the hbh options extension header MUST be first, instead of just recommending it. I think I will add that to my draft. > In the case of C, the router needs to keep looking at subsequent options > until one of three things happens: > > 1. a known HBH option is seen > indicating there are HBH options > 2. a known E2E option is seen > indicating there are no HBH options > 3. there are no more options > indicating there are no HBH options > > As a result, it's entirely possible that a router could need to parse > the entire option chain before it can determine whether there are any > HBH options. Yes, because of the point I just mentioned. That's a bug IMHO. However, the observed problems come from middleboxes that don't parse regular extension headers, not hbh option headers. Brian >> (You can legitimately argue that the hbh header and the routing header >> are effectively useless, but that doesn't break fundamental >> connectivity.) >> >> IPv6 routers should have nothing to do with fragmentation. > > +1 > >> The problem is due to middleboxes that break the IPv6 spec by inspecting >> any part of the packet beyond the hop-by-hop header and discarding what >> they don't understand. > > +1 > > Joe > From joelja@bogus.com Thu Nov 1 12:07:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002BE21F9435 for ; Thu, 1 Nov 2012 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PCuiLwnXYy5 for ; Thu, 1 Nov 2012 12:07:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 90A6621F9434 for ; Thu, 1 Nov 2012 12:07:04 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qA1J6wJk066115 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 19:06:58 GMT (envelope-from joelja@bogus.com) Message-ID: <5092C84D.8050306@bogus.com> Date: Thu, 01 Nov 2012 12:06:53 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Templin, Fred L" References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5092BE93.9090809@isi.edu> In-Reply-To: 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, 01 Nov 2012 19:06:58 +0000 (UTC) Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:07:05 -0000 On 11/1/12 12:00 PM, Templin, Fred L wrote: >>> The right way to deal with this is to rate-limit or drop on the >>> routers. You're saying the architecture doesn't allow this? Then I'm >>> sorry, but we need a better architecture. >> The "right way" is to drop them at the offending source, but I hope we >> all agree we cannot do that because there's no viable solution. > Isn't ingress filtering the means by which packets are > dropped as close to the offending source as possible? And, > shouldn't ingress filtering be implemented by all legitimate > sites? Yeah so, I can clearly turn off all my ACLs because all my upstreams will filter unwanted traffic for me when it enters their network... > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Thu Nov 1 12:15:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D0121F93E4 for ; Thu, 1 Nov 2012 12:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRW+pa7JkR4z for ; Thu, 1 Nov 2012 12:15:29 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D826421F93E0 for ; Thu, 1 Nov 2012 12:15:28 -0700 (PDT) Received: from [216.130.36.186] (helo=[10.154.150.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TU0Eb-00007N-HT; Thu, 01 Nov 2012 20:15:23 +0100 Message-ID: <5092A13F.7010902@si6networks.com> Date: Thu, 01 Nov 2012 14:20:15 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> In-Reply-To: <509174F1.8080809@isi.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:15:29 -0000 Hi, Joe, On 10/31/2012 04:58 PM, Joe Touch wrote: >> While the IPv6 extension header syntax is good in terms of extensibility >> (in principle, you can include as many options as you want, it also >> allows for pathological cases in which the header chain is split among >> multiple fragments (we're working on fixing that one), and also requires >> any box that wants to find the upper-layer header to parse the entire >> IPv6 header chain -- something that a large number of devices cannot do >> at wire speed. > > I thought we were talking more about fragmentation - which defeats > filtering on upper layer info anyway. Well, it's the combination of both that defeats stateless filtering. However, please see draft-ietf-6man-oversized-header-chain. >> For filtering purposes, it'd been interesting to have a pointer to the >> upper-layer header -- although with the original specs, it might simply >> not be there. With IPv4, at the very least it's trivial to find the >> upper layer protocol: just skip the first IHL of the packet, and you're >> there. With IPv6, at leasts in theory, it might be impossible (unless >> you reassemble-filter-and-refragment). > > In both cases fragmentation defeats DPI. But then so does IPsec. But the two are completely different cases. With IPsec, there's a trust relationship between the two endpoints. That doesn't necessarly mean that you wouldn't like any DPI, though. > Yes, IPv6's chained header structure is not DPI-friendly. But this isn't > news, is it? Agreed. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Nov 1 12:22:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC01D21F9477 for ; Thu, 1 Nov 2012 12:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gceks-n2Wlg for ; Thu, 1 Nov 2012 12:22:27 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 245B821F9471 for ; Thu, 1 Nov 2012 12:22:27 -0700 (PDT) Received: from [216.130.36.186] (helo=[10.154.150.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TU0LF-0000Mb-Sa; Thu, 01 Nov 2012 20:22:17 +0100 Message-ID: <50929E7A.5040101@si6networks.com> Date: Thu, 01 Nov 2012 14:08:26 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> In-Reply-To: <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:22:28 -0000 On 11/01/2012 09:16 AM, Ole Trøan wrote: > I don't see how we can build protocols to accommodate middle boxes, and > we have already done RFC3514. Well, you simply do not rely on stuff that is unreliable. e.g., any protocol that relies on extension headers is likely to have deployment problems. So, you better e.g. carry your options somewhere else, as opposed to putting them in IPv6 extension headers. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Nov 1 12:23:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5863A21F8E04 for ; Thu, 1 Nov 2012 12:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tbqMhdS+1bQ for ; Thu, 1 Nov 2012 12:23:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E031121F8A67 for ; Thu, 1 Nov 2012 12:23:26 -0700 (PDT) Received: from [216.130.36.186] (helo=[10.154.150.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TU0ME-0000Mh-3i; Thu, 01 Nov 2012 20:23:23 +0100 Message-ID: <5092A26E.2000503@si6networks.com> Date: Thu, 01 Nov 2012 14:25:18 -0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50918153.7070509@si6networks.com> <50918349.9020205@isi.edu> In-Reply-To: <50918349.9020205@isi.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:23:34 -0000 On 10/31/2012 06:00 PM, Joe Touch wrote: >>> However, since fragmentation is near the end of the set of possible >>> options, that means that ANY recommendations about how IPv6 routers >>> handle options will require deep option parsing. How does that help? >> >> mm.. not sure what you mean. Could you elaborate a bit more? > > The fragment header is not required to be the first header; it's > required to come after the HBH and before the E2E ones. > > So "must drop IPv6 fragments" implies parsing ALL HBH headers that come > before the frag header (or you'd never know the frag header was there). That's why it's very likely that IPv6 packets with extension headers (whether Frag Header, Dst pts header, or some other one9 will be unreliable. >>> I thought we were talking more about fragmentation - which defeats >>> filtering on upper layer info anyway. >> >> It *currently* does in v6, but not in v4: in v4 the first fragment >> always has, at the very least, the IP addresses, upper-layer protocol, >> and transport ports. In v6 (with the current specs), that might not be >> the case. >> >> >>> The non-HBH options can be split across fragments, but not the HBH ones. >> >> And...? > > I'm not sure what bug you're implying above ("we're working on fixing > that one"), but it's not that the entire chain is split among the > fragments. Please see: draft-ietf-6man-oversize-header-chain. I wouldn't call it a "bug" but rather a pathological case that, while non-existent in practice, was still allowed by the current specs. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From sthaug@nethelp.no Thu Nov 1 12:24:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0821F91E3 for ; Thu, 1 Nov 2012 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IihW6hXaKBoo for ; Thu, 1 Nov 2012 12:24:18 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id E0C8221F91DD for ; Thu, 1 Nov 2012 12:24:17 -0700 (PDT) Received: (qmail 74581 invoked from network); 1 Nov 2012 19:24:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Nov 2012 19:24:16 -0000 Date: Thu, 01 Nov 2012 20:24:16 +0100 (CET) Message-Id: <20121101.202416.112557190.sthaug@nethelp.no> To: touch@isi.edu From: sthaug@nethelp.no In-Reply-To: <5092C14B.7090704@isi.edu> References: <5092C14B.7090704@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, draft-taylor-v6ops-fragdrop@tools.ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:24:19 -0000 > IMO, a router that looks beyond the IP headers is doing DPI. I realize > others think DPI means looking at the E2E data. > > However, to avoid confusion, I'll just state that: > > - anything that looks only at an IP packet is a router > > - anything that looks at higher layer headers isn't a router anymore. it > might be a firewall, filter, etc., and whether the box can do that at > line rate is a question customers should ask their vendors, not a > problem the IETF should solve. This looks like a nice theoretical classification that is rather useless in practice. A modern router with multiple 10G interfaces (say a Juniper MX or Cisco ASR9K) can be configured to look at higher layers. The primary function of these routers is forwarding packets at high speeds. The fact that these routers *can* look at higher layers is not going to make me stop calling them routers. I don't think I'm alone here :-) As for the idea that routers shouldn't look at higher layers: - Routers need to be able to protect themselves. This may require looking at higher layer info, as noted by several people. - At the borders of my AS I may need to look at higher layer info to protect services or customers within my AS. For instance: I may want my recursive name servers to be pingable from outside my AS - but any DNS lookups towards these servers from outside my AS should be dropped. The obvious place for such filtering is at the border routers, done in hardware at high speed. Sure I can ask my vendors if their boxes can parse arbitrarily long IPv6 header chains at line rate. But *until* such boxes are installed in my network: If I'm being attacked with "hard to parse" IPv6 traffic at line rate, I'm much more likely to configure my border routers to drop traffic (for instance by dropping all IPv6 headers except those I know I need) than simply not doing anything at "because routers should not look at higher layers". Steinar Haug, AS 2116 From Fred.L.Templin@boeing.com Thu Nov 1 12:33:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B5E21F93D0 for ; Thu, 1 Nov 2012 12:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZCfvtFFiaQZ for ; Thu, 1 Nov 2012 12:33:49 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9C21F93CA for ; Thu, 1 Nov 2012 12:33:49 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qA1JXmbW006049 for ; Thu, 1 Nov 2012 14:33:48 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qA1JXksD005542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Nov 2012 14:33:46 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 1 Nov 2012 12:33:46 -0700 From: "Templin, Fred L" To: joel jaeggli Date: Thu, 1 Nov 2012 12:33:45 -0700 Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: Ac24ZBYPYg8LIle0SHGY6IzNpWeIJAAA1rgg Message-ID: References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5092BE93.9090809@isi.edu> <5092C84D.8050306@bogus.com> In-Reply-To: <5092C84D.8050306@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:33:49 -0000 > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com] > Sent: Thursday, November 01, 2012 12:07 PM > To: Templin, Fred L > Cc: Joe Touch; Lorenzo Colitti; Fernando Gont; v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop >=20 > On 11/1/12 12:00 PM, Templin, Fred L wrote: > >>> The right way to deal with this is to rate-limit or drop on the > >>> routers. You're saying the architecture doesn't allow this? Then I'm > >>> sorry, but we need a better architecture. > >> The "right way" is to drop them at the offending source, but I hope we > >> all agree we cannot do that because there's no viable solution. > > Isn't ingress filtering the means by which packets are > > dropped as close to the offending source as possible? And, > > shouldn't ingress filtering be implemented by all legitimate > > sites? > Yeah so, I can clearly turn off all my ACLs because all my upstreams > will filter unwanted traffic for me when it enters their network... I posed the question facetiously - yet, wasn't "the plan" about a decade ago to push for ingress filtering at all sites? Have we given up on that? Thanks - Fred fred.l.templin@boeing.com > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From touch@isi.edu Thu Nov 1 12:58:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6921F9195 for ; Thu, 1 Nov 2012 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bckmSc0yHrWX for ; Thu, 1 Nov 2012 12:58:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 523CA21F914A for ; Thu, 1 Nov 2012 12:58:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA1JuiNO013058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 12:56:44 -0700 (PDT) Message-ID: <5092D3FC.2010902@isi.edu> Date: Thu, 01 Nov 2012 12:56:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sthaug@nethelp.no References: <5092C14B.7090704@isi.edu> <20121101.202416.112557190.sthaug@nethelp.no> In-Reply-To: <20121101.202416.112557190.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, draft-taylor-v6ops-fragdrop@tools.ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 19:58:36 -0000 On 11/1/2012 12:24 PM, sthaug@nethelp.no wrote: >> IMO, a router that looks beyond the IP headers is doing DPI. I realize >> others think DPI means looking at the E2E data. >> >> However, to avoid confusion, I'll just state that: >> >> - anything that looks only at an IP packet is a router >> >> - anything that looks at higher layer headers isn't a router anymore. it >> might be a firewall, filter, etc., and whether the box can do that at >> line rate is a question customers should ask their vendors, not a >> problem the IETF should solve. > > This looks like a nice theoretical classification that is rather useless > in practice. > > A modern router with multiple 10G interfaces (say a Juniper MX or Cisco > ASR9K) can be configured to look at higher layers. The primary function > of these routers is forwarding packets at high speeds. The fact that > these routers *can* look at higher layers is not going to make me stop > calling them routers. I don't think I'm alone here :-) Fine. Then either get your vendors - of whatever boxes you want to call them - to support the current option structure, or choose not to support IPv6. There are choices here. Joe From touch@isi.edu Thu Nov 1 13:04:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889E821F95F9 for ; Thu, 1 Nov 2012 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8kprIioq56z for ; Thu, 1 Nov 2012 13:04:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 12B9721F93B3 for ; Thu, 1 Nov 2012 13:04:33 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qA1K414i003995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 13:04:02 -0700 (PDT) Message-ID: <5092D5B1.2000201@isi.edu> Date: Thu, 01 Nov 2012 13:04:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> In-Reply-To: <5092C846.5090009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 20:04:33 -0000 On 11/1/2012 12:06 PM, Brian E Carpenter wrote: ... >> In the case of C, the router needs to keep looking at subsequent options >> until one of three things happens: >> >> 1. a known HBH option is seen >> indicating there are HBH options >> 2. a known E2E option is seen >> indicating there are no HBH options >> 3. there are no more options >> indicating there are no HBH options >> >> As a result, it's entirely possible that a router could need to parse >> the entire option chain before it can determine whether there are any >> HBH options. > > Yes, because of the point I just mentioned. That's a bug IMHO. > However, the observed problems come from middleboxes that don't > parse regular extension headers, not hbh option headers. Isn't the real bug the fact that the option numbers don't indicate whether an option is HBH or not? Joe From touch@isi.edu Thu Nov 1 13:05:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD821F9606 for ; Thu, 1 Nov 2012 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.432 X-Spam-Level: X-Spam-Status: No, score=-105.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8EKCgNQEJHt for ; Thu, 1 Nov 2012 13:05:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0821F9608 for ; Thu, 1 Nov 2012 13:05:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA1K26Re014292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 13:02:06 -0700 (PDT) Message-ID: <5092D53E.8000104@isi.edu> Date: Thu, 01 Nov 2012 13:02:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Templin, Fred L" References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5092BE93.9090809@isi.edu> In-Reply-To: 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: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 20:05:02 -0000 On 11/1/2012 12:00 PM, Templin, Fred L wrote: >>> The right way to deal with this is to rate-limit or drop on the >>> routers. You're saying the architecture doesn't allow this? Then I'm >>> sorry, but we need a better architecture. >> >> The "right way" is to drop them at the offending source, but I hope we >> all agree we cannot do that because there's no viable solution. > > Isn't ingress filtering the means by which packets are > dropped as close to the offending source as possible? And, > shouldn't ingress filtering be implemented by all legitimate > sites? The "most correct" way is to block them at the origin. Ingress filtering happens after that point. The former is not feasible, and so we do not pursue it. I claim that the latter is increasingly not feasible in a modern Internet either, due to the prevalence of secure tunnels. Joe From touch@isi.edu Thu Nov 1 13:21:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF021F96E9 for ; Thu, 1 Nov 2012 13:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.522 X-Spam-Level: X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCHgpn8ZpPc2 for ; Thu, 1 Nov 2012 13:21:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 47BBC21F96DD for ; Thu, 1 Nov 2012 13:21:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qA1KLRKs009644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 13:21:27 -0700 (PDT) Message-ID: <5092D9C7.9040409@isi.edu> Date: Thu, 01 Nov 2012 13:21:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joel Jaeggli References: <5092C14B.7090704@isi.edu> <20121101.202416.112557190.sthaug@nethelp.no> <5092D3FC.2010902@isi.edu> <48C09AC6-4068-4DEB-BFEF-26E1BED5305B@zynga.com> In-Reply-To: <48C09AC6-4068-4DEB-BFEF-26E1BED5305B@zynga.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: "" , "" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 20:21:43 -0000 On 11/1/2012 1:11 PM, Joel Jaeggli wrote: ... >> Then either get your vendors - of whatever boxes you want to call them - to support the current option structure, or choose not to support IPv6. > > That's not an operationally useful statement. Well, we had a third alternative in IPv4, which was to avoid options. I don't think that's a practical alternative here. What's more likely is that we'll start running IPv6 with fragmentation (and options) over IPv6 with no options just to get the fast-path processing. At that point, either operators will forward those packets and we have a badly busted Internet that exists only at the edges, or operators will toss all those packets because they can't inspect them, at which point we have a badly busted Internet. Continued insistence on looking inside IP packets will then result in no IPv6. > and it's not what's cooked into silicon by a number of companies that are well represented at the IETF. Sure, but it may be time to consider that their business model may be flawed if this is what they expect. >> There are choices here. > > Indeed, and the observable phenomena on the internet indicate what operators and their vendors arrived at indepedantly. Well, either this works or it kills IPv6. However, as I noted, the only realistic recommendation from this group is "it's OK to configure routers to drop all packets with any options". IMO that's not an appropriate position for an ops group to take, since it undermines an existing standard. So if options are being deprecated in IPv6, that needs (IMO) to be taken to intarea, not simply asserted here. Joe From prvs=645c476ba=jjaeggli@zynga.com Thu Nov 1 13:11:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8721F9637 for ; Thu, 1 Nov 2012 13:11:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftMk8YZNSkaO for ; Thu, 1 Nov 2012 13:11:53 -0700 (PDT) Received: from c7-ip02.zynga.com (c7-ip02.zynga.com [72.5.237.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0B32821F9631 for ; Thu, 1 Nov 2012 13:11:53 -0700 (PDT) Authentication-Results: c7-ip02.corp.zynga.com; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=10.101.0.38; receiver=c7-ip02.corp.zynga.com; envelope-from="jjaeggli@zynga.com"; x-sender="jjaeggli@zynga.com"; x-conformance=sidf_compatible.downgrade_pra Received-SPF: Pass identity=mailfrom; client-ip=10.101.0.38; receiver=c7-ip02.corp.zynga.com; envelope-from="jjaeggli@zynga.com"; x-sender="jjaeggli@zynga.com"; x-conformance=sidf_compatible.downgrade_pra; x-record-type="v=spf1" Received-SPF: None identity=helo; client-ip=10.101.0.38; receiver=c7-ip02.corp.zynga.com; envelope-from="jjaeggli@zynga.com"; x-sender="postmaster@C7-EX-CASHT01.corp.zynga.com"; x-conformance=sidf_compatible.downgrade_pra Received: from c7-ex-casht01.corp.zynga.com ([10.101.0.38]) by c7-ip02.corp.zynga.com with ESMTP; 01 Nov 2012 13:11:52 -0700 Received: from C7-EX-MAIL02.corp.zynga.com ([fe80::d4d:df70:ccb7:16db]) by C7-EX-CASHT01.corp.zynga.com ([::1]) with mapi id 14.01.0355.002; Thu, 1 Nov 2012 13:11:52 -0700 From: Joel Jaeggli To: Joe Touch Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop Thread-Index: AQHNq5wf84m0GKx0106nyUn/qEDQIJe8s9wAgAABjYCAAATUAIAAAHaAgAABbACAAD0fAIAADlEAgAD23oCAABrRgIAAZZwAgAAMGQCAAALJAIAAAuoAgAE/FICAFJxhgIAABmwAgAA9FYCAAASGgIAAAhgAgAEnp4CAAA02AIAACRIAgAAEOYA= Date: Thu, 1 Nov 2012 20:11:51 +0000 Message-ID: <48C09AC6-4068-4DEB-BFEF-26E1BED5305B@zynga.com> References: <5092C14B.7090704@isi.edu> <20121101.202416.112557190.sthaug@nethelp.no> <5092D3FC.2010902@isi.edu> In-Reply-To: <5092D3FC.2010902@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.6.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <551B360096E8BD48956D3E60A6A85940@zynga.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 01 Nov 2012 13:25:29 -0700 Cc: "" , "" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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 Nov 2012 20:11:54 -0000 On Nov 1, 2012, at 12:56 PM, Joe Touch wrote: >=20 >=20 > On 11/1/2012 12:24 PM, sthaug@nethelp.no wrote: >>> IMO, a router that looks beyond the IP headers is doing DPI. I realize >>> others think DPI means looking at the E2E data. >>>=20 >>> However, to avoid confusion, I'll just state that: >>>=20 >>> - anything that looks only at an IP packet is a router >>>=20 >>> - anything that looks at higher layer headers isn't a router anymore. i= t >>> might be a firewall, filter, etc., and whether the box can do that at >>> line rate is a question customers should ask their vendors, not a >>> problem the IETF should solve. >>=20 >> This looks like a nice theoretical classification that is rather useless >> in practice. >>=20 >> A modern router with multiple 10G interfaces (say a Juniper MX or Cisco >> ASR9K) can be configured to look at higher layers. The primary function >> of these routers is forwarding packets at high speeds. The fact that >> these routers *can* look at higher layers is not going to make me stop >> calling them routers. I don't think I'm alone here :-) >=20 > Fine. not really it isn't. What got me down this rathole was l3+l4 hashing. > Then either get your vendors - of whatever boxes you want to call them - = to support the current option structure, or choose not to support IPv6. That's not an operationally useful statement. and it's not what's cooked in= to silicon by a number of companies that are well represented at the IETF. > There are choices here. Indeed, and the observable phenomena on the internet indicate what operator= s and their vendors arrived at indepedantly.=20 > Joe=20 From diego@tid.es Thu Nov 1 16:53:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9602B21F8B6E for ; Thu, 1 Nov 2012 16:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACOybDYJdpt9 for ; Thu, 1 Nov 2012 16:53:07 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4E3721F8B6C for ; Thu, 1 Nov 2012 16:53:06 -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 <0MCU00KLO2CHM8@tid.hi.inet> for v6ops@ietf.org; Fri, 02 Nov 2012 00:53:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id AD.E9.03143.16B03905; Fri, 02 Nov 2012 00:53:05 +0100 (CET) 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 ESMTPS id <0MCU00KLK2CHM8@tid.hi.inet> for v6ops@ietf.org; Fri, 02 Nov 2012 00:53:05 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Fri, 02 Nov 2012 00:53:05 +0100 Date: Thu, 01 Nov 2012 23:53:04 +0000 From: "Diego R. Lopez" In-reply-to: <2671C6CDFBB59E47B64C10B3E0BD59230336CAEB6B@PRVPEXVS15.corp.twcable.com> X-Originating-IP: [10.95.64.115] To: "George, Wes" 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 Thread-topic: New version of draft-lopez-v6ops-dc-ipv6 Thread-index: AQHNr3M8j4EugeD3fkKjjO1OoT0HCJfLpGbAgAZT1YCAAaq+sIACBWyA X-AuditID: 0a5f4068-b7f746d000000c47-62-50930b61971d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe/ApZvIPTnA4NRjLYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/3mT+wFa/Qrlh7rZWlgnKDXxcjJISFgInFw11ZmCFtM4sK9 9WxdjFwcQgIbGCV6/k1jh3B+MErM7V7PDOFMY5S4dPMaC0gLi4CqxJ0FzYwgNhuQ/aj5NzuI LSxgKjHt5zTWLkYODk6BcInrG5wgNihI/Dn3GKxVREBXYtuDg2CbmYHibe/awcbwCnhLbO86 xwoRN5N4P3c9M0RcUOLH5HssICOZBdQlpkzJhSgRl2huvckCYStKTFvUADaGEeiZ76fWMEGs MpNYcmUDI0iriICbxP1fRhDXCEgs2XMe6ndRiZeP/7FCfHibSWLr11OMExglZiG5YhaSK2Yh XDELyRWzkFyxgJF1FaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSMxl7GBcvlPlEKMAB6MS D++L75MChFgTy4orcw8xSnIwKYny7uKcHCDEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPf4CqBy 3pTEyqrUonyYlAwHh5IE70YuoDbBotT01Iq0zBxgYoFJM3FwgrTzALUXgdTwFhck5hZnpkPk TzFKSonzHgBJCIAkMkrz4HpfMYoDHSnMOwskywNMgXBdr4AGMgENVLGYCDKwJBEhJdXAmGQS 1nnrFivfVKme1F9hqrJMFjtbGEs0nuvMcHC9/OvXUe7zEheEq+L4FrcUx870vhcw0adosk2A em6R616THxOW5BVN/vNAvWf22xSuZ2UG2qsLq86cYv5WXcoX915fYn810zWWKdsXfvfrvfDw jceUPUK7UsNl/d+65yxJ/3PayKzfQcNciaU4I9FQi7moOBEA94ztsT4DAAA= References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59230336A87C8B@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230336CAEB6B@PRVPEXVS15.corp.twcable.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] New version of draft-lopez-v6ops-dc-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: Thu, 01 Nov 2012 23:53:08 -0000 SGkgV2VzLA0KDQpPbiAzMSBPY3QgMjAxMiwgYXQgMTc6MTAgLCBHZW9yZ2UsIFdlcyB3cm90ZToN Cj4+IFRoaXMgaXMgYSBnb29kIHBvaW50LCB0aG91Z2ggSSB0aGluayB3ZSBzaG91bGQgYWdyZWUg aW4gbGltaXRpbmcgdGhlDQo+PiBudW1iZXIgb2Ygc3VjaCBpdGVtcywgYW5kIGNsZWFybHkgaWRl bnRpZnkgaG93IHRoZSBhcHBsaWNhdGlvbiBvZiB2Ng0KPj4gYWZmZWN0IHRoZW0gYW5kIGluIHdo aWNoIHJlc3BlY3QgdGhleSBhcmUgc3BlY2lmaWMgdG8gdGhlIERDDQo+PiBlbnZpcm9ubWVudC4g Q2VydGFpbmx5IG1hbmFnZW1lbnQgc3lzdGVtcyBhcmUsIGFzIGNvbnNpZGVyYXRpb25zIG9uIHRo ZQ0KPj4gZmFicmljIGFuZCBoeXBlcnZpc29ycy4NCj4gW1dFR10gWWVzLiBUaGF0J3MgYSBnb29k IHRlc3QgdG8gdXNlLiBUaGVyZSdzIGEgbG90IG9mIHJpc2sgaW4gZ2V0dGluZyB0b28gc3BlY2lm aWMgYW5kIHRvIHNwZWNpYWxpemVkIGhlcmUsIHNvIGZlZWRiYWNrIGZyb20gREMgb3BlcmF0b3Jz IG9uIGEgc2V0IG9mIGNhdGVnb3JpZXMgdGhhdCBtYWtlIHNlbnNlIHdpbGwgYmUgdmVyeSBoZWxw ZnVsLg0KDQpTbyBJIHRoaW5rIHdlIGFyZSBpbiBhZ3JlZW1lbnQgaGVyZS4gTGV0J3Mgc2F5IHRo YXQgd2UgZmluZCB0aGF0DQpjb25zaWRlcmF0aW9ucyBvbiB0aGUgZm9sbG93aW5nIGl0ZW1zIHNo b3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZHJhZnQ6DQoqIE1hbmFnZW1lbnQgc3lzdGVtcw0KKiBG YWJyaWMNCiogSHlwZXJ2aXNvcnMNCiogRWFzdC13ZXN0IGNvbW11bmljYXRpb25zIChzZWUgYmVs b3cpDQoNCkFuZCBjb21tZW50cyBmcm9tIERDIG9wZXJhdG9ycywgdG8ga25vdyB3aGV0aGVyIHRo ZXkgZmluZCB0aGlzIGxpc3QNCnN1ZmZpY2llbnQgb3IgbG9uZ2VyIHRoYW4gcmVxdWlyZWQsIGFu ZCB3aGljaCBpdGVtcyB0aGV5J2QgbGlrZSB0byBzZWUNCmFkZGVkIG9yIHJlbW92ZWQgd2lsbCBi ZSBleHRyZW1lbHkgd2VsY29tZS0NCg0KSSdsbCBpbmNsdWRlIGEgcmVmbGVjdGlvbiBvbiB0aGlz IGluIHRoZSBzbGlkZXMgdG8gYmUgZGlzY3Vzc2VkIGluIEF0bGFudGENCg0KPj4gSW4gdGhlIGNh c2Ugb2YgZW5kLXVzZXIgYXBwbGljYXRpb25zIGFuZCBjb250ZW50IEkgdGhpbmsgdGhleSBhcmUg bW9zdGx5DQo+PiBjb25zaWRlcmVkIGluIG90aGVyIG9wZXJhdGlvbmFsIGd1aWRlbGluZTogKGRy YWZ0LWNoa3B2Yy1lbnRlcnByaXNlLQ0KPj4gaW5jcmVtZW50YWwtaXB2NikgYW5kIHdlIGNvdWxk IGZvbGxvdyBhbiBhcHByb2FjaCBzaW1pbGFyIHRvIHRoZSB1c2VkIGluDQo+PiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMuDQo+Pg0KPj4gV2hlbiBpdCBjb21lcyB0byBNMk0gYW5kIGV4dGVy bmFsIHNlcnZpY2VzLCBJJ2QgbGlrZSB0byBoYXZlIGEgY2xlYXJlcg0KPj4gaWRlYSBvZiB3aGF0 IHlvdSBhcmUgcmVmZXJyaW5nIHRvLi4uDQo+Pg0KPiBbV0VHXSBJIGNhbiB0cnkgdG8gY2xhcmlm eSBhIGJpdCAtDQo+IE0yTSAtIEF0IGxlYXN0IGluIG15IGNvbXBhbnkncyBzeXN0ZW1zLCBoYXZl IGEgZmFpcmx5IG1vZHVsYXIgZGVzaWduIHRvIHRoZSBhcHBsaWNhdGlvbnMgdGhhdCB3ZSB1c2Us IHNvIHdlIGVuZCB1cCB3aXRoIGEgbG90IG9mIGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgb25lIHNl dCBvZiBmdW5jdGlvbnMsIGJ1dCBtYWtlIEFQSSBjYWxscyB0byBvdGhlciBhcHBsaWNhdGlvbnMg d2l0aGluIHRoZSBkYXRhIGNlbnRlciBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aGF0IHRo ZXkgcmVxdWlyZSB0byBjb21wbGV0ZSB0aGVpciBpbnRlbmRlZCBmdW5jdGlvbi4gVGhlc2UgbWFj aGluZS10by1tYWNoaW5lIGNvbW11bmljYXRpb25zIGFyZSBhIGdvb2QgcGxhY2UgdG8gZXhwZXJp bWVudCB3aXRoIG1vdmluZyB0byBJUHY2LCBlc3BlY2lhbGx5IHdoZW4geW91IGhhdmUgY29udHJv bCBvdmVyIGJvdGggb2YgdGhlIGFwcGxpY2F0aW9ucyAodnMgb25lIHdoZXJlIHlvdSdyZSBtYWtp bmcgY2FsbHMgdG8gYW4gQVBJIG9uIGFuIGV4dGVybmFsbHkgbWFuYWdlZCBzeXN0ZW0gZm9yIGV4 YW1wbGUpLiBUaGlzIGlzIGJlY2F1c2UgYXNzdW1pbmcgeW91IGhhdmUgYW4gSVB2Ni1jYXBhYmxl IGZhYnJpYyBpbiBwbGFjZSwgYW5kIHRoZSB1bmRlcmx5aW5nIFZNIGluZnJhc3RydWN0dXJlIHN1 cHBvcnRzIElQdjYsIGl0IG1heSBiZSBhcyBzaW1wbGUgYXMgY2hhbmdpbmcgYSBmZXcgRE5TIGVu dHJpZXMgdG8gYWRkIEFBQUEgcmVjb3JkcywgYW5kIHRoZSB0cmFmZmljIGdvaW5nIGJldHdlZW4g dGhlc2UgYXBwbGljYXRpb25zIHdpbGwgYmVnaW4gdXNpbmcgSVB2NiBpbiBhIHdheSB0aGF0IGlz IHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkIGZyb20gYSBjb250cm9sIGFuZCByb2xsb3V0IHBl cnNwZWN0aXZlIGJlY2F1c2UgeW91IGFyZSBub3QgZGVhbGluZyB3aXRoIHRoZSB2YXJpYWJsZSB0 aGF0IGFueSBzb3J0IG9mIGh1bWFuIHVzZXIgbWlnaHQgaW50cm9kdWNlIC0gaXQncyB0d28gYXBw bGljYXRpb25zIHRhbGtpbmcgdG8gb25lIGFub3RoZXIgZGlyZWN0bHkuIEl0IGlzIHdvcnRoIG5v dGluZyB0aGF0IGluIHNvbWUgY2FzZXMgdGhlc2UgYXJlIG5vdCBuZWNlc3NhcmlseSBjb250YWlu ZWQgY29tcGxldGVseSB3aXRoaW4gb25lIGRhdGFjZW50ZXIsIHNvIHlvdSBjb3VsZCBtYWtlIGEg ZGlzdGluY3Rpb24gYmV0d2VlbiB0aG9zZSB0aGF0IHN0YXkgd2l0aGluIGEgc2luZ2xlIGRhdGEg Y2VudGVyIHZzIHRob3NlIHRoYXQgbXVzdCBjb21tdW5pY2F0ZSBiZXR3ZWVuIGRhdGFjZW50ZXJz Lg0KPiBFeHRlcm5hbCBzZXJ2aWNlcyByZWZlcnMgdG8gYW55IHNvcnQgb2YgYXBwbGljYXRpb25z IHRoYXQgYXJlIHByb3ZpZGluZyBzZXJ2aWNlcyBjb25zdW1lZCBvdXRzaWRlIG9mIHRoZSBkYXRh Y2VudGVyICh2cyB0aG9zZSBsaWtlIEkgb3V0bGluZWQgYWJvdmUpLg0KPiBIb3BlZnVsbHkgdGhh dCBoZWxwcy4gSSBrbm93IHRoYXQgTTJNIGlzIGFsc28gYW4gb3ZlcmxvYWRlZCB0ZXJtLCBhbmQg SSBkaWRuJ3QgZXhhY3RseSB1c2UgaXQgaW4gdGhlIHRyYWRpdGlvbmFsIHNlbnNlLCBzbyBJIGFw b2xvZ2l6ZSBmb3IgYW55IGNvbmZ1c2lvbiBJIG1heSBoYXZlIGNhdXNlZC4NCg0KQXMgc2FpZGUg YWJvdmUsIHRoZSB0ZXJtIEknZCB1c2UgZm9yIHJlZmVycmluZyB0byB0aGlzIGtpbmQgb2YgZXhj aGFuZ2VzDQppcyBFYXN0LVdlc3QgY29tbXVuaWNhdGlvbiAob3IgIkVhc3QtYm91bmJkIGludGVy ZmFjZXMiIG9yIHNpbWlsYXIgdGVybXMpLA0KdG8gZGVub3RhdGUgdGhhdCB0aGV5IHJ1biBpbiBh biBob3Jpem9udGFsIHBhdHRlcm4gYWNjcm9zcyB0aGUgdHlwaWNhbA0KcmVwcmVzZW50YXRpb24g b2YgYSBEQyBmYWJyaWMsIGluIGNvbnRyYXN0IHdpdGggdGhlIGNvbW11bmljYXRpb25zIHdpdGgN Cm9yaWdpbiBhbmQvb3IgZGVzdGluYXRpb24gb3V0c2lkZSBvZiB0aGUgREMgdGhhdCBpcyBub3Jt YWxseSByZWZlcnJlZCBhcw0KIk5vcnRoLWJvdW5kIGNvbW11bmljYXRpb24iIG9yIHNpbWlsYXIg dGVybXMuDQoNClNvIGlmIHdlIGFncmVlIG9uIHRoZSB0ZXJtaW5vbG9neSwgSSBjZXJ0YWlubHkg YWdyZWUgaW4gdGhhdCBzb21lIG1vcmUNCmRldGFpbGVkIGRpc2N1c3Npb24gb24gdGhpcyB3b3Vs ZCBhZGQgdG8gdGhlIGRyYWZ0IGNvbnRlbnRzLiBJbiBmYWN0LCBhIGZldw0KbWVudGlvbnMgdG8g dGhpcyBhcmUgc2NhdHRlcmVkIGFjcm9zcyB0aGUgdGV4dCwgaW4gYSBzaW1pbGFyIHdheSBhcyBp dCBoYXBwZW5zDQp3aXRoIGh5cGVydmlzb3JzLg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZl eiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpU ZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFp bDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgy IDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmln ZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0 cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmlj byBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVu ZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2Vp dmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3 dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From brian.e.carpenter@gmail.com Fri Nov 2 01:17:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983F321F999F for ; Fri, 2 Nov 2012 01:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV7CG+I9CQ2q for ; Fri, 2 Nov 2012 01:17:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1462821F99AB for ; Fri, 2 Nov 2012 01:17:43 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1579768wgb.13 for ; Fri, 02 Nov 2012 01:17:43 -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=QhNOY6ewc0BSq6pipl0gI9yBjPWgZKsOsKzM+vgq02s=; b=iS+S1b+ahsiGU5gaazVjV1soUI/rLTBkFuI4KSyHz3UxYPlURcf8UlS6myXZv+XAu7 Y2t+TUNJe21wJrUQVEX3rX+AellsMOJF5IA9jY5VSU9XpIEWiDusW4/dzf5IO2uV1ZTu 0kwtIf41ODf9jGEg06gj9BRdmhY825olzD3mVkWInKRf3Ip8HGwZwoqlro2cGGMJBMvN LZvKbJoZxufmAULvNrU1dkDtsPy/eiHuv9zcJFnAUpdTvwUROD60hP/atxjmkYL7S85w gbCnMLFHq4XSnOysuvtnhjgP3/8mRI3OUt7n6w53zdED+spvCQeA0BOMSkvotFRdtSXS TBcQ== Received: by 10.180.87.230 with SMTP id bb6mr1540518wib.6.1351844263195; Fri, 02 Nov 2012 01:17:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-241.as13285.net. [2.102.219.241]) by mx.google.com with ESMTPS id dm3sm1479685wib.3.2012.11.02.01.17.41 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 01:17:42 -0700 (PDT) Message-ID: <509381B3.9040602@gmail.com> Date: Fri, 02 Nov 2012 08:17:55 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> In-Reply-To: <5092D5B1.2000201@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2012 08:17:46 -0000 On 01/11/2012 20:04, Joe Touch wrote: > > > On 11/1/2012 12:06 PM, Brian E Carpenter wrote: > ... >>> In the case of C, the router needs to keep looking at subsequent options >>> until one of three things happens: >>> >>> 1. a known HBH option is seen >>> indicating there are HBH options >>> 2. a known E2E option is seen >>> indicating there are no HBH options >>> 3. there are no more options >>> indicating there are no HBH options >>> >>> As a result, it's entirely possible that a router could need to parse >>> the entire option chain before it can determine whether there are any >>> HBH options. >> >> Yes, because of the point I just mentioned. That's a bug IMHO. >> However, the observed problems come from middleboxes that don't >> parse regular extension headers, not hbh option headers. > > Isn't the real bug the fact that the option numbers don't indicate > whether an option is HBH or not? Why is that a problem? The extension header that contains the options tells you that (0 for hbh options, 60 for destination options). Brian From touch@isi.edu Fri Nov 2 06:50:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F03D21F884B for ; Fri, 2 Nov 2012 06:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+fOI-QMe3YF for ; Fri, 2 Nov 2012 06:50:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFD721F8835 for ; Fri, 2 Nov 2012 06:50:31 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA2DnLfq022269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Nov 2012 06:49:31 -0700 (PDT) Message-ID: <5093CF61.9090301@isi.edu> Date: Fri, 02 Nov 2012 06:49:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> In-Reply-To: <509381B3.9040602@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2012 13:50:33 -0000 Hi, Brian, On 11/2/2012 1:17 AM, Brian E Carpenter wrote: ... >> Isn't the real bug the fact that the option numbers don't indicate >> whether an option is HBH or not? > > Why is that a problem? The extension header that contains the options > tells you that (0 for hbh options, 60 for destination options). Except for extension headers that are yet to be defined. I.e., while you're fixing the order, another key issue is that: all HBH options MUST occur only in the HBH extension header (similarly, 60 isn't strictly the only destination header; see esp. the end of Sec. 4.6, but that is much less problematic) Frankly, the HBH extension header is misnamed; AFAICT, this is intended to be the true forwarding plane options. Other other currently defined options (AFAICT), including the routing option, occur only when the router is really acting as a host (i.e., where that router owns the destination IP address of the packet). Joe From phdgang@gmail.com Fri Nov 2 15:13:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1E11E80E1 for ; Fri, 2 Nov 2012 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8PsPGYw3l7q for ; Fri, 2 Nov 2012 15:13:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6234711E80DF for ; Fri, 2 Nov 2012 15:13:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4750109vbb.31 for ; Fri, 02 Nov 2012 15:13:15 -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=Mwd/dVpcur7q1eF6g/5ENSHslLN2So4hr43SwsbNWXE=; b=e+7KF67Fve4V+YyYUfHEBvbO/xn2DmOQM1URZff0wbdqjMc5+ezj6KyhY7ZwqJssm5 k7vgo6FD+NvAsXwt+YYWLnn+FjXi9tb9e8cmqxBkJyRsbPWeHkS5T/xnPdBiunD7nshU zUQg54RN3aYRQEq8S//JsYSN1P+/Ls2+d5qGKp4ZRxA4KEAACoPqV5gii6c47FXK6kA8 Mb+eviNM1mZxtGq6l1Eo9Latn2UxRa4XpD/wI5/MO/5ufqe9l6VS6RyjzucK11t5Z0gb o1JvB0Z6gOM5qKordhDucq3v8NWBoh9HmfSMox/g1se7FjA0oqbz2AJrkVgTtet4l5GA HMjg== MIME-Version: 1.0 Received: by 10.58.186.147 with SMTP id fk19mr3331060vec.13.1351894395528; Fri, 02 Nov 2012 15:13:15 -0700 (PDT) Received: by 10.58.44.10 with HTTP; Fri, 2 Nov 2012 15:13:15 -0700 (PDT) In-Reply-To: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> References: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> Date: Sat, 3 Nov 2012 06:13:15 +0800 Message-ID: From: GangChen To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org list" , draft-ietf-v6ops-nat64-experience@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-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, 02 Nov 2012 22:13:21 -0000 Hi Philip, 2012/11/1, Philip Matthews : > Hi authors: > > I read your draft with interest. I need to re-read it more carefully, but > here are some preliminary comments: > > 1) The title of the draft is "NAT64 Operational Experiences", but I feel the > draft reads much more like "NAT64 Deployment Considerations". I didn't see > any place where the draft says "This is what we did and it worked well (or > it didn't work well)". That is, it is not really relating the specific > experience of an operator in deploying NAT64 so much as describing things > that an operator should take into account when planning their own NAT64 > deployment. Thanks for the comments. Regarding the word of "Experiences", I searched the definition from a dictionary. It usually refers to "knowledge or practical wisdom gained from what one has observed, encountered, or undergone". It's true it involves a particular instance of encountering or undergoing something. Whereas, we didn't describe such particular behavior (what we did), since the texts seems to be time-sensitive. It tends to be ephemeral as a documented output in RFC. So it may be more effective/worthwhile to discuss generalized knowledge/problems being addressed in the document. We are still opening on this point. I guess that is only the matter of structuring texts > 2) Section 3.1 has the sentence: > It is advantageous from the vantage-point of > troubleshooting and traffic engineering to carry the IPv6 traffic > natively for as long as possible within an access network and > translates only at or near the network egress. > I think it would be interesting and helpful to say more about why you feel > this is true. Can you give some specific examples? In our practices, NAT64 is positioned on the location of border routers. As you mentioned, the reason for that is for cost reasons. Other gains are simplification of traceability and network provisioning in one network domain. AFAIK, the cases are also shared by other operators in the author list. > Though today I suspect > most operators will try to centralize their NAT64 boxes for cost reasons, I > can see in the future an operator that is forced to go pure IPv6 and is > planning a large rollout, and will be worried that centralizing NAT64 will > not scale well and will thus consider pushing NAT64 to closer to the > customer. The concerns were actually discussed when we do the network planning. One point is native IPv6 communications would bypass the NAT64. Those traffic offload on NAT64 should be encouraged if an operator is forced to go pure IPv6. In some sense, the concerns of scalability on NAT64 may be alleviated. > 3) Section 3.2 on HA Considerations has the sentence: > Given that short > lived sessions account for most of the bindings, hot-standby does not > offer much benefit for those sessions. > Just curious if you have evidence or a reference that backs up this claim? Statistic of service traffic in a mobile network could be the evidence depending on the colleted data. Most traffic (almost 94% of amount of traffic) is accounted by Http, WAP browsing, which are short lived sessions. > This is certainly frequently stated for NAT44, but I haven't seen hard facts > in the case of NAT64. I am especially wondering if the fact that some > traffic (like DNS traffic and native IPV6 traffic) doesn't go through the > NAT64 would change the situation from the NAT44 case. I guess the situation on NAT64 is similar with NAT44, since all IPv4 connections to the IPv4 Internet from IPv6-only clients must traverse the NAT64. > 4) The draft is currently organized so that section 3 discusses the > NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE > case. I suggest you consider organizing the draft differently, so that you > have a series of sections discussing a topic (e.g Load Balancing or MTU), > and within the section you first discuss the NAT64-CGN case and then the > NAT64-CPE case. I suggest that this would allow you to discuss each topic > more fully, and would emphasis the similarities or differences between the > CGN and CPE cases. Just a suggestion. Thanks for the suggestions. Some texts in same topics for NAT64-CGN and -CE could be structured. Yet, there are also different topics regarding to -CGN and -CE, which is hardly organized in such way. BTW, the term "CE" is likely confused with CPE. What we indicated is actually a load-balancer in front of enterprise network, e.g. data center. If the group agree, we intend to rename it as "Front End" to precisely indicate the meaning. Best Regards Gang > - Philip > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Fri Nov 2 18:27:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18D911E8101 for ; Fri, 2 Nov 2012 18:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.655 X-Spam-Level: X-Spam-Status: No, score=-101.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THxtP9Q2rKCb for ; Fri, 2 Nov 2012 18:27:16 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 62E4211E80A3 for ; Fri, 2 Nov 2012 18:27:16 -0700 (PDT) Received: from dhcp-413c.meeting.ietf.org ([130.129.65.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qA31R1kQ084347 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 01:27:08 GMT (envelope-from joelja@bogus.com) Message-ID: <5094269F.3000705@bogus.com> Date: Fri, 02 Nov 2012 13:01:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> In-Reply-To: <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 03 Nov 2012 01:27:10 +0000 (UTC) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2012 01:27:17 -0000 On 11/1/12 4:16 AM, Ole Trøan wrote: >>>>> Yes, but the whole point of the IPv6 option architecture was to avoid >>>>> the issues seen with IPv4 options. >>>> The only thing in that IPv6 would avoid is requiring routers to parse >>>> *all* options, just to find the ones that need to be processed by >>>> routers. >>> Yes. >> No. The only extension header that *needs* to be parsed by intermediate >> routers is the hop-by-hop options header, and that is the first one (if >> present). >> >> (You can legitimately argue that the hbh header and the routing header >> are effectively useless, but that doesn't break fundamental connectivity.) >> >> IPv6 routers should have nothing to do with fragmentation. That horse left the barn when we use L4 headers as part of a load-balancing hash key. While the potential for reordering due to differing path selection is superficially irrelevant in the core (I do have four 4 ECMPed cross-country paths in the US with about 12ms difference in rtt between the shortest and longest), when fronting a stateful device like load balancer(s) or firewall(s) it is not. Now, if the flow label were reliably immutable and non-zero it might be a suitable replacement for the L4 header in the hash calculation. >> >> The problem is due to middleboxes that break the IPv6 spec by inspecting >> any part of the packet beyond the hop-by-hop header and discarding what >> they don't understand. > > quite. > what stops these boxes from filtering IPsec, TLS, or anything that isn't HTTP with a > whitewashed URL? So, I'm providing service to an application we are generally inclined to limit the service area exposed on the application, which I think of a pretty good fit for L4-leveraging stateless ACLS. > > I don't see how we can build protocols to accommodate middle boxes, and > we have already done RFC3514. Nor do i think it's likely that we'll come to a great deal of consensus on "you absolutely cannot use L4 headers in forwarding filtering calculations." it's pretty clear from modern router platforms that customers demand those. What I think we can do is document the observance of the phenomenon, acknowledge what gets broken as a result, and perhaps provide advice that limits the scope of the damage. > cheers, > Ole > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sat Nov 3 00:38:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBF21F84E1 for ; Sat, 3 Nov 2012 00:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.343 X-Spam-Level: X-Spam-Status: No, score=-101.343 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX1WMiK+aL6j for ; Sat, 3 Nov 2012 00:38:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE321F9C8E for ; Sat, 3 Nov 2012 00:38:05 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2009303wgb.13 for ; Sat, 03 Nov 2012 00:38:05 -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=0+LuZ9qy+zQQ14f+Mo+PfAtlAmsBevbYrORcXVZHDVo=; b=mz/8FO2u+mBpcDQ6k0CgBMwTkLGu2LgEkt0nlmlPDaI80Y6VJvWpXUBcp83ZNnVnSN yWbpd/IV+LQajt4iX6Cah0W7ZrLaMTvjf+7kkZ9wE/4JUshbU+mYO4hJuLXUsSVZ7xN4 1yWahxiRFSUS8PYMHlB6x8TGeufxCUzyOurhpTyB4ptKqKEeGiW69o1py5GgKoqNbfU1 3iqFDgmA1ZHb5UzjuIP/xoTwckdNg+GznHg+NeKBCG86Qtq1DTHpfBto6as8Zdj33W13 3OWVqbUKSd95eEr72diHCcATdyLseolDhR9SUetsG4euU23qxyMdkgmwMZEm4pLFigO1 gzMg== Received: by 10.216.70.13 with SMTP id o13mr1472196wed.184.1351928284567; Sat, 03 Nov 2012 00:38:04 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-217-116.as13285.net. [2.102.217.116]) by mx.google.com with ESMTPS id dt9sm1318536wib.1.2012.11.03.00.38.02 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 00:38:03 -0700 (PDT) Message-ID: <5094C9E7.4030306@gmail.com> Date: Sat, 03 Nov 2012 07:38:15 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> In-Reply-To: <5094269F.3000705@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2012 07:38:13 -0000 On 02/11/2012 20:01, joel jaeggli wrote: > On 11/1/12 4:16 AM, Ole Tr=C3=B8an wrote: >>>>>> Yes, but the whole point of the IPv6 option architecture was to av= oid >>>>>> the issues seen with IPv4 options. >>>>> The only thing in that IPv6 would avoid is requiring routers to par= se >>>>> *all* options, just to find the ones that need to be processed by >>>>> routers. >>>> Yes. >>> No. The only extension header that *needs* to be parsed by intermedia= te >>> routers is the hop-by-hop options header, and that is the first one (= if >>> present). >>> >>> (You can legitimately argue that the hbh header and the routing heade= r >>> are effectively useless, but that doesn't break fundamental >>> connectivity.) >>> >>> IPv6 routers should have nothing to do with fragmentation. > That horse left the barn when we use L4 headers as part of a > load-balancing hash key. >=20 > While the potential for reordering due to differing path selection is > superficially irrelevant in the core (I do have four 4 ECMPed > cross-country paths in the US with about 12ms difference in rtt between= > the shortest and longest), when fronting a stateful device like load > balancer(s) or firewall(s) it is not. >=20 > Now, if the flow label were reliably immutable and non-zero it might be= > a suitable replacement for the L4 header in the hash calculation. So, ask your suppliers to implement RFC 6437/6438. It's the best we can d= o. Brian >=20 >>> >>> The problem is due to middleboxes that break the IPv6 spec by inspect= ing >>> any part of the packet beyond the hop-by-hop header and discarding wh= at >>> they don't understand. >> >> quite. >> what stops these boxes from filtering IPsec, TLS, or anything that >> isn't HTTP with a >> whitewashed URL? > So, I'm providing service to an application we are generally inclined t= o > limit the service area exposed on the application, which I think of a > pretty good fit for L4-leveraging stateless ACLS. >> >> I don't see how we can build protocols to accommodate middle boxes, an= d >> we have already done RFC3514. > Nor do i think it's likely that we'll come to a great deal of consensus= > on "you absolutely cannot use L4 headers in forwarding filtering > calculations." it's pretty clear from modern router platforms that > customers demand those. >=20 > What I think we can do is document the observance of the phenomenon, > acknowledge what gets broken as a result, and perhaps provide advice > that limits the scope of the damage. >> cheers, >> Ole >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 From joelja@bogus.com Sat Nov 3 05:41:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDA221F981A for ; Sat, 3 Nov 2012 05:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtsAmYEsfpPd for ; Sat, 3 Nov 2012 05:41:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B50D221F976D for ; Sat, 3 Nov 2012 05:41:09 -0700 (PDT) Received: from dhcp-413c.meeting.ietf.org ([130.129.65.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qA3Cf2JO090804 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 3 Nov 2012 12:41:03 GMT (envelope-from joelja@bogus.com) Message-ID: <509510DD.9050909@bogus.com> Date: Sat, 03 Nov 2012 08:41:01 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> In-Reply-To: <5094C9E7.4030306@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 03 Nov 2012 12:41:04 +0000 (UTC) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2012 12:41:10 -0000 On 11/3/12 3:38 AM, Brian E Carpenter wrote: > On 02/11/2012 20:01, joel jaeggli wrote: >> On 11/1/12 4:16 AM, Ole Trøan wrote: >>>>>>> Yes, but the whole point of the IPv6 option architecture was to avoid >>>>>>> the issues seen with IPv4 options. >>>>>> The only thing in that IPv6 would avoid is requiring routers to parse >>>>>> *all* options, just to find the ones that need to be processed by >>>>>> routers. >>>>> Yes. >>>> No. The only extension header that *needs* to be parsed by intermediate >>>> routers is the hop-by-hop options header, and that is the first one (if >>>> present). >>>> >>>> (You can legitimately argue that the hbh header and the routing header >>>> are effectively useless, but that doesn't break fundamental >>>> connectivity.) >>>> >>>> IPv6 routers should have nothing to do with fragmentation. >> That horse left the barn when we use L4 headers as part of a >> load-balancing hash key. >> >> While the potential for reordering due to differing path selection is >> superficially irrelevant in the core (I do have four 4 ECMPed >> cross-country paths in the US with about 12ms difference in rtt between >> the shortest and longest), when fronting a stateful device like load >> balancer(s) or firewall(s) it is not. >> >> Now, if the flow label were reliably immutable and non-zero it might be >> a suitable replacement for the L4 header in the hash calculation. > So, ask your suppliers to implement RFC 6437/6438. It's the best we can do. Unfortunately I have a network to run in the interim. > Brian > > From randy@psg.com Sat Nov 3 05:58:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C3621F994D for ; Sat, 3 Nov 2012 05:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRpcCWTqaDi7 for ; Sat, 3 Nov 2012 05:58:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CF9AE21F98B6 for ; Sat, 3 Nov 2012 05:58:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TUdIt-000HBE-1x; Sat, 03 Nov 2012 12:58:23 +0000 Date: Sat, 03 Nov 2012 21:58:21 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5094C9E7.4030306@gmail.com> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2012 12:58:29 -0000 > So, ask your suppliers to implement RFC 6437/6438. It's the best we > can do. i have a limited number of brownie points with vendors, a limited budget to use as a carrot, and limited time. i am sure flow labels are on my list somewhere. i just can not see that far down without binoculars. randy From joelja@bogus.com Sat Nov 3 11:08:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514F21F883B for ; Sat, 3 Nov 2012 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-tUNAdRNGTe for ; Sat, 3 Nov 2012 11:08:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC021F8514 for ; Sat, 3 Nov 2012 11:08:18 -0700 (PDT) Received: from dhcp-6038.meeting.ietf.org ([130.129.96.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qA3I8HAa094165 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 3 Nov 2012 18:08:18 GMT (envelope-from joelja@bogus.com) Message-ID: <50955D8F.9020604@bogus.com> Date: Sat, 03 Nov 2012 14:08:15 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPv6 Ops WG 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]); Sat, 03 Nov 2012 18:08:18 +0000 (UTC) Subject: [v6ops] Volunteers needed for Thursday v6ops meeting. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:08:27 -0000 If you'd like to pre-identify yourself as a note-taker or jabber scribe please do so at your convenience between now and the first of our meetings on Thursday at 1300. thanks joel From brian.e.carpenter@gmail.com Sat Nov 3 17:51:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F221F9C9D for ; Sat, 3 Nov 2012 17:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjmY97enAbbO for ; Sat, 3 Nov 2012 17:51:17 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4752121F9C6D for ; Sat, 3 Nov 2012 17:51:15 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2153329dan.31 for ; Sat, 03 Nov 2012 17:51:09 -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=NI6Xjr7zr9c1ac+L+hNcVX8FavjC1XeRmIB+gg3EmsM=; b=flmGfGL8KRVGGVfEKIc0SHMnCtJxUjUnzFAm9NCTT+TkcwSswshF0bTmW2swcwYyTO VxZiHcuB/yQDgYbhCvxXKyrcA2yZDTeiON+FfejAMXfyTSQOodXlrs3srUGdkP6/TUfe GmaylB/fyPplicwmXiH4qeSU7g0SF7BPRCgWRBXSWKURxtfVoQywlqKHx4OrK7ECQgxX pqDZB+J0Z+obXvnbHamxGa3bdzGOdbGQkClTA9/diNaLZIIzti+WOpvtK3wuclZUelns 70jXp7oImCn4EZPrl6HPGww9q7ZV+f2JpQV02vNpEArrjQkfqLQLsprsKqLFY7rGzXIg aYmA== Received: by 10.66.80.133 with SMTP id r5mr17524659pax.24.1351990269633; Sat, 03 Nov 2012 17:51:09 -0700 (PDT) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id bc8sm8128757pab.5.2012.11.03.17.51.08 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 17:51:08 -0700 (PDT) Message-ID: <5095BC0F.80301@gmail.com> Date: Sun, 04 Nov 2012 00:51:27 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2012 00:51:19 -0000 On 03/11/2012 12:58, Randy Bush wrote: >> So, ask your suppliers to implement RFC 6437/6438. It's the best we >> can do. > > i have a limited number of brownie points with vendors, a limited budget > to use as a carrot, and limited time. i am sure flow labels are on my > list somewhere. i just can not see that far down without binoculars. Seriously, I think binoculars are appropriate. This is a long game. At the moment we're trying to make IPv6 do what IPv4 does but with bigger addresses, and that is v6ops' main business obviously. The long game is to enable things that work badly or are impossible with IPv4. I *fully* realise that people trying make a crust by running actual stuff have to focus on what can be done right now. Brian From randy@psg.com Sat Nov 3 17:57:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F3121F9C3D for ; Sat, 3 Nov 2012 17:57:02 -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.151, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwKVmS3e71RK for ; Sat, 3 Nov 2012 17:57:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7193E21F9A32 for ; Sat, 3 Nov 2012 17:57:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TUoWE-000JIM-UP; Sun, 04 Nov 2012 00:56:55 +0000 Date: Sun, 04 Nov 2012 09:56:53 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5095BC0F.80301@gmail.com> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> <5095BC0F.80301@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2012 00:57:02 -0000 >>> So, ask your suppliers to implement RFC 6437/6438. It's the best we >>> can do. >> >> i have a limited number of brownie points with vendors, a limited >> budget to use as a carrot, and limited time. i am sure flow labels >> are on my list somewhere. i just can not see that far down without >> binoculars. > > Seriously, I think binoculars are appropriate. This is a long game. > At the moment we're trying to make IPv6 do what IPv4 does but with > bigger addresses, and that is v6ops' main business obviously. The long > game is to enable things that work badly or are impossible with IPv4. > > I *fully* realise that people trying make a crust by running actual > stuff have to focus on what can be done right now. the problem, as joel pointed out, is that current approaches will be cast in cement. randy From marka@isc.org Sun Nov 4 16:00:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB6321F87A6 for ; Sun, 4 Nov 2012 16:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0VuvFp51fI4 for ; Sun, 4 Nov 2012 16:00:23 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3787921F860D for ; Sun, 4 Nov 2012 16:00:23 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 378FCCA112; Mon, 5 Nov 2012 00:00:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d4fd:9b72:542a:8949]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EC28F216C85; Mon, 5 Nov 2012 00:00:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A56232ACCA52; Mon, 5 Nov 2012 11:00:15 +1100 (EST) To: Randy Bush From: Mark Andrews References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> <5095BC0F.80301@gmail.com> In-reply-to: Your message of "Sun, 04 Nov 2012 09:56:53 +0900." Date: Mon, 05 Nov 2012 11:00:15 +1100 Message-Id: <20121105000015.A56232ACCA52@drugs.dv.isc.org> Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Nov 2012 00:00:24 -0000 While flow labels work for distributing traffic, they do not work for filtering as there is guarentee that fragments will arrive in order. For filtering their need a copy of the headers routers are using to filter to be available in all of the fragments. At a minimum this is the UDP header. TCP should be able to be handled with PTB being returned on fragmented packets. I havn't thought about other protocols. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From touch@isi.edu Sun Nov 4 19:14:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0BA21F84A1 for ; Sun, 4 Nov 2012 19:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.301 X-Spam-Level: X-Spam-Status: No, score=-105.301 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2T5r3gvAzKp for ; Sun, 4 Nov 2012 19:14:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C721F21F84A4 for ; Sun, 4 Nov 2012 19:14:22 -0800 (PST) Received: from [192.168.1.85] (pool-71-105-94-82.lsanca.dsl-w.verizon.net [71.105.94.82]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qA53DSpK017169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 4 Nov 2012 19:13:38 -0800 (PST) References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <76E349F3-6022-4042-9B44-57507593B8DE@employees.org> <5094269F.3000705@bogus.com> <5094C9E7.4030306@gmail.com> <5095BC0F.80301@gmail.com> <20121105000015.A56232ACCA52@drugs.dv.isc.org> In-Reply-To: <20121105000015.A56232ACCA52@drugs.dv.isc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8BC045F0-8F79-48D1-8D71-9365694753D2@isi.edu> X-Mailer: iPhone Mail (10A525) From: Joe Touch Date: Sun, 4 Nov 2012 19:13:28 -0800 To: Mark Andrews X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Nov 2012 03:14:23 -0000 On Nov 4, 2012, at 4:00 PM, Mark Andrews wrote: >=20 > While flow labels work for distributing traffic, they do not work > for filtering as there is guarentee that fragments will arrive in > order. For filtering their need a copy of the headers routers are > using to filter to be available in all of the fragments. At a > minimum this is the UDP header. TCP should be able to be handled > with PTB being returned on fragmented packets. I havn't thought > about other protocols. TCP is supposed to react to PTB already. If you're getting fragments in v6 t= hey're generated at the source. Why would PTB not just result in more, small= er fragments? And what if/when PTB is blocked or dropped by operators like you?=20 Joe From fred@cisco.com Mon Nov 5 06:58:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9EA21F867E for ; Mon, 5 Nov 2012 06:58:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t31ZqHgI-yK5 for ; Mon, 5 Nov 2012 06:58:42 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83821F8681 for ; Mon, 5 Nov 2012 06:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1337; q=dns/txt; s=iport; t=1352127522; x=1353337122; h=from:to:subject:date:message-id:mime-version; bh=84GIR5jSyI5qX6k3StTDvhqAuur/7y7oe6QvWttb2nE=; b=G/a3ElxHYk0I5RGttBu90aVpoVTQqC9RkxihXPGW09aw/EwS+MdHsNrV Cpmv0iAcqBSYbkHq6Bw+43mRpU8pP4LFekl90wO+TkKUfhdKJPFwar4a3 udFhxNCaKXnTo34e9WQnIqTDEUA2zc1hvPONCp/H3PkmDpiptRxeLz+Mx U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHHTl1CtJV2Z/2dsb2JhbABEhVC9aoEIgiABBBIBeAEqVicEGwYUh2gLmTiBK59hBJFcYQOOe4EhlDiBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="asc'?scan'208";a="138900468" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2012 14:58:41 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5Ewfix017297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Nov 2012 14:58:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 08:58:41 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Discussions Thursday Thread-Index: AQHNu2YKaiFTjkTlaEuM0x9Gv5aqow== Date: Mon, 5 Nov 2012 14:58:40 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B1963FA@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.91] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--24.256100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_306BBFBC-C3E0-4AA0-8B22-C81233D45864"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Discussions Thursday X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Nov 2012 14:58:42 -0000 --Apple-Mail=_306BBFBC-C3E0-4AA0-8B22-C81233D45864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://datatracker.ietf.org/meeting/85/agenda/v6ops/ We have 11 drafts to discuss on Thursday, and of course it is best if we = are all familiar with their contents before we get there. I expect some = of them will want to be adopted as working group drafts, some will be = dead ends, and some will need more work before they achieve working = group support. Specifically, however, if you have no time to read anything else, please = be familiar with the first four drafts on the agenda. I expect we will = start the process of finalizing the two working group drafts, and that = we will have a robust discussion about the future of RFC 3316.= --Apple-Mail=_306BBFBC-C3E0-4AA0-8B22-C81233D45864 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iD8DBQFQl9QfbjEdbHIsm0MRAurYAJ91f6gUG4Cqo5pmDysr8kdIdiqR9QCgvVUs GU/NtXTH/0DDvmyRbk1sc6A= =gyrY -----END PGP SIGNATURE----- --Apple-Mail=_306BBFBC-C3E0-4AA0-8B22-C81233D45864-- From mawatari@jpix.ad.jp Mon Nov 5 22:15:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B455021F879E for ; Mon, 5 Nov 2012 22:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzKCg-CgXnoh for ; Mon, 5 Nov 2012 22:15:31 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2217B21F879B for ; Mon, 5 Nov 2012 22:15:30 -0800 (PST) Received: from [192.168.0.231] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 1A44CFC040; Tue, 6 Nov 2012 15:15:29 +0900 (JST) Date: Tue, 06 Nov 2012 15:15:29 +0900 From: MAWATARI Masataka To: phdgang@gmail.com In-Reply-To: References: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> Message-Id: <20121106151528.1783.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: v6ops@ietf.org, draft-ietf-v6ops-nat64-experience@tools.ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-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, 06 Nov 2012 06:15:33 -0000 Dear authors, * On Sat, 3 Nov 2012 06:13:15 +0800 * GangChen wrote: > Hi Philip, > > 2012/11/1, Philip Matthews : > > Hi authors: > > > > I read your draft with interest. I need to re-read it more carefully, but > > here are some preliminary comments: > > > > 1) The title of the draft is "NAT64 Operational Experiences", but I feel the > > draft reads much more like "NAT64 Deployment Considerations". I didn't see > > any place where the draft says "This is what we did and it worked well (or > > it didn't work well)". That is, it is not really relating the specific > > experience of an operator in deploying NAT64 so much as describing things > > that an operator should take into account when planning their own NAT64 > > deployment. > > Thanks for the comments. Regarding the word of "Experiences", I > searched the definition from a dictionary. It usually refers to > "knowledge or practical wisdom gained from what one has observed, > encountered, or undergone". It's true it involves a particular > instance of encountering or undergoing something. Whereas, we didn't > describe such particular behavior (what we did), since the texts seems > to be time-sensitive. It tends to be ephemeral as a documented output > in RFC. So it may be more effective/worthwhile to discuss generalized > knowledge/problems being addressed in the document. > > We are still opening on this point. I guess that is only the matter of > structuring texts > > > > 2) Section 3.1 has the sentence: > > It is advantageous from the vantage-point of > > troubleshooting and traffic engineering to carry the IPv6 traffic > > natively for as long as possible within an access network and > > translates only at or near the network egress. > > I think it would be interesting and helpful to say more about why you feel > > this is true. Can you give some specific examples? > > In our practices, NAT64 is positioned on the location of border > routers. As you mentioned, the reason for that is for cost reasons. > Other gains are simplification of traceability and network > provisioning in one network domain. AFAIK, the cases are also shared > by other operators in the author list. > > > > Though today I suspect > > most operators will try to centralize their NAT64 boxes for cost reasons, I > > can see in the future an operator that is forced to go pure IPv6 and is > > planning a large rollout, and will be worried that centralizing NAT64 will > > not scale well and will thus consider pushing NAT64 to closer to the > > customer. > > The concerns were actually discussed when we do the network planning. > One point is native IPv6 communications would bypass the NAT64. Those > traffic offload on NAT64 should be encouraged if an operator is forced > to go pure IPv6. In some sense, the concerns of scalability on NAT64 > may be alleviated. > > > > 3) Section 3.2 on HA Considerations has the sentence: > > Given that short > > lived sessions account for most of the bindings, hot-standby does not > > offer much benefit for those sessions. > > Just curious if you have evidence or a reference that backs up this claim? > > Statistic of service traffic in a mobile network could be the evidence > depending on the colleted data. Most traffic (almost 94% of amount of > traffic) is accounted by Http, WAP browsing, which are short lived > sessions. > > > This is certainly frequently stated for NAT44, but I haven't seen hard facts > > in the case of NAT64. I am especially wondering if the fact that some > > traffic (like DNS traffic and native IPV6 traffic) doesn't go through the > > NAT64 would change the situation from the NAT44 case. > > I guess the situation on NAT64 is similar with NAT44, since all IPv4 > connections to the IPv4 Internet from IPv6-only clients must traverse > the NAT64. > > > 4) The draft is currently organized so that section 3 discusses the > > NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE > > case. I suggest you consider organizing the draft differently, so that you > > have a series of sections discussing a topic (e.g Load Balancing or MTU), > > and within the section you first discuss the NAT64-CGN case and then the > > NAT64-CPE case. I suggest that this would allow you to discuss each topic > > more fully, and would emphasis the similarities or differences between the > > CGN and CPE cases. Just a suggestion. > > Thanks for the suggestions. Some texts in same topics for NAT64-CGN > and -CE could be structured. Yet, there are also different topics > regarding to -CGN and -CE, which is hardly organized in such way. > > BTW, the term "CE" is likely confused with CPE. What we indicated is > actually a load-balancer in front of enterprise network, e.g. data > center. If the group agree, we intend to rename it as "Front End" to > precisely indicate the meaning. I understood that NAT64-CE shows server-side applicability of NAT64. If my understanding is correct, "Server Farm Edge" sounds better to me, IMHO. Kind Regards, Masataka MAWATARI > Best Regards > > > Gang From philip_matthews@magma.ca Tue Nov 6 08:35:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19ED21F887E for ; Tue, 6 Nov 2012 08:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prOZhfPyU1fm for ; Tue, 6 Nov 2012 08:35:56 -0800 (PST) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id DAB5B21F8837 for ; Tue, 6 Nov 2012 08:35:55 -0800 (PST) Received: from dhcp-1192.meeting.ietf.org ([130.129.17.146]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TVm81-0006CI-2e; Tue, 06 Nov 2012 11:35:54 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Tue, 6 Nov 2012 11:35:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> To: GangChen X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1192.meeting.ietf.org [130.129.17.146] Cc: "v6ops@ietf.org list" , draft-ietf-v6ops-nat64-experience@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-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, 06 Nov 2012 16:35:56 -0000 On 2012-11-02, at 18:13 , GangChen wrote: > Hi Philip, >=20 > 2012/11/1, Philip Matthews : >> Hi authors: >>=20 >> I read your draft with interest. I need to re-read it more = carefully, but >> here are some preliminary comments: >>=20 >> 1) The title of the draft is "NAT64 Operational Experiences", but I = feel the >> draft reads much more like "NAT64 Deployment Considerations". I = didn't see >> any place where the draft says "This is what we did and it worked = well (or >> it didn't work well)". That is, it is not really relating the = specific >> experience of an operator in deploying NAT64 so much as describing = things >> that an operator should take into account when planning their own = NAT64 >> deployment. >=20 > Thanks for the comments. Regarding the word of "Experiences", I > searched the definition from a dictionary. It usually refers to > "knowledge or practical wisdom gained from what one has observed, > encountered, or undergone". It's true it involves a particular > instance of encountering or undergoing something. Whereas, we didn't > describe such particular behavior (what we did), since the texts seems > to be time-sensitive. It tends to be ephemeral as a documented output > in RFC. So it may be more effective/worthwhile to discuss generalized > knowledge/problems being addressed in the document. >=20 > We are still opening on this point. I guess that is only the matter of > structuring texts It is just a suggestion, but I think this title change would reflect the = document contents better. >=20 >=20 >> 2) Section 3.1 has the sentence: >> It is advantageous from the vantage-point of >> troubleshooting and traffic engineering to carry the IPv6 traffic >> natively for as long as possible within an access network and >> translates only at or near the network egress. >> I think it would be interesting and helpful to say more about why you = feel >> this is true. Can you give some specific examples? >=20 > In our practices, NAT64 is positioned on the location of border > routers. As you mentioned, the reason for that is for cost reasons. > Other gains are simplification of traceability and network > provisioning in one network domain. AFAIK, the cases are also shared > by other operators in the author list. I think it would be interesting if you said a bit more about these = reasons in the draft. >=20 >=20 >> Though today I suspect >> most operators will try to centralize their NAT64 boxes for cost = reasons, I >> can see in the future an operator that is forced to go pure IPv6 and = is >> planning a large rollout, and will be worried that centralizing NAT64 = will >> not scale well and will thus consider pushing NAT64 to closer to the >> customer. >=20 > The concerns were actually discussed when we do the network planning. > One point is native IPv6 communications would bypass the NAT64. Those > traffic offload on NAT64 should be encouraged if an operator is forced > to go pure IPv6. In some sense, the concerns of scalability on NAT64 > may be alleviated. >=20 >=20 >> 3) Section 3.2 on HA Considerations has the sentence: >> Given that short >> lived sessions account for most of the bindings, hot-standby does = not >> offer much benefit for those sessions. >> Just curious if you have evidence or a reference that backs up this = claim? >=20 > Statistic of service traffic in a mobile network could be the evidence > depending on the colleted data. Most traffic (almost 94% of amount of > traffic) is accounted by Http, WAP browsing, which are short lived > sessions. >=20 >> This is certainly frequently stated for NAT44, but I haven't seen = hard facts >> in the case of NAT64. I am especially wondering if the fact that some >> traffic (like DNS traffic and native IPV6 traffic) doesn't go through = the >> NAT64 would change the situation from the NAT44 case. >=20 > I guess the situation on NAT64 is similar with NAT44, since all IPv4 > connections to the IPv4 Internet from IPv6-only clients must traverse > the NAT64. >=20 >> 4) The draft is currently organized so that section 3 discusses the >> NAT64-CGN case, and section 4 discusses the same topics in the = NAT64-CPE >> case. I suggest you consider organizing the draft differently, so = that you >> have a series of sections discussing a topic (e.g Load Balancing or = MTU), >> and within the section you first discuss the NAT64-CGN case and then = the >> NAT64-CPE case. I suggest that this would allow you to discuss each = topic >> more fully, and would emphasis the similarities or differences = between the >> CGN and CPE cases. Just a suggestion. >=20 > Thanks for the suggestions. Some texts in same topics for NAT64-CGN > and -CE could be structured. Yet, there are also different topics > regarding to -CGN and -CE, which is hardly organized in such way >=20 > BTW, the term "CE" is likely confused with CPE. What we indicated is > actually a load-balancer in front of enterprise network, e.g. data > center. If the group agree, we intend to rename it as "Front End" to > precisely indicate the meaning. >=20 > Best Regards >=20 >=20 > Gang >=20 >> - Philip >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From phdgang@gmail.com Tue Nov 6 12:58:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6569321F8B36 for ; Tue, 6 Nov 2012 12:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbAWaw510hFr for ; Tue, 6 Nov 2012 12:58:03 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 582D721F8BD8 for ; Tue, 6 Nov 2012 12:58:03 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so914894vcb.31 for ; Tue, 06 Nov 2012 12:58:02 -0800 (PST) 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=G0wjp8bQnX1L6x8smQVarQADNH5T5lvefnzqQmg4KZ4=; b=IvnYYDK+i/hw4JHU3mvjvlo4/iy7rWDslNeig+GPc/8i//YWypdhZd7NqUMiPmVktN qnQG+DD7FAPv0tv+S3y++V5Hn0h9Qpa2XxgohSPj08qcxCsoms0v5UQ4h0jMoS0spvQP gtktT0uzXlwFVddKrxYvF21VJpl048+UCkUd5fjEqQ/ZCiFPDHDW5KjGW1tQeWl1GRek LEsBpRxnPtdc8VOjdLA1plr8cnCuh/Y/FT8JSdE0jNzg4JN2XMGZBpqwGluAndw6YWNH zeUHFj7bXLhsiAmblovjGLlvRSzqly76l/w4dWkwvyT/eJqdYrca3y4L1YKKIBVpyxpq J7zw== MIME-Version: 1.0 Received: by 10.52.97.165 with SMTP id eb5mr1863732vdb.75.1352235482786; Tue, 06 Nov 2012 12:58:02 -0800 (PST) Received: by 10.58.44.10 with HTTP; Tue, 6 Nov 2012 12:58:02 -0800 (PST) In-Reply-To: References: <86E4957C-33CA-493A-991E-9A937FC28BE0@magma.ca> Date: Wed, 7 Nov 2012 04:58:02 +0800 Message-ID: From: GangChen To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org list" , draft-ietf-v6ops-nat64-experience@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-nat64-experience-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, 06 Nov 2012 20:58:04 -0000 Hi Philip, 2012/11/7, Philip Matthews : > > On 2012-11-02, at 18:13 , GangChen wrote: > >> Hi Philip, >> >> 2012/11/1, Philip Matthews : >>> Hi authors: >>> >>> I read your draft with interest. I need to re-read it more carefully, >>> but >>> here are some preliminary comments: >>> >>> 1) The title of the draft is "NAT64 Operational Experiences", but I feel >>> the >>> draft reads much more like "NAT64 Deployment Considerations". I didn't >>> see >>> any place where the draft says "This is what we did and it worked well >>> (or >>> it didn't work well)". That is, it is not really relating the specific >>> experience of an operator in deploying NAT64 so much as describing >>> things >>> that an operator should take into account when planning their own NAT64 >>> deployment. >> >> Thanks for the comments. Regarding the word of "Experiences", I >> searched the definition from a dictionary. It usually refers to >> "knowledge or practical wisdom gained from what one has observed, >> encountered, or undergone". It's true it involves a particular >> instance of encountering or undergoing something. Whereas, we didn't >> describe such particular behavior (what we did), since the texts seems >> to be time-sensitive. It tends to be ephemeral as a documented output >> in RFC. So it may be more effective/worthwhile to discuss generalized >> knowledge/problems being addressed in the document. >> >> We are still opening on this point. I guess that is only the matter of >> structuring texts > > It is just a suggestion, but I think this title change would reflect the > document contents better. Ok. I would add it as an open question in the slides to see opinions from the group. >> >> >>> 2) Section 3.1 has the sentence: >>> It is advantageous from the vantage-point of >>> troubleshooting and traffic engineering to carry the IPv6 traffic >>> natively for as long as possible within an access network and >>> translates only at or near the network egress. >>> I think it would be interesting and helpful to say more about why you >>> feel >>> this is true. Can you give some specific examples? >> >> In our practices, NAT64 is positioned on the location of border >> routers. As you mentioned, the reason for that is for cost reasons. >> Other gains are simplification of traceability and network >> provisioning in one network domain. AFAIK, the cases are also shared >> by other operators in the author list. > > I think it would be interesting if you said a bit more about these reasons > in the draft. Will add at the next version Best Regards Gang >> >> >>> Though today I suspect >>> most operators will try to centralize their NAT64 boxes for cost reasons, >>> I >>> can see in the future an operator that is forced to go pure IPv6 and is >>> planning a large rollout, and will be worried that centralizing NAT64 >>> will >>> not scale well and will thus consider pushing NAT64 to closer to the >>> customer. >> >> The concerns were actually discussed when we do the network planning. >> One point is native IPv6 communications would bypass the NAT64. Those >> traffic offload on NAT64 should be encouraged if an operator is forced >> to go pure IPv6. In some sense, the concerns of scalability on NAT64 >> may be alleviated. >> >> >>> 3) Section 3.2 on HA Considerations has the sentence: >>> Given that short >>> lived sessions account for most of the bindings, hot-standby does not >>> offer much benefit for those sessions. >>> Just curious if you have evidence or a reference that backs up this >>> claim? >> >> Statistic of service traffic in a mobile network could be the evidence >> depending on the colleted data. Most traffic (almost 94% of amount of >> traffic) is accounted by Http, WAP browsing, which are short lived >> sessions. >> >>> This is certainly frequently stated for NAT44, but I haven't seen hard >>> facts >>> in the case of NAT64. I am especially wondering if the fact that some >>> traffic (like DNS traffic and native IPV6 traffic) doesn't go through >>> the >>> NAT64 would change the situation from the NAT44 case. >> >> I guess the situation on NAT64 is similar with NAT44, since all IPv4 >> connections to the IPv4 Internet from IPv6-only clients must traverse >> the NAT64. >> >>> 4) The draft is currently organized so that section 3 discusses the >>> NAT64-CGN case, and section 4 discusses the same topics in the NAT64-CPE >>> case. I suggest you consider organizing the draft differently, so that >>> you >>> have a series of sections discussing a topic (e.g Load Balancing or >>> MTU), >>> and within the section you first discuss the NAT64-CGN case and then the >>> NAT64-CPE case. I suggest that this would allow you to discuss each >>> topic >>> more fully, and would emphasis the similarities or differences between >>> the >>> CGN and CPE cases. Just a suggestion. >> >> Thanks for the suggestions. Some texts in same topics for NAT64-CGN >> and -CE could be structured. Yet, there are also different topics >> regarding to -CGN and -CE, which is hardly organized in such way >> >> BTW, the term "CE" is likely confused with CPE. What we indicated is >> actually a load-balancer in front of enterprise network, e.g. data >> center. If the group agree, we intend to rename it as "Front End" to >> precisely indicate the meaning. >> >> Best Regards >> >> >> Gang >> >>> - Philip >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> > > From arturo.servin@gmail.com Wed Nov 7 06:40:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6F21F8B4A for ; Wed, 7 Nov 2012 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1EpRBLpeAVR for ; Wed, 7 Nov 2012 06:40:46 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFDC121F8B55 for ; Wed, 7 Nov 2012 06:40:45 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1313359pbb.31 for ; Wed, 07 Nov 2012 06:40:45 -0800 (PST) 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:content-transfer-encoding; bh=P34SL9YzpAT4ENS+/R0OYR5anPbbNuXekx9rQwgzzuE=; b=wtmbrXrHwfiDgq18XIUMOd5iq591RaCrFYjP2OVTOcY9F1nZYcdtYQ1axY3xN0rDqQ 9t4qwx1GnIlbaz5Yj9TNvWiWt/jSumbYIceykUlKU4C19ElODvf5UXcoyOz+oOrdnk4Q SufPYFpQOdDhLoxbwjJt+n0GI896OWI7bUuw8TPjtP4yeUMJaPA4eIy7Mhlzdj61DIrl CDxrrbw/ZSrO3KpRl6HA61xlEOnkF7fhBez9CbFKl22C+5l3oppp6vT1DLMgq+R+ae+7 Io01HMJVccGoejNlmKpQA0o/y/fvPYbG4DRJEVp3KY66vXPGOaN1ratAIoQNPgY0f5t1 YTOw== Received: by 10.68.225.3 with SMTP id rg3mr14475671pbc.27.1352299245693; Wed, 07 Nov 2012 06:40:45 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org ([2001:df8:0:16:e4a1:84f4:6e89:f0ef]) by mx.google.com with ESMTPS id ug6sm6117996pbc.4.2012.11.07.06.40.42 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:40:44 -0800 (PST) Message-ID: <509A72E8.80602@gmail.com> Date: Wed, 07 Nov 2012 09:40:40 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20120915180503.23774.22275.idtracker@ietfa.amsl.com> In-Reply-To: <20120915180503.23774.22275.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-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: Wed, 07 Nov 2012 14:40:46 -0000 Sorry about a bit late. Some comments: Section 3.4.3 (and 4.3) I-D.gashinsky-v6ops-v6nd-problems is now rfc6583. 3.5 Address plan I am not sure that the operation community has converged to declare /127 for p2p links even though RFC6164. In any case, a recommendation to use a /127 but to reserved a /64 for future use may be good to add. 4.4 is empty. Are you planning to add text? I think you should. Also, some considerations from 4.4 (Applications) I think apply to 5.3 (application testing, database length fields, logging, etc.) 6.2 IPv6-only I think you are missing an important motivation to move to IPv6 only. This cost is in datacenter operations where admins do not need to maintain ipv4 for applications that never interact with the end-user (with v4), for example databases, application servers, etc. Hence there is a saving by not maintaining double server configurations, firewalls, etc. 7.2 Data center virt. You can add some of my previous comment here as well. Regards, as On 15/09/2012 14:05, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 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-01.txt > Pages : 28 > Date : 2012-09-15 > > 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-ipv6 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-enterprise-incremental-ipv6-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From arturo.servin@gmail.com Wed Nov 7 06:50:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3E21F8B33 for ; Wed, 7 Nov 2012 06:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6sFy4t6Hxh5 for ; Wed, 7 Nov 2012 06:50:34 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EC21F89F5 for ; Wed, 7 Nov 2012 06:50:34 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1319325pbb.31 for ; Wed, 07 Nov 2012 06:50:34 -0800 (PST) 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:content-transfer-encoding; bh=uUWsQ1mS0saWA1jDnrZJJFEp8mQ2OKpDB3scvf6ofxA=; b=fhAyyJn8E2qcBfdNw9cWeWZvzHY4xdbC7BduuzYxHLJEqrHBRwbwC7LxR09rXhfR4h 6jPhhxDYg9ATiGZGlMJlmkz5LYdTb2VbpfQVPidKxG2JmIESxuhLl8TC4db90b00fPsQ xwFs2IxLHNpMJMEzZT3zfJubvHHdbyg24d9CGI4LDG6szcx8jXeI+r2IignkEZZqNOn+ NPucGz7L3prW/h9p27DVD34Ld0zxmMg1XputV/ln8imD5bMy6H4wGanlSL0hN+3X7oVf 5eSnUJi9UYQR9o8LwmMk7+Wb/yk63fuLE+IFuFl422pFZ0r3JctQELKCIK17rkZme9ib zmWQ== Received: by 10.68.135.42 with SMTP id pp10mr14411283pbb.159.1352299834148; Wed, 07 Nov 2012 06:50:34 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org ([2001:df8:0:16:e4a1:84f4:6e89:f0ef]) by mx.google.com with ESMTPS id o1sm14381031paz.34.2012.11.07.06.50.32 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:50:33 -0800 (PST) Message-ID: <509A7536.6020009@gmail.com> Date: Wed, 07 Nov 2012 09:50:30 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20121020200652.28676.43201.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] New version of draft-lopez-v6ops-dc-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, 07 Nov 2012 14:50:35 -0000 Diego, A quick comment. For the section 2.3 I think one important motivation is cost savings by not maintaining two stacks. Today basically we need to maintain two datacenters networks, Have procedures to enable and secure IPv4 and IPv6, test new applications in both stacks, etc. As datacenter admin, to maintain a single stack is a real motivation to run ipv6 only at least for internal infrastructure that do not interact with users (databases, application servers, VM infrastructure, etc.) Regards as On 21/10/2012 06:02, Diego R. Lopez wrote: > Hi, > > This new version incorporates all the changes discussed in Vancouver, > being the most salient a title change and the renaming of the "maturity > levels" (and their numbers) into named "transition stages", plus more > elaborated text for examples at each transition stage, and a first full > attempt for the security considerations. > > http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6 > > Diff http://www.ietf.org/rfcdiff?url2=draft-lopez-v6ops-dc-ipv6-03 > > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Nov 7 07:00:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267121F87B8 for ; Wed, 7 Nov 2012 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gofT603XYu5a for ; Wed, 7 Nov 2012 07:00:09 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4226E21F8B33 for ; Wed, 7 Nov 2012 07:00:06 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1273844pad.31 for ; Wed, 07 Nov 2012 07:00:06 -0800 (PST) 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=dsw+gyfKLgwmWmCzd/5JYrsQPEQseATFVq8IySo58Z0=; b=oA4lDLi/Vf/YzpQby6KNPznK9TpIQ6fWrSbe6jVxcFkLTT0QyJXOi6gSvUrmE3D+zT WrPaAcb84iFNHhRG/Ixh0sgR+i/MYGOIyZdCGlAharb254yrFz1yCiosWUQUTXUSw75q jmE/q1EBaPYSKwOgXMgL4DdzVBndgWTezkIlElyrNxLPOdrjb6YRuVBVUsYrkd0YuNcc Zv9+EYhWk1YUHPzY7cAuynUozHcx9iVXVhPjkMn7nrO3gddJCVJeTISJ+uR2GhSTeDCZ p9S07lSykPhLhKTlEp8W76ULwDY1wxwBks9L3YkEktGtJL5OFsa17AxyNJc1u1nwDF+E WjAQ== Received: by 10.68.232.195 with SMTP id tq3mr14479713pbc.70.1352300405959; Wed, 07 Nov 2012 07:00:05 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ok8sm14247172pbb.42.2012.11.07.07.00.03 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:00:03 -0800 (PST) Message-ID: <509A777A.9000508@gmail.com> Date: Wed, 07 Nov 2012 15:00:10 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> In-Reply-To: <5092C846.5090009@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2012 15:00:12 -0000 On 01/11/2012 19:06, Brian E Carpenter wrote: > Joe, > > On 01/11/2012 18:34, Joe Touch wrote: >> >> On 11/1/2012 2:35 AM, Brian E Carpenter wrote: >>> On 31/10/2012 18:58, Joe Touch wrote: >>>> >>>> On 10/31/2012 11:34 AM, Fernando Gont wrote: >>>>> On 10/31/2012 04:11 PM, Joe Touch wrote: >>>>>> Yes, but the whole point of the IPv6 option architecture was to avoid >>>>>> the issues seen with IPv4 options. >>>>> The only thing in that IPv6 would avoid is requiring routers to parse >>>>> *all* options, just to find the ones that need to be processed by >>>>> routers. >>>> Yes. >>> No. The only extension header that *needs* to be parsed by intermediate >>> routers is the hop-by-hop options header, and that is the first one (if >>> present). >> The first one could be: >> >> A. a known HBH option >> indicating there are HBH options >> B. a known E2E option >> indicating there are no HBH options >> C. an unknown option or a pad option >> indicating NOTHING > > Actually there is another unfortunate aspect of RFC 2460 here. It would > be better if it said that the hbh options extension header MUST be > first, instead of just recommending it. I think I will add that to my draft. I was wrong. 2460 does have this as a lower case "must". Brian > >> In the case of C, the router needs to keep looking at subsequent options >> until one of three things happens: >> >> 1. a known HBH option is seen >> indicating there are HBH options >> 2. a known E2E option is seen >> indicating there are no HBH options >> 3. there are no more options >> indicating there are no HBH options >> >> As a result, it's entirely possible that a router could need to parse >> the entire option chain before it can determine whether there are any >> HBH options. > > Yes, because of the point I just mentioned. That's a bug IMHO. > However, the observed problems come from middleboxes that don't > parse regular extension headers, not hbh option headers. > > Brian > >>> (You can legitimately argue that the hbh header and the routing header >>> are effectively useless, but that doesn't break fundamental >>> connectivity.) >>> >>> IPv6 routers should have nothing to do with fragmentation. >> +1 >> >>> The problem is due to middleboxes that break the IPv6 spec by inspecting >>> any part of the packet beyond the hop-by-hop header and discarding what >>> they don't understand. >> +1 >> >> Joe >> > From brian.e.carpenter@gmail.com Wed Nov 7 07:07:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A878A21F8BF8 for ; Wed, 7 Nov 2012 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Ixwn6eh8lB for ; Wed, 7 Nov 2012 07:07:12 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 367ED21F8BBE for ; Wed, 7 Nov 2012 07:07:12 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1278352pad.31 for ; Wed, 07 Nov 2012 07:07:12 -0800 (PST) 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=lBVkV8cIjGV3bCgCQxZ4rRrZzTca2YfpEUKZAZKsmaM=; b=R7PSqAYGPBHsthU0bw2gj85FO8mRxC8VHOftehWnCyIHQsFTiWIiiyeeBATREerNdW lVYtVWNMd7tfS6YJTSABl5ndTySf7Zcd1GgyUuAt5B4Yf6zjko+mWVrz64xIzC+rCHVc nQvDMJJnkkVfiZznVcB/RUpM1+y5fGm1xjhs144A4mMPZQ/W6NG3oBGpMrqjgDImFnKg G0sKsZzV1AK2wVyJxK3dPIczK8fP5WMgZ9b1G7V0TsYAWuBvBFcpR2frtKSVa1hyjYac daixGlVkR+mqlQ0VUCI3SvNOgTI0udLrAan53uXOFnA/T7KWQyKNJjdfZtnf7FWvkQpN UsvA== Received: by 10.68.218.97 with SMTP id pf1mr14419269pbc.96.1352300832024; Wed, 07 Nov 2012 07:07:12 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ox8sm7780217pbc.31.2012.11.07.07.07.07 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:07:07 -0800 (PST) Message-ID: <509A7922.9080000@gmail.com> Date: Wed, 07 Nov 2012 15:07:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> In-Reply-To: <5093CF61.9090301@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2012 15:07:12 -0000 On 02/11/2012 13:49, Joe Touch wrote: > Hi, Brian, > > On 11/2/2012 1:17 AM, Brian E Carpenter wrote: > ... >>> Isn't the real bug the fact that the option numbers don't indicate >>> whether an option is HBH or not? >> >> Why is that a problem? The extension header that contains the options >> tells you that (0 for hbh options, 60 for destination options). > > Except for extension headers that are yet to be defined. I don't get your point, Joe. It is very clear in 2460 that extension headers are only interpreted at the destination, except for the HBH options header. So there's no scope to develop a new header with HBH semantics. In any case, this is already covered in RFC 6564: "New IPv6 extension header(s) having hop-by-hop behavior MUST NOT be created or specified. New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible." Brian > > I.e., while you're fixing the order, another key issue is that: > > all HBH options MUST occur only in the HBH extension header > > (similarly, 60 isn't strictly the only destination header; see esp. the > end of Sec. 4.6, but that is much less problematic) > > Frankly, the HBH extension header is misnamed; AFAICT, this is intended > to be the true forwarding plane options. Other other currently defined > options (AFAICT), including the routing option, occur only when the > router is really acting as a host (i.e., where that router owns the > destination IP address of the packet). > > Joe > From wwwrun@rfc-editor.org Wed Nov 7 08:02:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34E121F8C31; Wed, 7 Nov 2012 08:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGspw8Ub3efu; Wed, 7 Nov 2012 08:02:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6804E21F8C32; Wed, 7 Nov 2012 08:02:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B8705B1E002; Wed, 7 Nov 2012 07:56:01 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121107155602.B8705B1E002@rfc-editor.org> Date: Wed, 7 Nov 2012 07:56:01 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6782 on Wireline Incremental 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, 07 Nov 2012 16:02:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6782 Title: Wireline Incremental IPv6 Author: V. Kuarsingh, Ed., L. Howard Status: Informational Stream: IETF Date: November 2012 Mailbox: victor.kuarsingh@gmail.com, lee.howard@twcable.com Pages: 29 Characters: 71197 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-wireline-incremental-ipv6-06.txt URL: http://www.rfc-editor.org/rfc/rfc6782.txt Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From touch@isi.edu Wed Nov 7 08:18:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1046221F8B64 for ; Wed, 7 Nov 2012 08:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o5wGj9+YrdD for ; Wed, 7 Nov 2012 08:18:49 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4D321F8B6A for ; Wed, 7 Nov 2012 08:18:48 -0800 (PST) Received: from [172.28.172.238] ([12.47.191.66]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA7GHOEf028727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Nov 2012 08:17:34 -0800 (PST) Message-ID: <509A8993.4000803@isi.edu> Date: Wed, 07 Nov 2012 08:17:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> <509A7922.9080000@gmail.com> In-Reply-To: <509A7922.9080000@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2012 16:18:50 -0000 On 11/7/2012 7:07 AM, Brian E Carpenter wrote: .... >> Except for extension headers that are yet to be defined. > > I don't get your point, Joe. It is very clear in 2460 that extension > headers are only interpreted at the destination, except for the HBH > options header. That was not at all clear from RFC2460, however, your pointer to 6564 corrects that omission (sorry I hadn't caught that). > So there's no scope to develop a new header with HBH > semantics. In any case, this is already covered in RFC 6564: > "New IPv6 extension > header(s) having hop-by-hop behavior MUST NOT be created or > specified. New options for the existing Hop-by-Hop Header SHOULD NOT > be created or specified unless no alternative solution is feasible." > > Brian There's remains other problematic language in 2460, however: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). So it still seems open to have more than one HBH header, which certainly complicates things even though they'd be clearly marked. Joe From cb.list6@gmail.com Thu Nov 8 09:54:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4521F852A for ; Thu, 8 Nov 2012 09:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkt4vZ92v9cr for ; Thu, 8 Nov 2012 09:54:32 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08D21F8433 for ; Thu, 8 Nov 2012 09:54:32 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2602327lbo.31 for ; Thu, 08 Nov 2012 09:54:31 -0800 (PST) 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=LVG+HLDKLdrw3/WnNgPcTb8Mr+WSrEYs5ttW3TVG3ic=; b=GHIyNsSgV1pPRxoZjpnAQX3V7W3cwGr2107vEWjnJn+ozmrKfQej2g+Be0rGT6wWQp OzJFkOoTtfL+x4aWxwFnHXSHGxqyyfye9pgn8a/flOfczlHA2iYblSSjd1SBfeE/TBfi zAyvjfriAg+n1gbI2ZULm8zl7DGuPEf0j0awe6dvzCNAevnLxGCk+MmemMqlkR/u7Ldw yO1Rqyfpn8VMiLogu58+QFjkVzJ77QmQ+9n3pruQk6bqxvdP28yzDVpt6K0vG3ccIy98 Bmq1gnC3LtNwYB4baR7/ry2aad7IVIKy9cuJP4Wd+w3ednK7or3DzYpDG5e/8JbSRqw/ aWZQ== MIME-Version: 1.0 Received: by 10.112.43.34 with SMTP id t2mr3565419lbl.109.1352397271287; Thu, 08 Nov 2012 09:54:31 -0800 (PST) Received: by 10.112.81.167 with HTTP; Thu, 8 Nov 2012 09:54:31 -0800 (PST) Date: Thu, 8 Nov 2012 09:54:31 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT + /64 share demo at meeting now X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 17:54:33 -0000 SSID = 464XLAT-demo This is bound to break with many people trying it, but feel free to give it a try Relevant test ip6.me should show you a 2607:fb90/32 T-Mobile USA address, or try http://test-ipv6.com http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 From alexandru.petrescu@gmail.com Thu Nov 8 10:35:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2888421F8438 for ; Thu, 8 Nov 2012 10:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.217 X-Spam-Level: X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYbHrrwmf2oT for ; Thu, 8 Nov 2012 10:35:05 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5082C21F842B for ; Thu, 8 Nov 2012 10:35:04 -0800 (PST) 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 qA8IZ3vD026715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Nov 2012 19:35:03 +0100 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 qA8IZ3Ow028515 for ; Thu, 8 Nov 2012 19:35:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-4.intra.cea.fr [132.166.201.4]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA8IYmHx029534 for ; Thu, 8 Nov 2012 19:35:03 +0100 Message-ID: <509BFB47.2080501@gmail.com> Date: Thu, 08 Nov 2012 19:34:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] about the draft /64 'sharing' 'tethering' draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 18:35:06 -0000 Hello, I have the following comments about draft-byrne-v6ops-64share-03. I walk a fine line of WG with respect to recommendations elsewhere. This /64 tethering to make a cellular terminal act like an IPv6 hotspot is highly needed. The mobile routers I work with highly need this. To avoid it I use Mobile IPv6, but that requires HA in the infra. This is needed not only for 3GPP terminals. It's also for an ADSL box which receives a /64 from operator and uses a ptp link from terminal to infrastructure. In netext, I wrote an individual submission draft about how to make a "prefix division" for a Mobile Router (with Proxy MIP in the infra). It's section 2.1 "HNP Division" of draft-petrescu-netext-pmip-nemo-01.txt. With respect to technical detail to your draft... I think an example is very good. You give an example but it could be better illustrated. Then, > When tethering a LAN, the UE may then assign that same address to its > LAN interface with a /64 subnet I have some doubts about this, but they could be clarified. For example, When the same address is present on both interfaces, will an application choose rightly the outgoing interface, or are there risks of choosing the wrong interface? To that end, it would be good to explain in the example what are the routing table entries, exemplify. Or say that never applications run on this device, but on the Hosts attached to hotspot. The reason I am asking this is the following. In the past there was much discussion about making an HA (Home Agent) work from MIP to MIP/NEMO. The initial proposals also considered this HA to have same address on an egress and on an ingress interface. It could work, but as spec went on we realized there were some problems and dropped that. I want to make sure we have no reason here to drop this. Alex From otroan@employees.org Thu Nov 8 11:06:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01A21F8531 for ; Thu, 8 Nov 2012 11:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNaSFRFqSeby for ; Thu, 8 Nov 2012 11:06:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C78BA21F8507 for ; Thu, 8 Nov 2012 11:06:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD4CnFCQ/khN/2dsb2JhbABEDsNOgQiCHgEBAQMBEgEnPwULC0ZXBjWHYgabfqA2kXhhA4ham3mBa4IyWw X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="78095221" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Nov 2012 19:06:01 +0000 Received: from dhcp-10-61-102-126.cisco.com (dhcp-10-61-102-126.cisco.com [10.61.102.126]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8J5xEM023041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Nov 2012 19:06:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <509A8993.4000803@isi.edu> Date: Thu, 8 Nov 2012 14:05:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <55E816CE-22B4-4C81-BC8C-61D932782192@employees.org> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> <509A7922.9080000@gmail.com> <509A8993.4000803@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1498) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 19:06:24 -0000 Joe, > There's remains other problematic language in 2460, however: >=20 > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). >=20 > So it still seems open to have more than one HBH header, which = certainly complicates things even though they'd be clearly marked. I don't see how you can read that to imply you can have more than one = Hop-by-Hop extension header. my reading (and what I think the _intention_ of the text was) is that = there can only be one Hop-By-Hop extension header, and that the HBH header must be the first extension header in the chain. = this way routers only need to check the Next Header field for the value of 0. cheers, Ole= From alexandru.petrescu@gmail.com Thu Nov 8 11:55:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE9C21F84F8 for ; Thu, 8 Nov 2012 11:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhTRXEuRKWNJ for ; Thu, 8 Nov 2012 11:55:26 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44921F8507 for ; Thu, 8 Nov 2012 11:55:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA8JtIUM007339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Nov 2012 20:55:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA8JtIfY009123 for ; Thu, 8 Nov 2012 20:55:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-4.intra.cea.fr [132.166.201.4]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA8JsZp2001723 for ; Thu, 8 Nov 2012 20:55:17 +0100 Message-ID: <509C0DFA.8010500@gmail.com> Date: Thu, 08 Nov 2012 20:54:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Comment on setting up an IPv6 cellular connection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 19:55:26 -0000 There is a need of guidelines of how to set up an IPv6 connection, step by step, between a cellular host and the infrastructure. This is not as easy as saying - just like IPv4 - it's different. A possible example, given one particular operator, a particular terminal hardware and 3G (not LTE) one already has a particular set of steps to execute, AT commands, widely available software to install, to make it work. This is what is very useful, maybe added up to requirements. Alex From alh-ietf@tndh.net Thu Nov 8 12:21:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94921F8738 for ; Thu, 8 Nov 2012 12:21:58 -0800 (PST) X-Quarantine-ID: 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: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPInoNah+Zxn for ; Thu, 8 Nov 2012 12:21:58 -0800 (PST) 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 C702121F8737 for ; Thu, 8 Nov 2012 12:21:57 -0800 (PST) Received: from [172.20.144.31] (helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TWYbn-00068j-61; Thu, 08 Nov 2012 12:21:56 -0800 From: "Tony Hain" To: "'Alexandru Petrescu'" , References: <509C0DFA.8010500@gmail.com> In-Reply-To: <509C0DFA.8010500@gmail.com> Date: Thu, 8 Nov 2012 12:21:51 -0800 Message-ID: <01e801cdbdee$afdb8dc0$0f92a940$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgj4O7oJz+3LrSQBKB61xajN6CpZe6vkxQ Content-Language: en-us X-SA-Exim-Connect-IP: 172.20.144.31 X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Subject: Re: [v6ops] Comment on setting up an IPv6 cellular connection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 20:21:58 -0000 Try: https://sites.google.com/site/tmoipv6/lg-mytouch > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Alexandru Petrescu > Sent: Thursday, November 08, 2012 11:55 AM > To: v6ops@ietf.org > Subject: [v6ops] Comment on setting up an IPv6 cellular connection > > There is a need of guidelines of how to set up an IPv6 connection, step by > step, between a cellular host and the infrastructure. > > This is not as easy as saying - just like IPv4 - it's different. > > A possible example, given one particular operator, a particular terminal > hardware and 3G (not LTE) one already has a particular set of steps to > execute, AT commands, widely available software to install, to make it work. > > This is what is very useful, maybe added up to requirements. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rjs@rob.sh Thu Nov 8 12:56:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD4D21F89E5 for ; Thu, 8 Nov 2012 12:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDU4iGhlX-5D for ; Thu, 8 Nov 2012 12:56:29 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 4117821F89F5 for ; Thu, 8 Nov 2012 12:56:29 -0800 (PST) Received: from rjs by cappuccino.rob.sh with local (Exim 4.72) (envelope-from ) id 1TWZ6h-0006fg-J9; Thu, 08 Nov 2012 20:53:47 +0000 Date: Thu, 8 Nov 2012 20:53:47 +0000 From: Rob Shakir To: Philip Matthews Message-ID: <20121108205347.GA25012@cappuccino.rob.sh> References: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 20:56:29 -0000 On Mon, Oct 22, 2012 at 02:28:49PM -0400, Philip Matthews wrote: > Folks: > > I have just posted a new version (-01) of the Design Guidelines draft: > https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/ OR > http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 Hi Philip, Apologies, I did not notice this to comment at the mic in the meeting. In the draft on the subject of eBGP sessions, you state: However, there are three main concerns with option (a). First, on most existing implementations, adding or removing an address family to an established BGP session will cause the router to tear down and re-establish the session. Thus adding the IPv6 family to an existing session carrying just IPv4 routes will disrupt the session, and the eventual removal of IPv4 from the dual IPv4/IPv6 session will also disrupt the session. This disruption problem will persist until something similar to [I-D.ietf-idr-dynamic-cap] is widely deployed. One should note that dynamic-cap is not the only option for not disrupting a session between two devices by adding new capabilities to it. For IPv4/IPv6/VPNv4/VPNv6, running multi-session [0] will allow separate sessions to be utilised for each . In this case, the transport is still over the single underlying IP transport (whether it be IPv4, or IPv6). This is notable because: A) It allows adding new AFIs to an adjacency in a non-disruptive way. B) It is already implemented in at least one major shipping implementation - where dynamic-cap is not implemented in any that I know of. C) It provides some fault isolation between UPDATE and other BGP errors in {IP,VPN}v4/{IP,VPN}v6 AFIs. D) It retains the management simplicity of having a single identifier for a remote peer, whilst having some of the advantages of separate sessions. Of course it does not address the other concerns around different transport planes that are contained in the same section, but it is perhaps worth nothing in your draft. Thanks, r. [0]: http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07 From bob.hinden@gmail.com Thu Nov 8 13:05:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF2A21F894D for ; Thu, 8 Nov 2012 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aigx0ibj+wTk for ; Thu, 8 Nov 2012 13:05:51 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6A21F88CC for ; Thu, 8 Nov 2012 13:05:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2427237pad.31 for ; Thu, 08 Nov 2012 13:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qCUykbMWjysR9DCSJOclLrfFoFwZRJVMufjNrhIzBlA=; b=KTRByCMM8+d6Fn7QqPoPRH8H+beM7zbmItp2q7nlM+6l95ZRpUsM/gKFvwkYpVRhyQ Rep0xpqipobhGGbm+MLdWmDZw96SnaBHTUt0cnYD2soTBgx+t5Oc/Yw4KzebRJKQxw0r isueGS1DYX3hXQxgIP6RKkupFZpYMLYnujC9WxCUm/dlzlD/WkRnp+TvSWFXaEFp1kKz qlzZBLndp93DOHYgdgjydZ0WF9AYeN7mhwUBLIpxblvfYfh+Id+bLq2G4XsxIv3svN1d BKyYdZJhVXdBh2M1PYL+MrYidfzAzLq72Q5WBXzIvKlZejoxPEElJZaH+/AsQb1Wox2/ UO9A== Received: by 10.68.236.131 with SMTP id uu3mr27500738pbc.104.1352408751574; Thu, 08 Nov 2012 13:05:51 -0800 (PST) Received: from ?IPv6:2001:df8::16:7877:b852:8476:6f44? ([2001:df8:0:16:7877:b852:8476:6f44]) by mx.google.com with ESMTPS id c1sm16672228pav.23.2012.11.08.13.05.48 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 13:05:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Bob Hinden In-Reply-To: <55E816CE-22B4-4C81-BC8C-61D932782192@employees.org> Date: Thu, 8 Nov 2012 16:05:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B60F4C0-0E86-4F7F-8B22-7CC0E471D11F@gmail.com> References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> <509A7922.9080000@gmail.com> <509A8993.4000803@isi.edu> <55E816CE-22B4-4C81-BC8C-61D932782192@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1283) Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 21:05:52 -0000 On Nov 8, 2012, at 2:05 PM, Ole Tr=F8an wrote: > Joe, >=20 >> There's remains other problematic language in 2460, however: >>=20 >> Each extension header should occur at most once, except for the >> Destination Options header which should occur at most twice (once >> before a Routing header and once before the upper-layer header). >>=20 >> So it still seems open to have more than one HBH header, which = certainly complicates things even though they'd be clearly marked. >=20 > I don't see how you can read that to imply you can have more than one = Hop-by-Hop extension header. > my reading (and what I think the _intention_ of the text was) is that = there can only be one Hop-By-Hop extension header, and > that the HBH header must be the first extension header in the chain. = this way routers only need to check the Next Header field > for the value of 0. +1 Bob From philip_matthews@magma.ca Thu Nov 8 13:16:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EDF21F89D2 for ; Thu, 8 Nov 2012 13:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmHd8o50S7lf for ; Thu, 8 Nov 2012 13:16:26 -0800 (PST) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 585C721F8487 for ; Thu, 8 Nov 2012 13:16:26 -0800 (PST) Received: from dhcp-1192.meeting.ietf.org ([130.129.17.146]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TWZSb-0003zn-1P for v6ops@ietf.org; Thu, 08 Nov 2012 16:16:25 -0500 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 16:16:23 -0500 Message-Id: To: "v6ops@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1192.meeting.ietf.org [130.129.17.146] Subject: [v6ops] Meetecho at V6OPS meetings? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:16:26 -0000 At the Large Interim Meeting, there was Meetecho support for the V6OPS = session, and I used it and found it fairly easy to use to follow the = meeting. (As well as anyone can follow a meeting remotely). I notice that there is no support for the Atlanta sessions.=20 I don't know what is involved, but I am just wondering if we could get = Meetecho support for the V6OPS Orlando meeting?=20 - Philip= From touch@isi.edu Thu Nov 8 13:21:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C221F8689 for ; Thu, 8 Nov 2012 13:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPfreKpomCaj for ; Thu, 8 Nov 2012 13:21:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 706CF21F8685 for ; Thu, 8 Nov 2012 13:21:14 -0800 (PST) Received: from [192.168.1.115] (24-121-24-110.npg.sta.suddenlink.net [24.121.24.110]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA8LJn9B014327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 13:19:59 -0800 (PST) Message-ID: <509C21F5.4030704@isi.edu> Date: Thu, 08 Nov 2012 13:19:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bob Hinden References: <5090DECF.3050100@gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu> <509381B3.9040602@gmail.com> <5093CF61.9090301@isi.edu> <509A7922.9080000@gmail.com> <509A8993.4000803@isi.edu> <55E816CE-22B4-4C81-BC8C-61D932782192@employees.org> <0B60F4C0-0E86-4F7F-8B22-7CC0E471D11F@gmail.com> In-Reply-To: <0B60F4C0-0E86-4F7F-8B22-7CC0E471D11F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 21:21:15 -0000 Well, I see only the word "should" here. Given how vendors already ignore "musts", I doubt we can expect them to be held to "shoulds". I agree with the intent, but am suggesting that any update on this issue might take the opportunity to clarify intent. Joe On 11/8/2012 1:05 PM, Bob Hinden wrote: > > On Nov 8, 2012, at 2:05 PM, Ole Trøan wrote: > >> Joe, >> >>> There's remains other problematic language in 2460, however: >>> >>> Each extension header should occur at most once, except for the >>> Destination Options header which should occur at most twice (once >>> before a Routing header and once before the upper-layer header). >>> >>> So it still seems open to have more than one HBH header, which certainly complicates things even though they'd be clearly marked. >> >> I don't see how you can read that to imply you can have more than one Hop-by-Hop extension header. >> my reading (and what I think the _intention_ of the text was) is that there can only be one Hop-By-Hop extension header, and >> that the HBH header must be the first extension header in the chain. this way routers only need to check the Next Header field >> for the value of 0. > > +1 > > Bob > From alexandru.petrescu@gmail.com Thu Nov 8 13:27:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4721F89E5 for ; Thu, 8 Nov 2012 13:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.919 X-Spam-Level: X-Spam-Status: No, score=-9.919 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuVWeXQvtz7e for ; Thu, 8 Nov 2012 13:27:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0047E21F8685 for ; Thu, 8 Nov 2012 13:27:58 -0800 (PST) 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 qA8LRvio005202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 22:27:57 +0100 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 qA8LRvgl020147; Thu, 8 Nov 2012 22:27:57 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-54.intra.cea.fr [132.166.201.54]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA8LRjkD004001; Thu, 8 Nov 2012 22:27:56 +0100 Message-ID: <509C23D1.1060807@gmail.com> Date: Thu, 08 Nov 2012 22:27:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tony Hain References: <509C0DFA.8010500@gmail.com> <01e801cdbdee$afdb8dc0$0f92a940$@tndh.net> In-Reply-To: <01e801cdbdee$afdb8dc0$0f92a940$@tndh.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comment on setting up an IPv6 cellular connection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 21:27:59 -0000 Le 08/11/2012 21:21, Tony Hain a écrit : > Try: > > https://sites.google.com/site/tmoipv6/lg-mytouch That may be useful to many but not to me. My operator does it differently. My equipment is not a phone but a usb dongled used in backwards compatible mode (3G+). My equipment may do simultaneous pdp contexts up to a point, when I want it, whereas this doesnt mention 2. Alex > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, November 08, 2012 11:55 AM To: v6ops@ietf.org >> Subject: [v6ops] Comment on setting up an IPv6 cellular connection >> >> There is a need of guidelines of how to set up an IPv6 connection, >> step by step, between a cellular host and the infrastructure. >> >> This is not as easy as saying - just like IPv4 - it's different. >> >> A possible example, given one particular operator, a particular >> terminal hardware and 3G (not LTE) one already has a particular set >> of steps to execute, AT commands, widely available software to >> install, to make it > work. >> >> This is what is very useful, maybe added up to requirements. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From philip_matthews@magma.ca Thu Nov 8 13:49:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AC21F8546 for ; Thu, 8 Nov 2012 13:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-uhp-rOGegE for ; Thu, 8 Nov 2012 13:49:28 -0800 (PST) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2408721F85B2 for ; Thu, 8 Nov 2012 13:49:27 -0800 (PST) Received: from dhcp-1192.meeting.ietf.org ([130.129.17.146]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TWZyZ-0008B9-0m; Thu, 08 Nov 2012 16:49:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20121108205347.GA25012@cappuccino.rob.sh> Date: Thu, 8 Nov 2012 16:49:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <80D39784-085C-4638-AAC0-0FADBA270959@magma.ca> References: <3AB4D8A4-B4A4-422B-8388-BFFA7D901FEC@magma.ca> <20121108205347.GA25012@cappuccino.rob.sh> To: Rob Shakir X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1192.meeting.ietf.org [130.129.17.146] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] New version of Design Guidelines draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2012 21:49:28 -0000 Thanks for your comment. I was not aware of the multi-session doc. I will look at it. - Philip On 2012-11-08, at 15:53 , Rob Shakir wrote: > On Mon, Oct 22, 2012 at 02:28:49PM -0400, Philip Matthews wrote: >> Folks: >>=20 >> I have just posted a new version (-01) of the Design Guidelines = draft: >> = https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/ = OR >> = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01 >=20 > Hi Philip, >=20 > Apologies, I did not notice this to comment at the mic in the meeting. >=20 > In the draft on the subject of eBGP sessions, you state: >=20 > However, there are three main concerns with option (a). First, on > most existing implementations, adding or removing an address family > to an established BGP session will cause the router to tear down and > re-establish the session. Thus adding the IPv6 family to an = existing > session carrying just IPv4 routes will disrupt the session, and the > eventual removal of IPv4 from the dual IPv4/IPv6 session will also > disrupt the session. This disruption problem will persist until > something similar to [I-D.ietf-idr-dynamic-cap] is widely deployed. >=20 > One should note that dynamic-cap is not the only option for not = disrupting a > session between two devices by adding new capabilities to it. For > IPv4/IPv6/VPNv4/VPNv6, running multi-session [0] will allow separate = sessions to > be utilised for each . In this case, the transport is still = over the > single underlying IP transport (whether it be IPv4, or IPv6). >=20 > This is notable because: > A) It allows adding new AFIs to an adjacency in a non-disruptive way. > B) It is already implemented in at least one major shipping = implementation - where > dynamic-cap is not implemented in any that I know of. > C) It provides some fault isolation between UPDATE and other BGP = errors in > {IP,VPN}v4/{IP,VPN}v6 AFIs. =20 > D) It retains the management simplicity of having a > single identifier for a remote peer, whilst having some of the = advantages of > separate sessions. >=20 > Of course it does not address the other concerns around different = transport > planes that are contained in the same section, but it is perhaps worth = nothing > in your draft. >=20 > Thanks, > r. >=20 >=20 > [0]: http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07 >=20 From tore.anderson@redpill-linpro.com Thu Nov 8 23:53:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C021F8B6D; Thu, 8 Nov 2012 23:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyHgLGTY8hDl; Thu, 8 Nov 2012 23:53:34 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDBE21F8B31; Thu, 8 Nov 2012 23:53:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B750B182001F; Fri, 9 Nov 2012 08:53:32 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3TpWbLjRIPl; Fri, 9 Nov 2012 08:53:28 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id B1E1E1820019; Fri, 9 Nov 2012 08:53:28 +0100 (CET) Message-ID: <509CB678.9090402@redpill-linpro.com> Date: Fri, 09 Nov 2012 08:53:28 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: "v6ops@ietf.org" , sunset4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-anderson-siit-dc-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, 09 Nov 2012 07:53:35 -0000 Good morning, I've just uploaded a new draft: Filename: draft-anderson-siit-dc Revision: 00 Title: Stateless IP/ICMP Translation in IPv6 Data Centre Environments Creation date: 2012-11-09 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-anderson-siit-dc-00.txt Status: http://datatracker.ietf.org/doc/draft-anderson-siit-dc Htmlized: http://tools.ietf.org/html/draft-anderson-siit-dc-00 Abstract: This document describes the use of Stateless IP/ICMP Translation (SIIT) in data centre environments in order to simultaneously facilitate IPv6 deployment and IPv4 address conservation. It describes the overall architecture, and provides guidelines for both operators and implementers. It's my first ever draft, so go easy on me. Note that this draft may be relevant to the discussion of draft-lopez-v6ops-dc-ipv6, as it documents in more technical detail a way to implement the "Next Generation Stage" briefly described in section 2.3. I do not know whether the discussion of this draft fits the best in v6ops or sunset4, so this message is cross-posted to both WGs. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From randy@psg.com Fri Nov 9 00:52:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6B21F8539 for ; Fri, 9 Nov 2012 00:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWErdFtUjTer for ; Fri, 9 Nov 2012 00:52:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1510721F8538 for ; Fri, 9 Nov 2012 00:52:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWkJx-000KVy-Qp; Fri, 09 Nov 2012 08:52:14 +0000 Date: Fri, 09 Nov 2012 17:52:12 +0900 Message-ID: From: Randy Bush To: Philip Matthews In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] Meetecho at V6OPS meetings? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:52:15 -0000 in what way was the meetecho broadcast more useful than the stream this week? randy From philip_matthews@magma.ca Fri Nov 9 06:26:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734021F85CB for ; Fri, 9 Nov 2012 06:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShbIVFLlvgIw for ; Fri, 9 Nov 2012 06:26:21 -0800 (PST) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1621F85BC for ; Fri, 9 Nov 2012 06:26:20 -0800 (PST) Received: from dhcp-1192.meeting.ietf.org ([130.129.17.146]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TWpXI-0000ou-0h; Fri, 09 Nov 2012 09:26:20 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Fri, 9 Nov 2012 09:26:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1192.meeting.ietf.org [130.129.17.146] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] Meetecho at V6OPS meetings? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:26:21 -0000 I could go to one place to get all the info about the session, rather = than juggling multiple apps. - Philip On 2012-11-09, at 3:52 , Randy Bush wrote: > in what way was the meetecho broadcast more useful than the stream = this > week? >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From mohamed.boucadair@orange.com Sun Nov 11 22:47:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCBD21F854B for ; Sun, 11 Nov 2012 22:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzM6Wzm6GmgJ for ; Sun, 11 Nov 2012 22:47:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B44FE21F84C4 for ; Sun, 11 Nov 2012 22:47:50 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0DE7C3B4233 for ; Mon, 12 Nov 2012 07:47:49 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D77F435C060 for ; Mon, 12 Nov 2012 07:47:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 12 Nov 2012 07:47:48 +0100 From: To: IPv6 Ops WG Date: Mon, 12 Nov 2012 07:47:48 +0100 Thread-Topic: draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3AoO7OcUkwg0OpTYK+OOMQp/alYAAAHbFQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> 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: 2012.10.24.110314 Subject: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 12 Nov 2012 06:47:54 -0000 Dear all, As discussed in the v6ops meeting, we re-submitted a new version of the tex= t which does not update RFC3316. We hope this new version is ready for the WG adoption. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 12 novembre 2012 07:42 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Internet Protocol Version 6 (IPv6) Requirements for Cell= ular Hosts Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-binet-v6ops-cellular-host-requirements-00.txt Pages : 15 Date : 2012-11-11 Abstract: This document lists a set of IPv6-related requirements to be supported by cellular hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-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 From swmike@swm.pp.se Mon Nov 12 00:12:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917E21F8487 for ; Mon, 12 Nov 2012 00:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1YRCo3hVSCh for ; Mon, 12 Nov 2012 00:12:57 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5327C21F847D for ; Mon, 12 Nov 2012 00:12:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 83D5E9C; Mon, 12 Nov 2012 09:12:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7D5F89A; Mon, 12 Nov 2012 09:12:53 +0100 (CET) Date: Mon, 12 Nov 2012 09:12:53 +0100 (CET) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 12 Nov 2012 08:12:58 -0000 On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote: > We hope this new version is ready for the WG adoption. I support adopting this as WG item, but I have some questions: In "http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/09.13.00_60/ts_123401v091300p.pdf" it says: "A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6" "If the requested PDN type is IPv4v6 and subscription data only allows PDN type IPv4 or only allows PDN type IPv6, the MME sets the PDN type according to the subscribed value. A reason cause shall be returned to the UE indicating that only the assigned PDN type is allowed. In this case the UE shall not request another PDN connection to the same APN for the other IP version" So this draft is duplicating language from 3GPP spec:s, correct? What is the rationale for the "particular" in REQ#3? Either it's in compliance or it's not, right? Perhaps a short paragraph on why the behaviour listed is especially important? Oh, REQ5 is interesting, I never understood how traffic was mapped into different bearers since the QoS is done per bearer. Now I know! REQ#8: Should perhaps say GGSN/PGW intead of "GGSN" to comply with 3GPP language for LTE as well? (I don't understand why they changed the names, but they did so...) REQ#9: Hm, I am not so sure about this one. What happens if PCO and RFC6106 gives different information? If DHCPv6 gives a third set? Or is this specified somewhere else? ... Ah, that's in REQ#10. my bad! REQ#10: Why shouldn't the host support DHCPv6 recursive DNS retreival if RFC6106 is supported? DHCPv6 gives more information than RFC6106, I think the device should support DHCPv6 regardless of RFC6106 support. REQ#11+12+13: +1 on the CLAT+NAT64+DNS64 stuff! REQ#15: Is the rationale here that a device with IPv4v6 PDP context will get a DNS64 enabled resolver? REQ#16: It would help here to just include the text "Happy Eyeballs" somewhere in the sentence, so I don't have to look at the RFC to identify what it is. REQ#17: Should not do DAD on the PDP context interface. In case of tethering/hotspot, it needs to do DAD on the wifi/lan interface, right? REQ#19: Shouldn't this be "IPv6 only"? A lot of devices today support IPv4+IPv6 on wifi, but they do not consider IPv6 only as "connected". Perhaps this could be clarified? 4. "these cellular devices have to meet". What does "have to" mean, is that a MUST but not written as such? This looks like an extremely useful document to have when sendning out requirements to equipment vendors. Thanks! -- Mikael Abrahamsson email: swmike@swm.pp.se From mohamed.boucadair@orange.com Mon Nov 12 01:18:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FE821F84F3 for ; Mon, 12 Nov 2012 01:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_41=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y-CMWJ-doru for ; Mon, 12 Nov 2012 01:18:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C421F84BB for ; Mon, 12 Nov 2012 01:18:37 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2219722C496; Mon, 12 Nov 2012 10:18:36 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 093E64C017; Mon, 12 Nov 2012 10:18:36 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 12 Nov 2012 10:18:35 +0100 From: To: Mikael Abrahamsson Date: Mon, 12 Nov 2012 10:18:34 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3ArYYkWcak1ZNgToadREZScsVcFgABo7GQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E947B1427@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> 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: 2012.11.12.80333 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 12 Nov 2012 09:18:38 -0000 Dear Mickael, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 >Envoy=E9 : lundi 12 novembre 2012 09:13 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt > >On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote: > >> We hope this new version is ready for the WG adoption. > >I support adopting this as WG item,=20 Med: Thanks.=20 but I have some questions: > >In=20 >"http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/09.13 >.00_60/ts_123401v091300p.pdf"=20 >it says: > >"A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6" > >"If the requested PDN type is IPv4v6 and subscription data=20 >only allows PDN=20 >type IPv4 or only allows PDN type IPv6, the MME sets the PDN type=20 >according to the subscribed value. A reason cause shall be=20 >returned to the=20 >UE indicating that only the assigned PDN type is allowed. In=20 >this case the=20 >UE shall not request another PDN connection to the same APN=20 >for the other=20 >IP version" > >So this draft is duplicating language from 3GPP spec:s,=20 >correct?=20 Med: Yes.=20 What is=20 >the rationale for the "particular" in REQ#3? Med: We wanted to focus on the specification part which describes the behav= iour for requesting IPv6-related PDP context(s). This is important to avoid= having broken IPv6 implementations in cellular devices.=20 Either it's in=20 >compliance or=20 >it's not, right? Perhaps a short paragraph on why the=20 >behaviour listed is=20 >especially important? > >Oh, REQ5 is interesting, I never understood how traffic was=20 >mapped into=20 >different bearers since the QoS is done per bearer. Now I know! Med: Great.=20 > >REQ#8: Should perhaps say GGSN/PGW intead of "GGSN" to comply=20 >with 3GPP=20 >language for LTE as well? (I don't understand why they changed=20 >the names,=20 >but they did so...) Med: OK. BTW, we have this text in the draft: The requirements listed below are valid for both 3GPP GPRS and 3GPP EPS access. For EPS, "PDN type" terminology is used instead of "PDP context". This is why we avoided repeating both terms.=20 > >REQ#9: Hm, I am not so sure about this one. What happens if PCO and=20 >RFC6106 gives different information? If DHCPv6 gives a third=20 >set? Or is=20 >this specified somewhere else? >... Ah, that's in REQ#10. my bad! Med: OK. > >REQ#10: Why shouldn't the host support DHCPv6 recursive DNS=20 >retreival if=20 >RFC6106 is supported?=20 Med: This is not what the req says. The req says:=20 REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. DHCPv6 gives more information than=20 >RFC6106, I think=20 >the device should support DHCPv6 regardless of RFC6106 support. Med: The sub-requirements is only about the DNS information. > >REQ#11+12+13: +1 on the CLAT+NAT64+DNS64 stuff! Med: OK. > >REQ#15: Is the rationale here that a device with IPv4v6 PDP=20 >context will=20 >get a DNS64 enabled resolver? Med: No. The point is the host has to enforce a procedure to prefer native = IPv6 connectivity.=20 > >REQ#16: It would help here to just include the text "Happy Eyeballs"=20 >somewhere in the sentence, so I don't have to look at the RFC=20 >to identify=20 >what it is. Med: OK. Done in my local copy. > >REQ#17: Should not do DAD on the PDP context interface. In case of=20 >tethering/hotspot, it needs to do DAD on the wifi/lan interface, right? Med: Yes. > >REQ#19: Shouldn't this be "IPv6 only"? A lot of devices today support=20 >IPv4+IPv6 on wifi, but they do not consider IPv6 only as "connected".=20 >Perhaps this could be clarified? Med: Good point. BTW, we have recorded an issue similar to the one you are = describing in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experime= nts-00#section-3.3. We will consider how to clarify the text. > >4. "these cellular devices have to meet". What does "have to" mean, is=20 >that a MUST but not written as such? Med: The normative language is used in each requirement. IMHO, no need to c= hange "have to" to "MUST". > > >This looks like an extremely useful document to have when sendning out=20 >requirements to equipment vendors. Thanks! Med: Thank you for the detailed review. From swmike@swm.pp.se Mon Nov 12 01:52:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3221F8484 for ; Mon, 12 Nov 2012 01:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3LqhEORM1h6 for ; Mon, 12 Nov 2012 01:52:18 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7480721F847D for ; Mon, 12 Nov 2012 01:52:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1BBA29C; Mon, 12 Nov 2012 10:52:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 14E0A9A; Mon, 12 Nov 2012 10:52:17 +0100 (CET) Date: Mon, 12 Nov 2012 10:52:17 +0100 (CET) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1427@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E947B1427@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 12 Nov 2012 09:52:19 -0000 On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote: > Med: We wanted to focus on the specification part which describes the > behaviour for requesting IPv6-related PDP context(s). This is important > to avoid having broken IPv6 implementations in cellular devices. Perhaps text could be included in the document about this, it's included for some other requirements. >> REQ#10: Why shouldn't the host support DHCPv6 recursive DNS >> retreival if >> RFC6106 is supported? > > Med: This is not what the req says. The req says: > > REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. > > DHCPv6 gives more information than >> RFC6106, I think >> the device should support DHCPv6 regardless of RFC6106 support. > > Med: The sub-requirements is only about the DNS information. Perhaps this could be clarified? >> REQ#15: Is the rationale here that a device with IPv4v6 PDP >> context will >> get a DNS64 enabled resolver? > > Med: No. The point is the host has to enforce a procedure to prefer native IPv6 connectivity. I think REQ#15 should be re-written. REQ#15: The cellular host SHOULD, when dual stacked, support means to prefer native IPv6 connection when faced with possibility of native IPv6, NAT64 or NAT44 connection to the same destination. ... or something to that effect. The find the current wording confusing. >> REQ#17: Should not do DAD on the PDP context interface. In case of >> tethering/hotspot, it needs to do DAD on the wifi/lan interface, right? > > Med: Yes. Clarification in the text? -- Mikael Abrahamsson email: swmike@swm.pp.se From mohamed.boucadair@orange.com Mon Nov 12 02:17:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6B821F8488 for ; Mon, 12 Nov 2012 02:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fwm-oNqpUwA for ; Mon, 12 Nov 2012 02:17:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0323821F844D for ; Mon, 12 Nov 2012 02:17:58 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 33EF23B41FE; Mon, 12 Nov 2012 11:17:57 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 12AF527C046; Mon, 12 Nov 2012 11:17:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 12 Nov 2012 11:17:56 +0100 From: To: Mikael Abrahamsson Date: Mon, 12 Nov 2012 11:17:55 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3Au2hesLopbpKjR+aCD9kd/MPnHQAAK/Dg Message-ID: <94C682931C08B048B7A8645303FDC9F36E947B14B5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E947B1427@PUEXCB1B.nanterre.francetelecom.fr> 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: 2012.10.24.110314 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 12 Nov 2012 10:17:59 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 >Envoy=E9 : lundi 12 novembre 2012 10:52 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : IPv6 Ops WG >Objet : RE: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt > >On Mon, 12 Nov 2012, mohamed.boucadair@orange.com wrote: > >> Med: We wanted to focus on the specification part which=20 >describes the=20 >> behaviour for requesting IPv6-related PDP context(s). This=20 >is important=20 >> to avoid having broken IPv6 implementations in cellular devices. > >Perhaps text could be included in the document about this,=20 >it's included=20 >for some other requirements. Med: I added this to my local copy: The text above focuses on the specification part which explains the behavior for requesting IPv6-related PDP context(s). Understanding this behavior is important to avoid having broken IPv6 implementations in cellular devices. Do we need to say more? > >>> REQ#10: Why shouldn't the host support DHCPv6 recursive DNS >>> retreival if >>> RFC6106 is supported? >> >> Med: This is not what the req says. The req says: >> >> REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. >> >> DHCPv6 gives more information than >>> RFC6106, I think >>> the device should support DHCPv6 regardless of RFC6106 support. >> >> Med: The sub-requirements is only about the DNS information. > >Perhaps this could be clarified? Med: I updated the text as follows: OLD: If [RFC6106] is not supported, the cellular host SHOULD retrieve DNS information using stateless DHCPv6 [RFC3736]. NEW: If [RFC6106] is not supported, the cellular host SHOULD retrieve DNS information using stateless DHCPv6 [RFC3736]. Note stateless DHCPv6 is useful to retrieve other information than DNS. > >>> REQ#15: Is the rationale here that a device with IPv4v6 PDP >>> context will >>> get a DNS64 enabled resolver? >> >> Med: No. The point is the host has to enforce a procedure to=20 >prefer native IPv6 connectivity. > >I think REQ#15 should be re-written. > >REQ#15: The cellular host SHOULD, when dual stacked, support means to=20 >prefer native IPv6 connection when faced with possibility of=20 >native IPv6,=20 >NAT64 or NAT44 connection to the same destination. > >... or something to that effect. The find the current wording=20 >confusing. Med: I updated the text as follows: OLD: REQ#15: The cellular host SHOULD support means to prefer native IPv6 connection over NAT64 devices or NAT44 when the cellular host gets dual stack connectivity. NEW: REQ#15: When the cellular host is dual stack connected, it SHOULD support means to prefer native IPv6 connection over NAT64 devices or NAT44. Better? > >>> REQ#17: Should not do DAD on the PDP context interface. In case of >>> tethering/hotspot, it needs to do DAD on the wifi/lan=20 >interface, right? >> >> Med: Yes. > >Clarification in the text? Med: I updated the text as follows: OLD: REQ#17: The cellular host SHOULD NOT perform Duplicate Address Detection (DAD) for these Global IPv6 addresses (as the GGSN or PDN-GW must not configure any IPv6 addresses using the prefix allocated to the cellular host). NEW: REQ#17: The cellular host SHOULD NOT perform Duplicate Address Detection (DAD) for these Global IPv6 addresses (as the GGSN or PDN-GW must not configure any IPv6 addresses using the prefix allocated to the cellular host). Refer to Section 4 for DAD considerations on the LAN interface when the 3GPP connection is shared. Are you Ok with the new text?= From fred@cisco.com Mon Nov 12 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F621F8580 for ; Mon, 12 Nov 2012 05:45:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGHQn6XAgxPz for ; Mon, 12 Nov 2012 05:45:02 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 28A4F21F856B for ; Mon, 12 Nov 2012 05:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=146; q=dns/txt; s=iport; t=1352727902; x=1353937502; h=date:from:message-id:to:subject:cc; bh=QbvE8pcCbl2ZJ52kGBTvYoJoFE3jpm0WQAn3VITKR58=; b=ZqrIyHApJF+zs5uYKBjzjfjYEnOENEFNFBljb5qdOSf23d/WBxt59ekX QrdSE/LopBST+1KS6b37T30qqcwxI2ke2bu6FVUcX2AQgIYTSf7dEN9xN VzS30UhOATRjYfDzJngWDoC9z59i685Xzn1r5m+QX7TYl6d52kcpdIVVb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYOAFT8oFCrRDoI/2dsb2JhbABEhVOsEAGQawQDgQGBCII3AWY8LYEKh2cMmnWfTo84gycDiFqOPo08gWuDEA X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="61264343" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 12 Nov 2012 13: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 qACDj1Fx001966; Mon, 12 Nov 2012 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id qACDj1t14317; Mon, 12 Nov 2012 05:45:01 -0800 (PST) Date: Mon, 12 Nov 2012 05:45:01 -0800 (PST) From: Message-Id: <201211121345.qACDj1t14317@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-binet-v6ops-cellular-host-requirements@tools.ietf.org Subject: [v6ops] new draft: draft-binet-v6ops-cellular-host-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2012 13:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements. Please take a look at it and comment. From Fred.L.Templin@boeing.com Tue Nov 13 08:50:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793EB21F8568 for ; Tue, 13 Nov 2012 08:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkkc5A4rQeA for ; Tue, 13 Nov 2012 08:50:41 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3922E21F8563 for ; Tue, 13 Nov 2012 08:50:39 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qADGob0G014058 for ; Tue, 13 Nov 2012 08:50:37 -0800 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qADGobkj014050 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 13 Nov 2012 08:50:37 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 13 Nov 2012 08:50:37 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Date: Tue, 13 Nov 2012 08:50:35 -0800 Thread-Topic: Operational Considerations for Tunnel Fragmentation and Reassembly Thread-Index: Ac3A3BDZSNS3sJ1xS7maXtntXJSpRwA4LXqw Message-ID: References: <201211121345.qACDj1t14317@ftpeng-update.cisco.com> In-Reply-To: <201211121345.qACDj1t14317@ftpeng-update.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [v6ops] Operational Considerations for Tunnel Fragmentation and Reassembly X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2012 16:50:41 -0000 Hi, At IETF85, I presented: "Operational Issues with Tunnel Maximum Transmission Unit (MTU)" (draft-generic-v6ops-tunmtu). Since that time, I have re-discovered RFC4459 ("MTU and Fragmentation Issues with In-the-Network Tunneling") which covers four possible tunnel MTU mitigations: "1. Fragmenting all too big encapsulated packets to fit in the paths, and reassembling them at the tunnel endpoints. 2. Signal to all the sources whose traffic must be encapsulated, and is larger than fits, to send smaller packets, e.g., using Path MTU Discovery (PMTUD)[7][8]. 3. Ensure that in the specific environment, the encapsulated packets will fit in all the paths in the network, e.g., by using MTU bigger than 1500 in the backbone used for encapsulation. 4. Fragmenting the original too big packets so that their fragments will fit, even encapsulated, in the paths, and reassembling them at the destination nodes. Note that this approach is only available for IPv4 under certain assumptions (see Section 3.4)." To avoid covering some of the same ground already examined by RFC4459, I have therefore re-scoped draft-generic-v6ops-tunmtu to look at the only solution alternative that can be applied generically; namely, tunnel fragmentation and reassembly. Please have a look at the latest version of the document and comment on the list: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ This document discusses new issues that have been uncovered since the publication of RFC4459, and also presents a new fragmentation and reassembly alternative that was not covered by the earlier works. Thanks - Fred fred.l.templin@boeing.com=20 From sarikaya2012@gmail.com Tue Nov 13 12:36:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0492D21F853C for ; Tue, 13 Nov 2012 12:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEEyv+xcUH+I for ; Tue, 13 Nov 2012 12:36:35 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84221F849A for ; Tue, 13 Nov 2012 12:36:35 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so12594618iec.31 for ; Tue, 13 Nov 2012 12:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=mNTG6FETS2H3gnBb3p8+Na9PO65FQmfGNcz7od812Kk=; b=AkmcQuYGVlIoR/j8Ki+9l6ZlZdQUQhn1XPiCvOR9hZpysXRr7z+JUv3uU/Z2LNG4oA 7b2+mO+12NDiUWONuurL/VUPlrDHYFqOdk6czUf8f9k8tNwzbJopGC0hgojVxt31F7lz Ixq2YYaPTVJ3uq68BmMxAoAqEcWAIZjFgNz8biTwoh3GhwDWAOO7tP3XnV9Voc0XctY+ vInTtLxmkmFhOQB7d+4QLiVkca2vTvrHlnmjKWjjqgcpC6tvJiYc0AjgzUK2iyp/g8Cc Y7QyPVNeh9QVfc8todnZynBow6iBQ0bMsfMDmrG4lzRdhx1a1RHfHqMsniJxEn7HIbPq UYUg== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr12342603igk.41.1352838994847; Tue, 13 Nov 2012 12:36:34 -0800 (PST) Received: by 10.231.85.26 with HTTP; Tue, 13 Nov 2012 12:36:34 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Nov 2012 14:36:34 -0600 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:36:37 -0000 I support the adoption. Regards, Behcet On Mon, Nov 12, 2012 at 12:47 AM, wrote: > Dear all, > > As discussed in the v6ops meeting, we re-submitted a new version of the t= ext which does not update RFC3316. > > We hope this new version is ready for the WG adoption. > > Cheers, > Med > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org > Envoy=E9 : lundi 12 novembre 2012 07:42 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Internet Protocol Version 6 (IPv6) Requirements= for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-binet-v6ops-cellular-host-requirements-00= .txt > Pages : 15 > Date : 2012-11-11 > > Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirem= ents > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-0= 0 > > > 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 wwwrun@rfc-editor.org Tue Nov 13 16:19:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91FB21F8771; Tue, 13 Nov 2012 16:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.682 X-Spam-Level: X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYX-x7dUYCKh; Tue, 13 Nov 2012 16:19:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6856A21F8679; Tue, 13 Nov 2012 16:19:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9F40DB1E00B; Tue, 13 Nov 2012 16:12:43 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121114001243.9F40DB1E00B@rfc-editor.org> Date: Tue, 13 Nov 2012 16:12:43 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6791 on Stateless Source Address Mapping for ICMPv6 Packets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2012 00:19:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6791 Title: Stateless Source Address Mapping for ICMPv6 Packets Author: X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston Status: Standards Track Stream: IETF Date: November 2012 Mailbox: xing@cernet.edu.cn, congxiao@cernet.edu.cn, dwing@cisco.com, rvaithia@cisco.com, gih@apnic.net Pages: 6 Characters: 11793 Updates: RFC6145 I-D Tag: draft-ietf-v6ops-ivi-icmp-address-07.txt URL: http://www.rfc-editor.org/rfc/rfc6791.txt A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From victor.kuarsingh@gmail.com Tue Nov 13 19:12:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DED21F860D for ; Tue, 13 Nov 2012 19:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yyg832JptSO for ; Tue, 13 Nov 2012 19:12:31 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE3FC21F85FF for ; Tue, 13 Nov 2012 19:12:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so13073043iec.31 for ; Tue, 13 Nov 2012 19:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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; bh=qzqNHH0AzHwTkduGD16P3kU+QgsAbLsOyyF7/FB6MHU=; b=pP05LweI1Uq6I8PTmjRPu1b03aouFjaXYASFImq7A8yIB/Uf48Yz/gn5FHVx9co4Jx KuBPsqbrP0fMGWTifMy+/gnG73Wm0SKTMIL+y9/6XJ/UDqgE8g+TP/rPuCpbnWEiu2JH KaaWJbtwjtW+4I8iX/CNyRW4msL4Wix9yEGrmo62hNr/OZqlmJ7sCs569pR1+1n5enbe r6cpjPG4IRZjXuCGzaWyBQkY3OC1xfKnflgeImTMjHzePU9R2bSIDBI7lSpPG7XYO8Hh x+wr9gxUQ5r496fDnzPMHTTfEVShONRz6dG/wnCUKw+lwhgSvZN+t1XjqXL2AaAsXSZj EVeQ== Received: by 10.50.160.166 with SMTP id xl6mr577814igb.74.1352862751125; Tue, 13 Nov 2012 19:12:31 -0800 (PST) Received: from [192.168.100.204] ([67.224.83.162]) by mx.google.com with ESMTPS id wh5sm272353igb.17.2012.11.13.19.12.25 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 19:12:29 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 13 Nov 2012 22:12:22 -0500 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: [v6ops] new draft: draft-binet-v6ops-cellular-host-requirements In-Reply-To: <201211121345.qACDj1t14317@ftpeng-update.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-binet-v6ops-cellular-host-requirements@tools.ietf.org Subject: Re: [v6ops] new draft: draft-binet-v6ops-cellular-host-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2012 03:12:32 -0000 V6ops/Draft Authors, Here are some comments on the updated draft (and it's relation to draft-korhonen-v6ops-rfc3316bis-00). I hope there is not too much overlap with other comments, I have not had time to review those as of yet. I would agree with the WG discussion that this draft (v6ops-cellular-host-requirements) is quite different then draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap (does not bother me as long as they are consistent where they overlap or it references the 3316bis document and removes the local document text) ON this draft: SECTION 2.1 - Wi-Fi IN section 2.1 (Wi-Fi) there is a very short set of requirements stated for the Wi-Fi interface. Given that this document is focused on the 3GPP interface and operation, perhaps you can just point to RFC 6434 (IPv6 Node Requirements). I note that since you don't mention SLACC in section 2.1, but do mention DHCPv6 (I would think that SLACC is likely a good idea to specify) Perhaps to make it easy, put RFC 6434 in REQ#19? OVERALL The draft seems to have a definite parallel target for 464XLAT operation. But most of the those requirements are SHOULDs in this document. I would think that some operators and handsets will want 464XLAT and some may not care (I am of the former myself - I want 464XLAT). That said, if a cell host needs to operate on a 464XLAT network, perhaps we need MUSTs in there? Would it make sense to spit off the requirements for 464XLAT and make them MUSTs within that section? Since they would be in different section, we can say "If the cellular host is intended to support 464XLAT operation, then the following section applies". (or something to that effect). Regards, Victor Kuarsingh On 2012-11-12 8:45 AM, "fred@cisco.com" wrote: > >A new draft has been posted, at >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements. >Please take a look at it and comment. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Nov 13 22:49:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E79221F8475; Tue, 13 Nov 2012 22:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3xabzp+V4cU; Tue, 13 Nov 2012 22:49:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AF21F87A6; Tue, 13 Nov 2012 22:49:34 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAE6nUbG049549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 06:49:32 GMT (envelope-from joelja@bogus.com) Message-ID: <50A33EFA.7070008@bogus.com> Date: Tue, 13 Nov 2012 22:49:30 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-dhc-addr-registration@tools.ietf.org, IPv6 Ops WG , dhcwg@ietf.org 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]); Wed, 14 Nov 2012 06:49:32 +0000 (UTC) Subject: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2012 06:49:35 -0000 I took a look at this draft since it was also presented in v6ops... http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 There's a couple issues that are quite striking. I kind of concur with Fred Baker that the most appropiate method for tracking l2/l3 binding for address identification is probably more akin to syslog. That is, since you don't really trust the hosts, having a switch/router, simply sysloging all new NDP cache entries pretty much achives the same thing execept with a lot less signaling. If a strong assertion of L2 identity in support of l2/l3 bindings is required 802.1x or the wireless equivalanet seems appropiate, e.g. it's what we do today. Availing oneself of a dhcp/ra option entails a lot of signaling for what is likely a relatively ephemeral port (windows machines and macs registering privacy addresses for example). specifiying a binding lifetime seems of limited utility since the host will probably discard the address long before the lifetime expires if it's sufficently long enough to allow for long lived connections using that address. From internet-drafts@ietf.org Wed Nov 14 08:26:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D221F8602; Wed, 14 Nov 2012 08:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbCOFbl8lmUS; Wed, 14 Nov 2012 08:26:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B1121F8506; Wed, 14 Nov 2012 08:26:38 -0800 (PST) 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.36 Message-ID: <20121114162630.17984.99960.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 08:26:30 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-06.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, 14 Nov 2012 16:26:39 -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 : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-06.txt Pages : 18 Date : 2012-11-14 Abstract: The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ra-guard-implementation= -06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 14 08:42:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E321F8622; Wed, 14 Nov 2012 08:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRAAjvn1ep7G; Wed, 14 Nov 2012 08:42:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31421F85C9; Wed, 14 Nov 2012 08:42:54 -0800 (PST) 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.36 Message-ID: <20121114164254.18000.28893.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 08:42:54 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-07.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, 14 Nov 2012 16:42:54 -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 : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-07.txt Pages : 18 Date : 2012-11-14 Abstract: The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ra-guard-implementation= -07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pete@systemnet.no Wed Nov 14 13:58:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49A521F880F for ; Wed, 14 Nov 2012 13:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCozlBBPt-Um for ; Wed, 14 Nov 2012 13:58:35 -0800 (PST) Received: from hk18-1.systemnet.no (hk18-1.systemnet.no [195.214.201.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC8321F8809 for ; Wed, 14 Nov 2012 13:58:35 -0800 (PST) Received: from [127.0.0.1] (pete@localhost.systemnet.no [127.0.0.1]) by hk18-1.systemnet.no (8.13.6/8.13.6) with ESMTP id qAELwTbu013367 for ; Wed, 14 Nov 2012 22:58:29 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Pete Vickers In-Reply-To: Date: Wed, 14 Nov 2012 22:58:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no> References: To: v6ops@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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, 14 Nov 2012 21:58:36 -0000 Hi, I'm very please with the way this draft is starting to look, just a = follow up on Victor's note though: Given that the 'DNS info' preference = order is set for multiple values received over cellular interface, I = believe that in the interests of consistent behaviour the same = preference order should also be mandated for wifi interface acquired = values. I think this effectively adds REQ 19.5 as SLACC, which is also = fine by me.=20 regards, Pete Vickers On 14. nov. 2012, at 21.00, v6ops-request@ietf.org wrote: >=20 >=20 > Message: 3 > Date: Tue, 13 Nov 2012 22:12:22 -0500 > From: Victor Kuarsingh > To: , > Cc: draft-binet-v6ops-cellular-host-requirements@tools.ietf.org > Subject: Re: [v6ops] new draft: > draft-binet-v6ops-cellular-host-requirements > Message-ID: > Content-Type: text/plain; charset=3D"US-ASCII" >=20 > V6ops/Draft Authors, >=20 > Here are some comments on the updated draft (and it's relation to > draft-korhonen-v6ops-rfc3316bis-00). I hope there is not too much = overlap > with other comments, I have not had time to review those as of yet. >=20 > I would agree with the WG discussion that this draft > (v6ops-cellular-host-requirements) is quite different then > draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap (does not > bother me as long as they are consistent where they overlap or it > references the 3316bis document and removes the local document text) >=20 > ON this draft: >=20 >=20 > SECTION 2.1 - Wi-Fi > IN section 2.1 (Wi-Fi) there is a very short set of requirements = stated > for the Wi-Fi interface. Given that this document is focused on the = 3GPP > interface and operation, perhaps you can just point to RFC 6434 (IPv6 = Node > Requirements). =20 >=20 > I note that since you don't mention SLACC in section 2.1, but do = mention > DHCPv6 (I would think that SLACC is likely a good idea to specify) >=20 > Perhaps to make it easy, put RFC 6434 in REQ#19? >=20 >=20 > OVERALL >=20 > The draft seems to have a definite parallel target for 464XLAT = operation. > But most of the those requirements are SHOULDs in this document. >=20 > I would think that some operators and handsets will want 464XLAT and = some > may not care (I am of the former myself - I want 464XLAT). >=20 > That said, if a cell host needs to operate on a 464XLAT network, = perhaps > we need MUSTs in there? >=20 > Would it make sense to spit off the requirements for 464XLAT and make = them > MUSTs within that section? Since they would be in different section, = we > can say "If the cellular host is intended to support 464XLAT = operation, > then the following section applies". (or something to that effect). >=20 > Regards, >=20 > Victor Kuarsingh >=20 >=20 From internet-drafts@ietf.org Wed Nov 14 14:11:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1E21F85A5; Wed, 14 Nov 2012 14:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWZfqZI1nK4g; Wed, 14 Nov 2012 14:11:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF821F8554; Wed, 14 Nov 2012 14:11:44 -0800 (PST) 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.36 Message-ID: <20121114221144.4582.8950.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 14:11:44 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-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, 14 Nov 2012 22:11:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-00.txt Pages : 18 Date : 2012-11-12 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionality that needs to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues relating to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From philip_matthews@magma.ca Wed Nov 14 14:38:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038F21F8878 for ; Wed, 14 Nov 2012 14:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luDeycoe4+XK for ; Wed, 14 Nov 2012 14:38:48 -0800 (PST) Received: from mail-07.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5AD21F8877 for ; Wed, 14 Nov 2012 14:38:47 -0800 (PST) Received: from [74.198.165.58] (helo=[172.20.10.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TYlbY-0007bA-2m; Wed, 14 Nov 2012 17:38:47 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20121114162630.17984.99960.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 17:38:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121114162630.17984.99960.idtracker@ietfa.amsl.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.58] Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-06.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, 14 Nov 2012 22:38:48 -0000 Two comments on version -07 of this draft. The draft says (section 3): 3. RA-Guard must parse the IPv6 entire header chain present in the packet, to identify whether the packet is a Router Advertisement message. RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension Header, thus meaning that an IPv6 node can parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Additionally, [I-D.ietf-6man-oversized-header-chain] requires that if a packet is fragmented, the first fragment contains the entire IPv6 header chain. RA-Guard implementations must not enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false- positives: legitimate packets could be dropped simply because the RA-Guard device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit must not claim compliance with this specification, and must pass the packet when such implementation-specific limit is reached. First (and I apologize if this is a silly question): If an RA-Guard = implementation encounters a protocol number that it does not recognize, = then how does it know that this number corresponds to an unrecognized = extension header (which follows the format of RFC 6564) and not some new = layer 4 protocol (which will likely not follow RFC 6564)? That is, when = an RA-Guard implementation encounters a protocol number N which it does = not recognize, then how does it select between the following two = options: a) Protocol number N is a new extension header (which the = implementation does not recognize) and it should skip over the header = and keep on parsing up the stack, OR b) Protocol number N is a new layer 4 protocol (which the = implementation does not recognize) and it should discard the packet. Second (and we already discussed this in OPSEC, so I am repeating this = so the WG can hear it): I am concerned with the last sentence that says = "An implementation that has such an implementation-specific limit ... = must pass the packet when such implementation-specific limit is = reached." It seems to me that an operator would strongly prefer the = RA-Guard to drop the packet when the limit is reached, rather than = forwarding it.=20 - Philip From rajiva@cisco.com Wed Nov 14 15:04:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE121F85D4 for ; Wed, 14 Nov 2012 15:04:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VhcAFbW9utJ for ; Wed, 14 Nov 2012 15:04:35 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5021F8558 for ; Wed, 14 Nov 2012 15:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2508; q=dns/txt; s=iport; t=1352934275; x=1354143875; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hci7h3qQknXOxBPY4qYKPHaR1uQqE2HbCJdIXLLwl28=; b=K29xIrjITECGL4msHd5q8al1UezN4/Io3nuec9BBe4TngR4Ll2uGpkxy Pjr3o1/o9JunPudWyJ2FpaInDBigjUwkDBfFnBHpTsaNMiEWWianVhokn CymYmbA6aia3iYCSFUHsZ84rVy/PRlcu2Q8tKhPNLCShveqJO8QNaPJD/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMJALQipFCtJV2d/2dsb2JhbABEw0KBAQeCHgEBAQQBAQEPASc0FwYBCBEDAQILFDcLHQgCBBMIGodpC5l6gSugDYwthUthA5cYjTyBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142519505" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Nov 2012 23:04:34 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEN4YjI010333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 Nov 2012 23:04:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 17:04:34 -0600 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-00.txt Thread-Index: AQHNwrU1/qGNpaD4zU+wkbx1S7vDbZfqBCYA Date: Wed, 14 Nov 2012 23:04:33 +0000 Message-ID: In-Reply-To: <20121114221144.4582.8950.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.82.250.30] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--37.364800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1F0F95C8356E784287890EED30C63C96@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-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, 14 Nov 2012 23:04:36 -0000 It would be helpful if this document also included IP-CAN session nomenclature (along with PDP). Cheers, Rajiv -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, November 14, 2012 5:11 PM To: "i-d-announce@ietf.org" Cc: "v6ops@ietf.org" Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Operations Working Group of the >IETF. > > Title : IPv6 for 3GPP Cellular Hosts > Author(s) : Jouni Korhonen > Jari Arkko > Teemu Savolainen > Suresh Krishnan > Filename : draft-ietf-v6ops-rfc3316bis-00.txt > Pages : 18 > Date : 2012-11-12 > >Abstract: > As the deployment of third and fourth generation cellular networks > progresses, a large number of cellular hosts are being connected to > the Internet. Standardization organizations are making Internet > Protocol version 6 (IPv6) mandatory in their specifications. > However, the concept of IPv6 covers many aspects and numerous > specifications. In addition, the characteristics of cellular links > in terms of bandwidth, cost and delay put special requirements on how > IPv6 is used. This document considers IPv6 for cellular hosts that > attach to the General Packet Radio Service (GPRS), Universal Mobile > Telecommunications System (UMTS), or Evolved Packet System (EPS) > networks (Hereafter collectively referred to as 3GPP networks). This > document also lists out specific IPv6 functionality that needs to be > implemented in addition what is already prescribed in the IPv6 Node > Requirements document. It also discusses some issues relating to the > use of these components when operating in these networks. This > document obsoletes RFC 3316. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Thu Nov 15 00:59:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088421F869C for ; Thu, 15 Nov 2012 00:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HrfNPRzwRX3 for ; Thu, 15 Nov 2012 00:59:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31D21F85CD for ; Thu, 15 Nov 2012 00:59:10 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8D62122D1E0; Thu, 15 Nov 2012 09:59:09 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6D2F04C05D; Thu, 15 Nov 2012 09:59:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 15 Nov 2012 09:59:09 +0100 From: To: Pete Vickers , "v6ops@ietf.org" Date: Thu, 15 Nov 2012 09:59:08 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3CsznvtYo/1r2sT1itStpsPoEU+AAURYhw Message-ID: <94C682931C08B048B7A8645303FDC9F36E95C9F626@PUEXCB1B.nanterre.francetelecom.fr> References: <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no> In-Reply-To: <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no> 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: 2012.10.24.110314 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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, 15 Nov 2012 08:59:11 -0000 Dear Pete, Thank you for your comment. I updated REQ#21 to add a preference order for DNS information: (1) RA, (2)= DHCPv6. As for REQ#19, I updated it as follows: * Add a reference to SLAAC * Focus on the support of IPv6-only connectivity mode (as this is not well = supported by some handsets). Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Pete Vickers >Envoy=E9 : mercredi 14 novembre 2012 22:58 >=C0 : v6ops@ietf.org >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt > >Hi, > > > >I'm very please with the way this draft is starting to look,=20 >just a follow up on Victor's note though: Given that the 'DNS=20 >info' preference order is set for multiple values received=20 >over cellular interface, I believe that in the interests of=20 >consistent behaviour the same preference order should also be=20 >mandated for wifi interface acquired values. I think this=20 >effectively adds REQ 19.5 as SLACC, which is also fine by me.=20 > > >regards, > >Pete Vickers > > > > > > > > >On 14. nov. 2012, at 21.00, v6ops-request@ietf.org wrote: > > >>=20 >>=20 >> Message: 3 >> Date: Tue, 13 Nov 2012 22:12:22 -0500 >> From: Victor Kuarsingh >> To: , >> Cc: draft-binet-v6ops-cellular-host-requirements@tools.ietf.org >> Subject: Re: [v6ops] new draft: >> draft-binet-v6ops-cellular-host-requirements >> Message-ID: >> Content-Type: text/plain; charset=3D"US-ASCII" >>=20 >> V6ops/Draft Authors, >>=20 >> Here are some comments on the updated draft (and it's relation to >> draft-korhonen-v6ops-rfc3316bis-00). I hope there is not=20 >too much overlap >> with other comments, I have not had time to review those as of yet. >>=20 >> I would agree with the WG discussion that this draft >> (v6ops-cellular-host-requirements) is quite different then >> draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap=20 >(does not >> bother me as long as they are consistent where they overlap or it >> references the 3316bis document and removes the local document text) >>=20 >> ON this draft: >>=20 >>=20 >> SECTION 2.1 - Wi-Fi >> IN section 2.1 (Wi-Fi) there is a very short set of=20 >requirements stated >> for the Wi-Fi interface. Given that this document is=20 >focused on the 3GPP >> interface and operation, perhaps you can just point to RFC=20 >6434 (IPv6 Node >> Requirements). =20 >>=20 >> I note that since you don't mention SLACC in section 2.1,=20 >but do mention >> DHCPv6 (I would think that SLACC is likely a good idea to specify) >>=20 >> Perhaps to make it easy, put RFC 6434 in REQ#19? >>=20 >>=20 >> OVERALL >>=20 >> The draft seems to have a definite parallel target for=20 >464XLAT operation. >> But most of the those requirements are SHOULDs in this document. >>=20 >> I would think that some operators and handsets will want=20 >464XLAT and some >> may not care (I am of the former myself - I want 464XLAT). >>=20 >> That said, if a cell host needs to operate on a 464XLAT=20 >network, perhaps >> we need MUSTs in there? >>=20 >> Would it make sense to spit off the requirements for 464XLAT=20 >and make them >> MUSTs within that section? Since they would be in different=20 >section, we >> can say "If the cellular host is intended to support 464XLAT=20 >operation, >> then the following section applies". (or something to that effect). >>=20 >> Regards, >>=20 >> Victor Kuarsingh >>=20 >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From fred@cisco.com Thu Nov 15 05:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0780121F88CF for ; Thu, 15 Nov 2012 05:45:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPBPRxV4NN18 for ; Thu, 15 Nov 2012 05:45:02 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E553921F88D0 for ; Thu, 15 Nov 2012 05:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1352987101; x=1354196701; h=date:from:message-id:to:subject:cc; bh=c+Ay8sh3+zqnEFC7SJyXPpB5Q7huzTQ64Chy7l1uek4=; b=JZLRkovL6tXuyRtf+/BOOzDRbybXG3SHN+gi5IBEl4i8JeieOehglWXN Y6EO5YitGZCg9QEzVcIZHXzrI00wl+Zl/5GF/qH2WlTfV2ZenKYqJf89e 803ZeMxY56mSdpNIPyrH9nPC+RmdvHPXmPOk0E7JYmJ9hx0u0VMlzDn0e g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsINAH3xpFCrRDoJ/2dsb2JhbABEhVaragGQfQQDgQSBCII3AWY8LYEKh2gMnEagCY82gycDiFqOPo08gWuDEA X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="60999675" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2012 13: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 qAFDj1DY012255; Thu, 15 Nov 2012 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id qAFDj1h29158; Thu, 15 Nov 2012 05:45:01 -0800 (PST) Date: Thu, 15 Nov 2012 05:45:01 -0800 (PST) From: Message-Id: <201211151345.qAFDj1h29158@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-rfc3316bis@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-rfc3316bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2012 13:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis. Please take a look at it and comment. From mohamed.boucadair@orange.com Thu Nov 15 06:59:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1508221F892B for ; Thu, 15 Nov 2012 06:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is7O0-2FkVrF for ; Thu, 15 Nov 2012 06:59:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADD621F850D for ; Thu, 15 Nov 2012 06:59:54 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 916FB2DC4D7; Thu, 15 Nov 2012 15:59:53 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7275635C070; Thu, 15 Nov 2012 15:59:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 15 Nov 2012 15:59:53 +0100 From: To: "v6ops@ietf.org" , Mikael Abrahamsson , Pete Vickers Date: Thu, 15 Nov 2012 15:59:51 +0100 Thread-Topic: draft-binet-v6ops-cellular-host-requirements-01 Thread-Index: Ac3DQPNOiO8HJcjRRLSzPIDmi5SHnwAAA+ng Message-ID: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> 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: 2012.10.24.110314 Subject: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2012 14:59:55 -0000 Dear all, We submitted a new version of the draft to take into account the comments r= eceived from M. Abrahamsson and P. Vickers. The main changes are: * Add some clarification text for REQ#3 * Mention stateless dhcpv6 is useful to retrieve other information than DNS * Re-word REQ#15 * Cite "Happy Eyeballs" in REQ#16 * Update the text of REQ#17 * Add two sub-requirements to REQ#19: IPv6-only connectivity + SLAAC * Precise the ordering in REQ#21 A more detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-requirem= ents-01 Chairs, would it be possible to issue a Call For Adoption for this document= ? Thanks. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 15 novembre 2012 15:53 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Internet Protocol Version 6 (IPv6) Requirements for Cell= ular Hosts Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-binet-v6ops-cellular-host-requirements-01.txt Pages : 16 Date : 2012-11-15 Abstract: This document lists a set of IPv6-related requirements to be supported by cellular hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-requirem= ents-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 From tore.anderson@redpill-linpro.com Thu Nov 15 07:12:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1821F8513 for ; Thu, 15 Nov 2012 07:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG+WVnNMeSiN for ; Thu, 15 Nov 2012 07:12:19 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8221F8488 for ; Thu, 15 Nov 2012 07:12:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E91C5182004B; Thu, 15 Nov 2012 16:12:17 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM6LMq+dd7rv; Thu, 15 Nov 2012 16:12:12 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 96D5F1820057; Thu, 15 Nov 2012 16:12:10 +0100 (CET) Message-ID: <50A5064A.1070208@redpill-linpro.com> Date: Thu, 15 Nov 2012 16:12:10 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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, 15 Nov 2012 15:12:26 -0000 Hi, REQ#8 («the cellular host MUST use the interface identifier sent in PDP Context Accept message to configure its link local address») is rather tricky to implement for a cellular dongle that emulate an Ethernet device (such as an USB CDC Ethernet class device). In that case, the dongle provides an invented Ethernet MAC address from which the host derives an link local address using EUI-64. Since this link local address does not have the correct interface identifier, ND may (partially) break. In particular, I've experienced that when sending an RS from such an EUI-64-derived link local address to the network, the GGSN reponds with an RA that is unicasted to the link local address the network expects the hosts to have. The host has no knowledge of this address, and discards the RA. I don't have a good answer to how this problem should be solved. However, if the document could make some recommendations (or at least describe the problem), that would be good. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From jouni.nospam@gmail.com Thu Nov 15 07:39:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED7F21F844F for ; Thu, 15 Nov 2012 07:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLz2DBDnYG79 for ; Thu, 15 Nov 2012 07:39:43 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67821F8427 for ; Thu, 15 Nov 2012 07:39:41 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1172507eek.31 for ; Thu, 15 Nov 2012 07:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+2QyVzeZsNcNXHrFaD3ez0tIaE3PTregGKi4mGWVKhI=; b=bRdfI1hozNSSRMnyII9V1F+cCvUwhtoDY3+qBAMD701bDaOsA1fw5FnPNG0NSghi82 5XQPb9dRO5M7EKyZLVoyqjowqjTKNStjJS5hpBEQbklQJ0lCZHDqdlgJ1dlIYSLDLwXP pC4fQHQSpLIBOda+6LBwbdu8qDHaHAOZbOapTIlVFsg2SviFEPuXTYqviNBSrRxgrtAl vKKC3xtxCuEOQf3RXSsvV/iUCBSE+CdG7+jlJTJHyd4eU6/y7Uwy76GOfO3k4GjxVokt 6rCFujb40Y35uhi+u2HLye0htZKlFaS5xengODwRwnYB2eBKVtjOi+ILVQ/qux6GkwBS EAsQ== Received: by 10.14.209.6 with SMTP id r6mr4820555eeo.34.1352993980602; Thu, 15 Nov 2012 07:39:40 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id o47sm36809550eem.11.2012.11.15.07.39.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 07:39:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 15 Nov 2012 17:39:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1283) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2012 15:39:44 -0000 Med, I am slightly confused about the overlap of draft-binet-v6ops-* and = draft-ietf-v6ops-rfc3316bis. My recollection was that overlaps were = supposed to be removed and then concentrate on the remaining part in = draft-binet-v6ops-*, no? This would concern requirements #1, #6, #7, #8, = #9, #17, #22, #23, #25, #26, #27. My recommendation would be removing = those and just reference to [draft-ietf-v6ops-rfc3316bis] because the = base IPv6 compliancy would come from there and I see no reason to repeat = those here. Then a question about the relevance of #24. Given the current bandwidth = in 3G/LTE is there really a need to compress headers? And if people = really see it as a life critical feature to have, I would appreciate = listing the ROHC profiles that are essential (e.g., align with IR.92 & = IR.58 that will be implemented on the network side). - Jouni On Nov 15, 2012, at 4:59 PM, = wrote: > Dear all, >=20 > We submitted a new version of the draft to take into account the = comments received from M. Abrahamsson and P. Vickers. >=20 > The main changes are: >=20 > * Add some clarification text for REQ#3 > * Mention stateless dhcpv6 is useful to retrieve other information = than DNS > * Re-word REQ#15 > * Cite "Happy Eyeballs" in REQ#16 > * Update the text of REQ#17 > * Add two sub-requirements to REQ#19: IPv6-only connectivity + SLAAC > * Precise the ordering in REQ#21 >=20 > A more detailed diff is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-require= ments-01 >=20 >=20 > Chairs, would it be possible to issue a Call For Adoption for this = document? Thanks. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org > Envoy=E9 : jeudi 15 novembre 2012 15:53 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: = draft-binet-v6ops-cellular-host-requirements-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Internet Protocol Version 6 (IPv6) = Requirements for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : = draft-binet-v6ops-cellular-host-requirements-01.txt > Pages : 16 > Date : 2012-11-15 >=20 > Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requireme= nts >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-01= >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-require= ments-01 >=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 david.binet@orange.com Thu Nov 15 08:05:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEAA21F845E for ; Thu, 15 Nov 2012 08:05:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNjt+9o55BSQ for ; Thu, 15 Nov 2012 08:05:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A5C9321F897C for ; Thu, 15 Nov 2012 08:05:07 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E1A1D22C550; Thu, 15 Nov 2012 17:05:06 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C78BD35C065; Thu, 15 Nov 2012 17:05:06 +0100 (CET) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.14]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 15 Nov 2012 17:05:01 +0100 From: To: Tore Anderson , BOUCADAIR Mohamed OLNC/OLN Date: Thu, 15 Nov 2012 17:04:59 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3DQ6OI3aQDkepgQaSdLjfteMEhpgAAnXuQ Message-ID: <24584_1352995506_50A512B2_24584_1846_1_1B2E7539FECD9048B261B791B1B24A7C3EF3E0DDBA@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <50A5064A.1070208@redpill-linpro.com> In-Reply-To: <50A5064A.1070208@redpill-linpro.com> 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: 2012.10.24.110314 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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, 15 Nov 2012 16:05:13 -0000 Hi, It seems it is an implementation issue. REQ#8 mandates the use of Interface Identifier sent by the Gateway to confi= gure the link local address and actually it is consistent with 3GPP specifi= cation.=20 We have integrated in last version of the draft some other implementation i= ssue we may have on Wi-Fi interface (report to REQ#19).=20=20 Please provide some text if you want to describe some implementation issues= you have identified.=20=20 Best Regards David > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part de Tore Anderson > Envoy=E9 : jeudi 15 novembre 2012 16:12 > =C0 : BOUCADAIR Mohamed OLNC/OLN > Cc : IPv6 Ops WG > Objet : Re: [v6ops]=20 > draft-binet-v6ops-cellular-host-requirements-00.txt >=20 > Hi, >=20 > REQ#8 (=ABthe cellular host MUST use the interface identifier=20 > sent in PDP Context Accept message to configure its link=20 > local address=BB) is rather tricky to implement for a cellular=20 > dongle that emulate an Ethernet device (such as an USB CDC=20 > Ethernet class device). In that case, the dongle provides an=20 > invented Ethernet MAC address from which the host derives an=20 > link local address using EUI-64. >=20 > Since this link local address does not have the correct=20 > interface identifier, ND may (partially) break. In=20 > particular, I've experienced that when sending an RS from=20 > such an EUI-64-derived link local address to the network, the=20 > GGSN reponds with an RA that is unicasted to the link local=20 > address the network expects the hosts to have. The host has=20 > no knowledge of this address, and discards the RA. >=20 > I don't have a good answer to how this problem should be solved. > However, if the document could make some recommendations (or=20 > at least describe the problem), that would be good. >=20 > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com=20 > _______________________________________________ > 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From markzzzsmith@yahoo.com.au Thu Nov 15 11:32:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65AE21F8528 for ; Thu, 15 Nov 2012 11:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwIXqubQa1fT for ; Thu, 15 Nov 2012 11:32:58 -0800 (PST) Received: from nm12.bullet.mail.bf1.yahoo.com (nm12.bullet.mail.bf1.yahoo.com [98.139.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id B48A521F8522 for ; Thu, 15 Nov 2012 11:32:58 -0800 (PST) Received: from [98.139.215.140] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 19:32:57 -0000 Received: from [98.139.212.232] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 19:32:57 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 19:32:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831940.1204.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 6364 invoked by uid 60001); 15 Nov 2012 19:32:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1353007977; bh=mSdOekFob54rH/08lCbnBVxX5G72n/ycs2FGLvZ5R5c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZPDh/zAnzG0MUfWrAxROqVWnzFfZEgTYeWcWIxal6Akif0Bcy0/FA8o0ecL8LEkpTuDyTECw6pPzXjt/tmUoimKWd10fCRkAIUFf+1tTkPxmlD67xa4KjAUw0DLDlN65h93jZY0PYYAs87N/T0ShVUkuqwjib0q2sAgZ8mycy3A= 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:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5giHhNR8NxCZc3KacAu1zbCrO4Eh7IeoIAFIHGk93QFptG/K2cNGzzkEPAL2ejweK6Wc9sUtvMDpKRkuDcRDwt/5JJV8reGhSQerPM98AquN0KtWV2op5lamPQAA2qZMP2YP/sJbLrvep8L0P7Gi0jZIWfmWjKueBR56OZshj8I=; X-YMail-OSG: gyto7C4VM1kp5QQR4cy_ARnZXDQfoKnwtXJnMB6WLkHt4wd 5GEdzwEflsrxCBhNeZ6t1Uf2hL56utbjxHeVZtneISEqJja44zMNSzJcWKlF X7RAN_21iM97cNnqzXmy7StE81vPmZHuUrO5v0DnP.blMS_EbguYhFTgVoII mODLC2OoURKIRulg.6wuVQkwFEqO7..YgvCppNzcJ2syFDHLWa2_zeWVVcJO FJwJwhUIhdwduOnCNPUnP8Am74xQfW2l9nOHyvPVVujfCABtfNqoSgqrIJBk P8Z.qwUNpbOAV3jgP6lQHtuOZUEOOph2BpFrWpLbHf7wS4OTgbV6vGFK0Z27 iWiSKwVNtOJhUWTkJTOuBe76ApZoGKms9Vc7Te97jmmzV3TD5HjyQ543ncOy cbHiQamLkSmuV2ZF3paPsyOjBJ7X6moOuwBd0Hbobx2ZQ68W2vWTyJ8qcCUA So4HA3NgyPXx2n0QTyjTyXs11qCcfqyxR2MlsTlSFNJSSG6PsMsiV8IEaK4v nrj947LUvJEZJV4Im2eP9Z7KQhQzsIeYPZFd3lj533KusfxhuwVcAQ2Oa_Ki D2tm19wIE1vMDYqfnHXKUJddQMow76CLL6Xc59s1mzr1aUcWZ7vComx1Xpmv 7KhLcejqjL27ECsMOkWBK310n4Nr0Hidl9PndEpRb_wxwoPSG0pAX9h3AZTZ jw99FuhNYL9Hp Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2012 11:32:56 PST X-Rocket-MIMEInfo: 001.001, SGksCgpBcyBJIHdhc24ndCBnb2luZyB0byBiZSBhdHRlbmRpbmcgdGhlIHJlY2VudCBJRVRGIG1lZXRpbmcsIEkgZGlkbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIHY2b3BzIG1lZXRpbmcgYWdlbmRhLiBJdCB3YXMgb25seSBhIGRheSBvciBzbyBiZWZvcmUgdGhlIG1lZXRpbmcgdGhhdCBJIGRpc2NvdmVyZWQgdGhhdCBteSBkcmFmdCwgIkEgTGFyZ2VyIExvb3BiYWNrIFByZWZpeCBmb3IgSVB2NiIgd2FzIG9uIGl0LsKgSSBxdWlja2x5IHB1dCB0b2dldGhlciBhIHByZXNlbnRhdGlvbi4gSSdtIG5vdCBzdXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1353007976.97173.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Thu, 15 Nov 2012 11:32:56 -0800 (PST) From: Mark Smith To: v6ops v6ops WG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Short presentation on "A Larger Loopback Prefix for IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:32:59 -0000 Hi,=0A=0AAs I wasn't going to be attending the recent IETF meeting, I didn'= t pay attention to the v6ops meeting agenda. It was only a day or so before= the meeting that I discovered that my draft, "A Larger Loopback Prefix for= IPv6" was on it.=A0I quickly put together a presentation. I'm not sure it = was covered at the meeting, so here it is instead :=0A=0Ahttp://www.users.o= n.net/~markachy/ietf-allpipv6.pdf=0A=0A=0AIt's 4 slides of content so shoul= d only take 5 minutes to go through.=0A=0AThe main thing I'm curious about = is if I should put time into further researching and writing the appendix t= hat I mention on the last slide.=0A=0AThe current version of the draft is h= ere :=0A=0Ahttp://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopbac= k-prefix-01=0A=0A=0AThanks very much,=0AMark. From joelja@bogus.com Thu Nov 15 11:55:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3413B21F8AC7 for ; Thu, 15 Nov 2012 11:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfT41lEF9jsR for ; Thu, 15 Nov 2012 11:55:11 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA8721F8A57 for ; Thu, 15 Nov 2012 11:55:11 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAFJtBvF071756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 19:55:11 GMT (envelope-from joelja@bogus.com) Message-ID: <50A54899.1040902@bogus.com> Date: Thu, 15 Nov 2012 11:55:05 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mark Smith References: <1353007976.97173.YahooMailNeo@web32502.mail.mud.yahoo.com> In-Reply-To: <1353007976.97173.YahooMailNeo@web32502.mail.mud.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, 15 Nov 2012 19:55:11 +0000 (UTC) Cc: v6ops v6ops WG Subject: Re: [v6ops] Short presentation on "A Larger Loopback Prefix for 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: Thu, 15 Nov 2012 19:55:12 -0000 I'm working on the minutes still, but your slides were presented in the meeting, and there was some feedback that appears in the jabber logs. I hope to be able to post the draft minutes by saturday. On 11/15/12 11:32 AM, Mark Smith wrote: > Hi, > > As I wasn't going to be attending the recent IETF meeting, I didn't pay attention to the v6ops meeting agenda. It was only a day or so before the meeting that I discovered that my draft, "A Larger Loopback Prefix for IPv6" was on it. I quickly put together a presentation. I'm not sure it was covered at the meeting, so here it is instead : > > http://www.users.on.net/~markachy/ietf-allpipv6.pdf > > > It's 4 slides of content so should only take 5 minutes to go through. > > The main thing I'm curious about is if I should put time into further researching and writing the appendix that I mention on the last slide. > > The current version of the draft is here : > > http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-01 > > > Thanks very much, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jouni.nospam@gmail.com Thu Nov 15 13:35:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC821F89F3 for ; Thu, 15 Nov 2012 13:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmXORr26yoxr for ; Thu, 15 Nov 2012 13:35:52 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 268AD21F849A for ; Thu, 15 Nov 2012 13:35:51 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1390534eek.31 for ; Thu, 15 Nov 2012 13:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BF5klVRVo98IKyJ3ySbX2Xx8utgtLxkziMRJzV/b+IM=; b=gsE9MAvEosOwn6M5wdn335OD7c4Dsmszs+Wn9UaiPW2+sR/DaOrRaU3SuyGB4lD1mb bTUo6twKqq8dSRoT/WYzBBDGKm7n6zeFwnY2FrGNjUrJCmxJVqR5vMtc9JcNHYNxRbHE kWISY3Z1lvqYgOfyci8ZioIrxsVM4SbSTgm6YxY6MZu52I+iB9XmFxRdx1japbHfBLay Uwjn6QzTAl2M8HDDhMDHv+jqi/OgQD5DCTMEkDmsV6NH1BTHeVLU5LZ1ImVbSdK1tYcA nmiLYfZ3ff6GMo8ffMgm/k/8rxlX0k5WGALW3BnjjM7dB8Tk9bizOavRQ9Aqu4b+zAoo RMMA== Received: by 10.14.221.8 with SMTP id q8mr7485387eep.28.1353015351358; Thu, 15 Nov 2012 13:35:51 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:f41e:40e6:dd7:f962? ([2001:1bc8:101:f101:f41e:40e6:dd7:f962]) by mx.google.com with ESMTPS id i1sm38576758eeo.8.2012.11.15.13.35.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:35:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <50A5064A.1070208@redpill-linpro.com> Date: Thu, 15 Nov 2012 23:35:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <50A5064A.1070208@redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1283) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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, 15 Nov 2012 21:35:53 -0000 Hi, On Nov 15, 2012, at 5:12 PM, Tore Anderson wrote: > Hi, >=20 > REQ#8 (=ABthe cellular host MUST use the interface identifier sent in = PDP > Context Accept message to configure its link local address=BB) is = rather > tricky to implement for a cellular dongle that emulate an Ethernet > device (such as an USB CDC Ethernet class device). In that case, the > dongle provides an invented Ethernet MAC address from which the host > derives an link local address using EUI-64. And usually you also get other weird stuff along this like the stack thinking the link really is ethernet and thus requiring address = resolution to work.. which itself is bogus as the 3GPP link has no link-layer addresses. > Since this link local address does not have the correct interface > identifier, ND may (partially) break. In particular, I've experienced > that when sending an RS from such an EUI-64-derived link local address > to the network, the GGSN reponds with an RA that is unicasted to the > link local address the network expects the hosts to have. The host has > no knowledge of this address, and discards the RA. Yep. But I say here the UE is more wrong than the gateway since the 3GPP link definition says the gateway _tells_ the UE the IID to use with the link-local. > I don't have a good answer to how this problem should be solved. > However, if the document could make some recommendations (or at least > describe the problem), that would be good. Simple. Get USB class fixed. - Jouni >=20 > Best regards, > --=20 > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Thu Nov 15 16:51:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA91F0C70; Thu, 15 Nov 2012 16:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEmsmY8fEh05; Thu, 15 Nov 2012 16:51:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA8CB1F0C6A; Thu, 15 Nov 2012 16:51:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP58081; Fri, 16 Nov 2012 00:51:23 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:51:07 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:51:22 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 08:51:17 +0800 From: Sheng Jiang To: joel jaeggli , "draft-ietf-dhc-addr-registration@tools.ietf.org" , IPv6 Ops WG , "dhcwg@ietf.org" Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNwjRAZyoNeWfvHE6KhAKB8QhDcZfropKQ Date: Fri, 16 Nov 2012 00:51:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> In-Reply-To: <50A33EFA.7070008@bogus.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 00:51:29 -0000 PlRoZXJlJ3MgYSBjb3VwbGUgaXNzdWVzIHRoYXQgYXJlIHF1aXRlIHN0cmlraW5nLiBJIGtpbmQg b2YgY29uY3VyIHdpdGgNCj5GcmVkICBCYWtlciB0aGF0IHRoZSBtb3N0IGFwcHJvcGlhdGUgbWV0 aG9kIGZvciB0cmFja2luZyBsMi9sMyBiaW5kaW5nDQo+Zm9yIGFkZHJlc3MgaWRlbnRpZmljYXRp b24gaXMgcHJvYmFibHkgbW9yZSBha2luIHRvIHN5c2xvZy4NCj4NCj5UaGF0IGlzLCBzaW5jZSB5 b3UgZG9uJ3QgcmVhbGx5IHRydXN0IHRoZSBob3N0cywgaGF2aW5nIGEgc3dpdGNoL3JvdXRlciwN Cj5zaW1wbHkgc3lzbG9naW5nIGFsbCBuZXcgTkRQIGNhY2hlIGVudHJpZXMgcHJldHR5IG11Y2gg YWNoaXZlcyB0aGUgc2FtZQ0KPnRoaW5nIGV4ZWNlcHQgd2l0aCBhIGxvdCBsZXNzIHNpZ25hbGlu Zy4NCg0KSGksIEpvZWwsDQoNCkkgYW0gbm90IGFncmVlIHRoZSBwcmVjb25kaXRpb24geW91IGhh dmUgaGVyZTogInNpbmNlIHlvdSBkb24ndCByZWFsbHkgdHJ1c3QgdGhlIGhvc3RzIi4gVGhlIGFz c3VtZSB3ZSB0YWtlIGlzIHRoYXQgaG9zdHMsIGF0IGxlYXN0IGhvc3QgSVAgc3RhY2ssIHdvdWxk IGRvIHRoaXMgcmlnaHQuIE9yIGF0IGxlYXN0IHRoZXkgd2lsbCBkbyByaWdodCB0aGluZ3MgYnkg c3RhbmRhcmQgZGVmaW5pdGlvbnMuIEluIHJlYWxpdHksIG1hbGljaW91cyBob3N0cyBkbyBub3Qg Zm9sbG93IHRoZSBSRkNzLiBUaGVyZWZvcmUsIHRoZXkgYXJlIGNvbnNpZGVyZWQgYXMgc2VjdXJp dHkgaXNzdWVzLiBJdCBvbmx5IG1lYW5zIG1vcmUgc2VjdXJpdHkgbWVjaGFuaXNtL2luZnJhc3Ry dWN0dXJlIHNob3VsZCBiZSBkZXBsb3llZC4gSXQgc2hvdWxkIG5vdCBkZW55IHRoZSBtZWFuaW5n IG9mIGFkZHJlc3MgcmVnaXN0cmF0aW9uLiBJdCBzZXJ2ZXJzIG1vc3Qgb2Ygb3JkaW5hcnkgaG9z dHMsIHdoaWNoIG1heSBiZSA5OSUgb2YgYWxsIHVzZXJzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNo ZW5nDQoNCj5JZiBhIHN0cm9uZyBhc3NlcnRpb24gb2YgTDIgaWRlbnRpdHkgaW4gc3VwcG9ydCBv ZiBsMi9sMyBiaW5kaW5ncyBpcw0KPnJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1 aXZhbGFuZXQgc2VlbXMgYXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+d2hhdCB3ZSBkbyB0b2RheS4N Cj4NCj5BdmFpbGluZyBvbmVzZWxmIG9mIGEgZGhjcC9yYSBvcHRpb24gZW50YWlscyBhIGxvdCBv ZiBzaWduYWxpbmcgZm9yIHdoYXQNCj5pcyBsaWtlbHkgYSByZWxhdGl2ZWx5IGVwaGVtZXJhbCBw b3J0ICh3aW5kb3dzIG1hY2hpbmVzIGFuZCBtYWNzDQo+cmVnaXN0ZXJpbmcgcHJpdmFjeSBhZGRy ZXNzZXMgZm9yIGV4YW1wbGUpLiBzcGVjaWZpeWluZyBhIGJpbmRpbmcNCj5saWZldGltZSBzZWVt cyBvZiBsaW1pdGVkIHV0aWxpdHkgc2luY2UgdGhlIGhvc3Qgd2lsbCBwcm9iYWJseSBkaXNjYXJk DQo+dGhlIGFkZHJlc3MgbG9uZyBiZWZvcmUgdGhlIGxpZmV0aW1lIGV4cGlyZXMgaWYgaXQncyBz dWZmaWNlbnRseSBsb25nDQo+ZW5vdWdoIHRvIGFsbG93IGZvciBsb25nIGxpdmVkIGNvbm5lY3Rp b25zIHVzaW5nIHRoYXQgYWRkcmVzcy4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From jiangsheng@huawei.com Thu Nov 15 16:56:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196521F85EF; Thu, 15 Nov 2012 16:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjvkAUi1IzaE; Thu, 15 Nov 2012 16:56:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7521F85E7; Thu, 15 Nov 2012 16:56:29 -0800 (PST) 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 ALP58301; Fri, 16 Nov 2012 00:56:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:56:12 +0000 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:56:28 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 08:56:22 +0800 From: Sheng Jiang To: joel jaeggli , "draft-ietf-dhc-addr-registration@tools.ietf.org" , IPv6 Ops WG , "dhcwg@ietf.org" Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNwjRAZyoNeWfvHE6KhAKB8QhDcZfrpcEg Date: Fri, 16 Nov 2012 00:56:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E437@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> In-Reply-To: <50A33EFA.7070008@bogus.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 00:56:34 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBqb2Vs IGphZWdnbGkNCj5TZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE0LCAyMDEyIDI6NTAgUE0NCj5U bzogZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb25AdG9vbHMuaWV0Zi5vcmc7IElQdjYg T3BzIFdHOw0KPmRoY3dnQGlldGYub3JnDQo+U3ViamVjdDogW3Y2b3BzXSBzb21lIGZlZWRiYWNr IG9uDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdp c3RyYXRpb24tMDENCj4NCj5JIHRvb2sgYSBsb29rIGF0IHRoaXMgZHJhZnQgc2luY2UgaXQgd2Fz IGFsc28gcHJlc2VudGVkIGluIHY2b3BzLi4uDQo+DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb24tMDENCj4NCj5UaGVyZSdzIGEgY291 cGxlIGlzc3VlcyB0aGF0IGFyZSBxdWl0ZSBzdHJpa2luZy4gSSBraW5kIG9mIGNvbmN1ciB3aXRo DQo+RnJlZCAgQmFrZXIgdGhhdCB0aGUgbW9zdCBhcHByb3BpYXRlIG1ldGhvZCBmb3IgdHJhY2tp bmcgbDIvbDMgYmluZGluZw0KPmZvciBhZGRyZXNzIGlkZW50aWZpY2F0aW9uIGlzIHByb2JhYmx5 IG1vcmUgYWtpbiB0byBzeXNsb2cuDQo+DQo+VGhhdCBpcywgc2luY2UgeW91IGRvbid0IHJlYWxs eSB0cnVzdCB0aGUgaG9zdHMsIGhhdmluZyBhIHN3aXRjaC9yb3V0ZXIsDQo+c2ltcGx5IHN5c2xv Z2luZyBhbGwgbmV3IE5EUCBjYWNoZSBlbnRyaWVzIHByZXR0eSBtdWNoIGFjaGl2ZXMgdGhlIHNh bWUNCj50aGluZyBleGVjZXB0IHdpdGggYSBsb3QgbGVzcyBzaWduYWxpbmcuDQo+DQo+SWYgYSBz dHJvbmcgYXNzZXJ0aW9uIG9mIEwyIGlkZW50aXR5IGluIHN1cHBvcnQgb2YgbDIvbDMgYmluZGlu Z3MgaXMNCj5yZXF1aXJlZCA4MDIuMXggb3IgdGhlIHdpcmVsZXNzIGVxdWl2YWxhbmV0IHNlZW1z IGFwcHJvcGlhdGUsIGUuZy4gaXQncw0KPndoYXQgd2UgZG8gdG9kYXkuDQo+DQo+QXZhaWxpbmcg b25lc2VsZiBvZiBhIGRoY3AvcmEgb3B0aW9uIGVudGFpbHMgYSBsb3Qgb2Ygc2lnbmFsaW5nIGZv ciB3aGF0DQo+aXMgbGlrZWx5IGEgcmVsYXRpdmVseSBlcGhlbWVyYWwgcG9ydCAod2luZG93cyBt YWNoaW5lcyBhbmQgbWFjcw0KPnJlZ2lzdGVyaW5nIHByaXZhY3kgYWRkcmVzc2VzIGZvciBleGFt cGxlKS4gc3BlY2lmaXlpbmcgYSBiaW5kaW5nDQo+bGlmZXRpbWUgc2VlbXMgb2YgbGltaXRlZCB1 dGlsaXR5IHNpbmNlIHRoZSBob3N0IHdpbGwgcHJvYmFibHkgZGlzY2FyZA0KPnRoZSBhZGRyZXNz IGxvbmcgYmVmb3JlIHRoZSBsaWZldGltZSBleHBpcmVzIGlmIGl0J3Mgc3VmZmljZW50bHkgbG9u Zw0KPmVub3VnaCB0byBhbGxvdyBmb3IgbG9uZyBsaXZlZCBjb25uZWN0aW9ucyB1c2luZyB0aGF0 IGFkZHJlc3MuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From joelja@bogus.com Thu Nov 15 17:51:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1546B1F0C49; Thu, 15 Nov 2012 17:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcAiNrGATG4l; Thu, 15 Nov 2012 17:51:32 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80DE31F0C44; Thu, 15 Nov 2012 17:51:32 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAG1pRfY075727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Nov 2012 01:51:29 GMT (envelope-from joelja@bogus.com) Message-ID: <50A59C1F.2040407@bogus.com> Date: Thu, 15 Nov 2012 17:51:27 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sheng Jiang References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; 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, 16 Nov 2012 01:51:29 +0000 (UTC) Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 01:51:33 -0000 On 11/15/12 4:51 PM, Sheng Jiang wrote: >> There's a couple issues that are quite striking. I kind of concur with >> Fred Baker that the most appropiate method for tracking l2/l3 binding >> for address identification is probably more akin to syslog. >> >> That is, since you don't really trust the hosts, having a switch/router, >> simply sysloging all new NDP cache entries pretty much achives the same >> thing execept with a lot less signaling. > Hi, Joel, > > I am not agree the precondition you have here: "since you don't really trust the hosts". The assume we take is that hosts, at least host IP stack, would do this right. Or at least they will do right things by standard definitions. That's an interesting assumption given that all pre-existing host stacks will be unaware of the availability of the mechanism and therefore not use it. > In reality, malicious hosts do not follow the RFCs. untrustworthy hosts aren't necessarily malicious. > Therefore, they are considered as security issues. It only means more security mechanism/infrastructure should be deployed. It should not deny the meaning of address registration. It servers most of ordinary hosts, which may be 99% of all users. I can with relatively minor effort on the part of a vendor capture the same information, with a lot less signaling out of the NDP cache on my routers, and do so without consideration of hosts behavior. > Best regards, > > Sheng > >> If a strong assertion of L2 identity in support of l2/l3 bindings is >> required 802.1x or the wireless equivalanet seems appropiate, e.g. it's >> what we do today. >> >> Availing oneself of a dhcp/ra option entails a lot of signaling for what >> is likely a relatively ephemeral port (windows machines and macs >> registering privacy addresses for example). specifiying a binding >> lifetime seems of limited utility since the host will probably discard >> the address long before the lifetime expires if it's sufficently long >> enough to allow for long lived connections using that address. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Thu Nov 15 18:33:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED9A21F84C7; Thu, 15 Nov 2012 18:33:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65GQ79U95bE3; Thu, 15 Nov 2012 18:33:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EB11E8097; Thu, 15 Nov 2012 18:33:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP62451; Fri, 16 Nov 2012 02:33:54 +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.3; Fri, 16 Nov 2012 02:33:39 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 02:33:53 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 10:33:49 +0800 From: Sheng Jiang To: joel jaeggli Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw5zqb/SB0+d2NUqed+yzFK7R8pfrtqcg Date: Fri, 16 Nov 2012 02:33:49 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> In-Reply-To: <50A59C1F.2040407@bogus.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 02:33:57 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogam9lbCBqYWVnZ2xpIFttYWlsdG86 am9lbGphQGJvZ3VzLmNvbV0NCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDk6NTEg QU0NCj5UbzogU2hlbmcgSmlhbmcNCj5DYzogZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRp b25AdG9vbHMuaWV0Zi5vcmc7IElQdjYgT3BzIFdHOw0KPmRoY3dnQGlldGYub3JnDQo+U3ViamVj dDogUmU6IFt2Nm9wc10gc29tZSBmZWVkYmFjayBvbg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uLTAxDQo+DQo+T24gMTEvMTUvMTIg NDo1MSBQTSwgU2hlbmcgSmlhbmcgd3JvdGU6DQo+Pj4gVGhlcmUncyBhIGNvdXBsZSBpc3N1ZXMg dGhhdCBhcmUgcXVpdGUgc3RyaWtpbmcuIEkga2luZCBvZiBjb25jdXIgd2l0aA0KPj4+IEZyZWQg IEJha2VyIHRoYXQgdGhlIG1vc3QgYXBwcm9waWF0ZSBtZXRob2QgZm9yIHRyYWNraW5nIGwyL2wz IGJpbmRpbmcNCj4+PiBmb3IgYWRkcmVzcyBpZGVudGlmaWNhdGlvbiBpcyBwcm9iYWJseSBtb3Jl IGFraW4gdG8gc3lzbG9nLg0KPj4+DQo+Pj4gVGhhdCBpcywgc2luY2UgeW91IGRvbid0IHJlYWxs eSB0cnVzdCB0aGUgaG9zdHMsIGhhdmluZyBhIHN3aXRjaC9yb3V0ZXIsDQo+Pj4gc2ltcGx5IHN5 c2xvZ2luZyBhbGwgbmV3IE5EUCBjYWNoZSBlbnRyaWVzIHByZXR0eSBtdWNoIGFjaGl2ZXMgdGhl IHNhbWUNCj4+PiB0aGluZyBleGVjZXB0IHdpdGggYSBsb3QgbGVzcyBzaWduYWxpbmcuDQo+PiBI aSwgSm9lbCwNCj4+DQo+PiBJIGFtIG5vdCBhZ3JlZSB0aGUgcHJlY29uZGl0aW9uIHlvdSBoYXZl IGhlcmU6ICJzaW5jZSB5b3UgZG9uJ3QgcmVhbGx5IHRydXN0DQo+dGhlIGhvc3RzIi4gVGhlIGFz c3VtZSB3ZSB0YWtlIGlzIHRoYXQgaG9zdHMsIGF0IGxlYXN0IGhvc3QgSVAgc3RhY2ssIHdvdWxk IGRvDQo+dGhpcyByaWdodC4gT3IgYXQgbGVhc3QgdGhleSB3aWxsIGRvIHJpZ2h0IHRoaW5ncyBi eSBzdGFuZGFyZCBkZWZpbml0aW9ucy4NCj5UaGF0J3MgYW4gaW50ZXJlc3RpbmcgYXNzdW1wdGlv biBnaXZlbiB0aGF0IGFsbCBwcmUtZXhpc3RpbmcgaG9zdCBzdGFja3MNCj53aWxsIGJlIHVuYXdh cmUgb2YgdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUgbWVjaGFuaXNtIGFuZCB0aGVyZWZvcmUgbm90 DQo+dXNlIGl0Lg0KDQpUaGlzIGFyZ3VtZW50IHNlZW1zIHRvbyB3aWRlLiBJZiBzbywgb3VyIElF VEYgc2hvdWxkIG5ldmVyIGRlZmluZSBhbnkgbmV3IGV4dGVuc2lvbiBoZWFkZXJzL29wdGlvbnMv bWVjaGFuaXNtcyBiZWNhdXNlIGFsbCBwcmUtZXhpc3RpbmcgaG9zdCBzdGFja3MgZG8gbm90IHVu YXdhcmUgdGhlbS4NCg0KRm9yIG1lLCB5b3VyIGFyZ3VtZW50IGlzIGF2YWlsYWJsZSBpZiBpdCBj b21lcyBsaWtlIHRoaXMgd2F5OiB0aGVyZSBzaG91bGQgYmUgbW9yZSBjb25zaWRlcmF0aW9ucyBm b3IgaG93IHRvIHN1cHBvcnQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIFdlIGNhbiB3b3JrIG9u IHRoYXQuDQoNCj4+ICAgSW4gcmVhbGl0eSwgbWFsaWNpb3VzIGhvc3RzIGRvIG5vdCBmb2xsb3cg dGhlIFJGQ3MuDQo+dW50cnVzdHdvcnRoeSBob3N0cyBhcmVuJ3QgbmVjZXNzYXJpbHkgbWFsaWNp b3VzLg0KDQpPay4gTGV0J3MgZGlzY3VzcyB3aGljaCBwYXJ0IHlvdSBkb24ndCB0cnVzdCBmcm9t IGhvc3RzLiBUaGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJpbGl0aWVzIEkgY2FuIHRoaW5rIG91dDog YSkgaG9zdHMgcmVmdXNlIHRvIHJlZ2lzdGVyIHRoZWlyIGFkZHJlc3NlcywgYikgaG9zdHMgcmVn aXN0ZXIgd3JvbmcgYWRkcmVzcy9tYWMgb24gcHVycG9zZSBjKSBob3N0IHN0YWNrcyBkb2VzIG5v dCByZWdpc3RlciBhZGRyZXNzL21hYyByaWdodC4gRm9yIG1lLCBhIGhhcyBiZWVuIGRlc2NyaWJl ZCBpbiB0aGUgZHJhZnQ7IGIgc2hvdWxkIGJlIGNvbnNpZGVyIGFzIG1hbGljaW91cyBiZWhhdmlv cjsgYyBpcyBkb3duIHRvIGltcGxlbWVudGF0aW9uLCBpdCBpcyBub3QgYSBzdGFuZGFyZCBpc3N1 ZS4NCg0KSWYgeW91IGhhdmUgb3RoZXIgdW50cnVzdHdvcnRoeSBjb25zaWRlcmF0aW9ucywgcGxl YXNlIGdpdmUgZGV0YWlscy4gSSBhbSBoYXBweSB0byBkaXNjdXNzIHRoZW0uDQoNCj4+ICAgVGhl cmVmb3JlLCB0aGV5IGFyZSBjb25zaWRlcmVkIGFzIHNlY3VyaXR5IGlzc3Vlcy4gSXQgb25seSBt ZWFucyBtb3JlDQo+c2VjdXJpdHkgbWVjaGFuaXNtL2luZnJhc3RydWN0dXJlIHNob3VsZCBiZSBk ZXBsb3llZC4gSXQgc2hvdWxkIG5vdCBkZW55IHRoZQ0KPm1lYW5pbmcgb2YgYWRkcmVzcyByZWdp c3RyYXRpb24uIEl0IHNlcnZlcnMgbW9zdCBvZiBvcmRpbmFyeSBob3N0cywgd2hpY2ggbWF5DQo+ YmUgOTklIG9mIGFsbCB1c2Vycy4NCj5JIGNhbiB3aXRoIHJlbGF0aXZlbHkgbWlub3IgZWZmb3J0 IG9uIHRoZSBwYXJ0IG9mIGEgdmVuZG9yIGNhcHR1cmUgdGhlDQo+c2FtZSBpbmZvcm1hdGlvbiwg d2l0aCBhIGxvdCBsZXNzIHNpZ25hbGluZyBvdXQgb2YgdGhlIE5EUCBjYWNoZSBvbiBteQ0KPnJv dXRlcnMsIGFuZCBkbyBzbyB3aXRob3V0IGNvbnNpZGVyYXRpb24gb2YgaG9zdHMgYmVoYXZpb3Iu DQoNCkkgYWdyZWUgd2l0aCB5b3UgaWYgd2Ugb25seSBkaXNjdXNzIHRoZSBzY2VuYXJpbyB0aGF0 IGZpcnN0LWhvcCByb3V0ZXIgaXMgZnVsbHkgdW5kZXIgbWFuYWdlbWVudCBieSBJU1BzLiBCdXQg dGhlcmUgYXJlIG90aGVyIHNjZW5hcmlvcywgaW4gd2hpY2ggZmlyc3QtaG9wIHJvdXRlciBpcyBo b21lIGdhdGV3YXksIG1vYmlsZSBub2RlIGFuZCBvdGhlcnMuIEZvciB0aGVzZSBzY2VuYXJpb3Ms IElTUCBjYW5ub3QgZ2V0IHRoZSBhZGRyZXNzIGluZm9ybWF0aW9uIHVubGVzcyBob3N0IHJlZ2lz dGVyaW5nLg0KDQpBbm90aGVyIHBvaW50IGlzIHRoaXMgbmV3IHJlZ2lzdHJhdGlvbiBpcyBiaS1k aXJlY3Rpb24gaW50ZXJhY3Rpb24uIEl0IGdpdmVzIElTUHMgYSBjaGFuY2UgdG8gbWFuYWdlIHRo ZXNlIGhvc3QtZ2VuZXJhdGVkIGFkZHJlc3Nlcywgc3VjaCBhcyBkZW55aW5nIGNlcnRhaW4gYWRk cmVzcyAoc3VjaCBhcyBsb3cgc2VjLXZhbHVlIENHQSksIGV0Yy4gRm9yIG5vdywgSVNQcyBoYXMg dG8gYWNjZXB0IGFsbCBob3N0LWdlbmVyYXRlZCBhZGRyZXNzZXMuIElmIElTUCBkZW5pZXMgYWNj ZXNzIGJlY2F1c2Ugb2YgYW55IGFkZHJlc3MtcmVsZXZhbnQgcmVhc29ucywgdGhlcmUgaXMgbm8g bWVjaGFuaXNtIHRvIHRlbGwgaG9zdHMgd2h5IGFuZCBob3cgdG8gZml4IGl0Lg0KDQpCZXN0IHJl Z2FyZHMsDQoNClNoZW5nDQoNCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ PiBJZiBhIHN0cm9uZyBhc3NlcnRpb24gb2YgTDIgaWRlbnRpdHkgaW4gc3VwcG9ydCBvZiBsMi9s MyBiaW5kaW5ncyBpcw0KPj4+IHJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1aXZh bGFuZXQgc2VlbXMgYXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+Pj4gd2hhdCB3ZSBkbyB0b2RheS4N Cj4+Pg0KPj4+IEF2YWlsaW5nIG9uZXNlbGYgb2YgYSBkaGNwL3JhIG9wdGlvbiBlbnRhaWxzIGEg bG90IG9mIHNpZ25hbGluZyBmb3Igd2hhdA0KPj4+IGlzIGxpa2VseSBhIHJlbGF0aXZlbHkgZXBo ZW1lcmFsIHBvcnQgKHdpbmRvd3MgbWFjaGluZXMgYW5kIG1hY3MNCj4+PiByZWdpc3RlcmluZyBw cml2YWN5IGFkZHJlc3NlcyBmb3IgZXhhbXBsZSkuIHNwZWNpZml5aW5nIGEgYmluZGluZw0KPj4+ IGxpZmV0aW1lIHNlZW1zIG9mIGxpbWl0ZWQgdXRpbGl0eSBzaW5jZSB0aGUgaG9zdCB3aWxsIHBy b2JhYmx5IGRpc2NhcmQNCj4+PiB0aGUgYWRkcmVzcyBsb25nIGJlZm9yZSB0aGUgbGlmZXRpbWUg ZXhwaXJlcyBpZiBpdCdzIHN1ZmZpY2VudGx5IGxvbmcNCj4+PiBlbm91Z2ggdG8gYWxsb3cgZm9y IGxvbmcgbGl2ZWQgY29ubmVjdGlvbnMgdXNpbmcgdGhhdCBhZGRyZXNzLg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdjZvcHMgbWFpbGlu ZyBsaXN0DQo+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From joelja@bogus.com Thu Nov 15 20:05:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9D621E8040; Thu, 15 Nov 2012 20:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdNyslrDGgMs; Thu, 15 Nov 2012 20:05:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07EF921E802E; Thu, 15 Nov 2012 20:05:39 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAG45Z8f077831 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Nov 2012 04:05:36 GMT (envelope-from joelja@bogus.com) Message-ID: <50A5BB8E.6010308@bogus.com> Date: Thu, 15 Nov 2012 20:05:34 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sheng Jiang References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; 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, 16 Nov 2012 04:05:37 +0000 (UTC) Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 04:05:40 -0000 On 11/15/12 6:33 PM, Sheng Jiang wrote: >> -----Original Message----- >> From: joel jaeggli [mailto:joelja@bogus.com] >> Sent: Friday, November 16, 2012 9:51 AM >> To: Sheng Jiang >> Cc: draft-ietf-dhc-addr-registration@tools.ietf.org; IPv6 Ops WG; >> dhcwg@ietf.org >> Subject: Re: [v6ops] some feedback on >> http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 >> >> On 11/15/12 4:51 PM, Sheng Jiang wrote: >>>> There's a couple issues that are quite striking. I kind of concur with >>>> Fred Baker that the most appropiate method for tracking l2/l3 binding >>>> for address identification is probably more akin to syslog. >>>> >>>> That is, since you don't really trust the hosts, having a switch/router, >>>> simply sysloging all new NDP cache entries pretty much achives the same >>>> thing execept with a lot less signaling. >>> Hi, Joel, >>> >>> I am not agree the precondition you have here: "since you don't really trust >> the hosts". The assume we take is that hosts, at least host IP stack, would do >> this right. Or at least they will do right things by standard definitions. >> That's an interesting assumption given that all pre-existing host stacks >> will be unaware of the availability of the mechanism and therefore not >> use it. > This argument seems too wide. If so, our IETF should never define any new extension headers/options/mechanisms because all pre-existing host stacks do not unaware them. There should be a pretty high standard associated with changing the behavior of things which already exist. > For me, your argument is available if it comes like this way: there should be more considerations for how to support backwards compatibility. We can work on that. > >>> In reality, malicious hosts do not follow the RFCs. >> untrustworthy hosts aren't necessarily malicious. > Ok. Let's discuss which part you don't trust from hosts. There are several possibilities I can think out: a) hosts refuse to register their addresses, b) hosts register wrong address/mac on purpose What is wrong MAC in this case? MACs are generally but not always stable (vrrp6 is a pretty good case for not stable), in any event they are reconfigurable. A MAC is a layer 2 binding and if you have a strong layer-2 authentication (as some centrally managed networks do) then forgery is essentially irrelvant. beyond that the correctness of a MAC absent ACLs, is limited to it's presence in the bridge table and any l2/l3 bindings it may have. > c) host stacks does not register address/mac right. For me, a has been described in the draft; b should be consider as malicious behavior; c is down to implementation, it is not a standard issue. > > If you have other untrustworthy considerations, please give details. I am happy to discuss them. > >>> Therefore, they are considered as security issues. It only means more >> security mechanism/infrastructure should be deployed. It should not deny the >> meaning of address registration. It servers most of ordinary hosts, which may >> be 99% of all users. >> I can with relatively minor effort on the part of a vendor capture the >> same information, with a lot less signaling out of the NDP cache on my >> routers, and do so without consideration of hosts behavior. > I agree with you if we only discuss the scenario that first-hop router is fully under management by ISPs. But there are other scenarios, in which first-hop router is home gateway, mobile node and others. For these scenarios, ISP cannot get the address information unless host registering. Either the network is centrally managed or it isn't. The draft describes a management entity (enterprise) which is fully in control of the first hop router(s). Here you're describing a transitory trust model where my first hop router managed by me passes a registration option to my hosts to register addresses used on my network with my ISP. That's not, in your document. The network in my house, or my enterprise is managed by me, my ISP once they've assigned or delegated a prefix doesn't get to determine if I can use an address or not. It is no business of my ISP, if my fridge, or thermostat decides to use SLAAC to assign an address from the prefix which it plans to use becuase it's covered by RA. > Another point is this new registration is bi-direction interaction. It gives ISPs a chance to manage these host-generated addresses, such as denying certain address (such as low sec-value CGA), etc. For now, ISPs has to accept all host-generated addresses. If ISP denies access because of any address-relevant reasons, there is no mechanism to tell hosts why and how to fix it. Interesting use case. It's not in the document however, which you do have is. After receiving this address registration request, the address registration server MUST register the requested address in its address database, which may further be used by other network functions, such as DNS, network access control lists, etc. so presumably you tell the IA that it can't have an address by setting preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an extremely useful message to send back out a client trying to register an address. Fundamentally if you don't control the network you shouldn't be managing address selection on it since you don't know what people will attach. if you do then by all means do so. > Best regards, > > Sheng > >>> Best regards, >>> >>> Sheng >>> >>>> If a strong assertion of L2 identity in support of l2/l3 bindings is >>>> required 802.1x or the wireless equivalanet seems appropiate, e.g. it's >>>> what we do today. >>>> >>>> Availing oneself of a dhcp/ra option entails a lot of signaling for what >>>> is likely a relatively ephemeral port (windows machines and macs >>>> registering privacy addresses for example). specifiying a binding >>>> lifetime seems of limited utility since the host will probably discard >>>> the address long before the lifetime expires if it's sufficently long >>>> enough to allow for long lived connections using that address. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > From jiangsheng@huawei.com Thu Nov 15 22:11:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89721F8853; Thu, 15 Nov 2012 22:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oTNVAcyUYbi; Thu, 15 Nov 2012 22:11:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3B21F8669; Thu, 15 Nov 2012 22:11:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP73199; Fri, 16 Nov 2012 06:11:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 06:11:36 +0000 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 06:11:51 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 14:11:45 +0800 From: Sheng Jiang To: joel jaeggli Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw5zqb/SB0+d2NUqed+yzFK7R8pfrtqcg//+bQwCAAJFR0A== Date: Fri, 16 Nov 2012 06:11:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> In-Reply-To: <50A5BB8E.6010308@bogus.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 06:11:56 -0000 Pj4+PkluIHJlYWxpdHksIG1hbGljaW91cyBob3N0cyBkbyBub3QgZm9sbG93IHRoZSBSRkNzLg0K Pj4+IHVudHJ1c3R3b3J0aHkgaG9zdHMgYXJlbid0IG5lY2Vzc2FyaWx5IG1hbGljaW91cy4NCj4+ IE9rLiBMZXQncyBkaXNjdXNzIHdoaWNoIHBhcnQgeW91IGRvbid0IHRydXN0IGZyb20gaG9zdHMu IFRoZXJlIGFyZSBzZXZlcmFsDQo+PnBvc3NpYmlsaXRpZXMgSSBjYW4gdGhpbmsgb3V0OiBhKSBo b3N0cyByZWZ1c2UgdG8gcmVnaXN0ZXIgdGhlaXIgYWRkcmVzc2VzLCBiKSBob3N0cw0KPj5yZWdp c3RlciB3cm9uZyBhZGRyZXNzL21hYyBvbiBwdXJwb3NlDQoNCj5XaGF0IGlzIHdyb25nIE1BQyBp biB0aGlzIGNhc2U/IA0KDQpJIHJlZmVycmVkIHRvIHRoZXNlIG1hbGljaW91cyBob3N0cywgd2hv IHVzZXMgZmFrZWQgTUFDIHRvIGdldCBuZXR3b3JrIGFjY2VzcyBvciBwbGF5cyB0byBiZSBvdGhl ciBob3N0cy4NCg0KPk1BQ3MgYXJlIGdlbmVyYWxseSBidXQgbm90IGFsd2F5cyBzdGFibGUNCj4o dnJycDYgaXMgYSBwcmV0dHkgZ29vZCBjYXNlIGZvciBub3Qgc3RhYmxlKSwgaW4gYW55IGV2ZW50 IHRoZXkgYXJlDQo+cmVjb25maWd1cmFibGUuIEEgTUFDIGlzIGEgbGF5ZXIgMiBiaW5kaW5nIGFu ZCBpZiB5b3UgaGF2ZSBhIHN0cm9uZw0KPmxheWVyLTIgYXV0aGVudGljYXRpb24gKGFzIHNvbWUg Y2VudHJhbGx5IG1hbmFnZWQgbmV0d29ya3MgZG8pIHRoZW4NCj5mb3JnZXJ5IGlzIGVzc2VudGlh bGx5IGlycmVsdmFudC4gYmV5b25kIHRoYXQgdGhlIGNvcnJlY3RuZXNzIG9mIGEgTUFDDQo+YWJz ZW50IEFDTHMsIGlzIGxpbWl0ZWQgdG8gaXQncyBwcmVzZW5jZSBpbiB0aGUgYnJpZGdlIHRhYmxl IGFuZCBhbnkNCj5sMi9sMyBiaW5kaW5ncyBpdCBtYXkgaGF2ZS4NCg0KVGhlbiwgd2h5IGhvc3Rz IGFyZSB1bnRydXN0d29ydGh5IHRvIHJlZ2lzdGVyIGFkZHJlc3M/DQoNCj4+PiBJIGNhbiB3aXRo IHJlbGF0aXZlbHkgbWlub3IgZWZmb3J0IG9uIHRoZSBwYXJ0IG9mIGEgdmVuZG9yIGNhcHR1cmUg dGhlDQo+Pj4gc2FtZSBpbmZvcm1hdGlvbiwgd2l0aCBhIGxvdCBsZXNzIHNpZ25hbGluZyBvdXQg b2YgdGhlIE5EUCBjYWNoZSBvbiBteQ0KPj4+IHJvdXRlcnMsIGFuZCBkbyBzbyB3aXRob3V0IGNv bnNpZGVyYXRpb24gb2YgaG9zdHMgYmVoYXZpb3IuDQo+PiBJIGFncmVlIHdpdGggeW91IGlmIHdl IG9ubHkgZGlzY3VzcyB0aGUgc2NlbmFyaW8gdGhhdCBmaXJzdC1ob3Agcm91dGVyIGlzIGZ1bGx5 DQo+PnVuZGVyIG1hbmFnZW1lbnQgYnkgSVNQcy4gQnV0IHRoZXJlIGFyZSBvdGhlciBzY2VuYXJp b3MsIGluIHdoaWNoIGZpcnN0LWhvcA0KPj5yb3V0ZXIgaXMgaG9tZSBnYXRld2F5LCBtb2JpbGUg bm9kZSBhbmQgb3RoZXJzLiBGb3IgdGhlc2Ugc2NlbmFyaW9zLCBJU1ANCj4+Y2Fubm90IGdldCB0 aGUgYWRkcmVzcyBpbmZvcm1hdGlvbiB1bmxlc3MgaG9zdCByZWdpc3RlcmluZy4NCg0KPkVpdGhl ciB0aGUgbmV0d29yayBpcyBjZW50cmFsbHkgbWFuYWdlZCBvciBpdCBpc24ndC4gVGhlIGRyYWZ0 IGRlc2NyaWJlcw0KPmEgbWFuYWdlbWVudCBlbnRpdHkgKGVudGVycHJpc2UpIHdoaWNoIGlzIGZ1 bGx5IGluIGNvbnRyb2wgb2YgdGhlIGZpcnN0DQo+aG9wIHJvdXRlcihzKS4gSGVyZSB5b3UncmUg ZGVzY3JpYmluZyBhIHRyYW5zaXRvcnkgdHJ1c3QgbW9kZWwgd2hlcmUgbXkNCj5maXJzdCBob3Ag cm91dGVyIG1hbmFnZWQgYnkgbWUgcGFzc2VzIGEgcmVnaXN0cmF0aW9uIG9wdGlvbiB0byBteSBo b3N0cw0KPnRvIHJlZ2lzdGVyIGFkZHJlc3NlcyB1c2VkIG9uIG15IG5ldHdvcmsgd2l0aCBteSBJ U1AuIFRoYXQncyBub3QsIGluDQo+eW91ciBkb2N1bWVudC4NCg0KWWVzLCBpdCB3YXMgbm90IGlu IHRoZSBkb2N1bWVudC4gU2luY2UgdGhpcyBkb2N1bWVudCBpcyBhIERIQyBkcmFmdCwgd2UgZm9j dXNlZCBvbiB0aGUgREhDUCBQcm90b2NvbCBpbnRlcmFjdGlvbiBhbmQgb3B0aW9uIGRlZmluaXRp b24uIFdlIGRpZCBub3QgZG8gdmVyeSB3ZWxsIHRvIGRlc2NyaWJlIHN1aXRhYmxlIHNjZW5hcmlv cyB1bnRpbCByZWNlbnRseS4gV2Ugd2lsbCB3b3JrIG9uIHRoYXQuIFRoYW5rcyB0byBoZWxwIHVz IGltcHJvdmUgdGhlIGRvY3VtZW50Lg0KDQo+VGhlIG5ldHdvcmsgaW4gbXkgaG91c2UsIG9yIG15 IGVudGVycHJpc2UgaXMgbWFuYWdlZCBieSBtZSwgbXkgSVNQIG9uY2UNCj50aGV5J3ZlIGFzc2ln bmVkIG9yIGRlbGVnYXRlZCBhIHByZWZpeCBkb2Vzbid0IGdldCB0byBkZXRlcm1pbmUgaWYgSSBj YW4NCj51c2UgYW4gYWRkcmVzcyBvciBub3QuIEl0IGlzIG5vIGJ1c2luZXNzIG9mIG15IElTUCwg aWYgbXkgZnJpZGdlLCBvcg0KPnRoZXJtb3N0YXQgZGVjaWRlcyB0byB1c2UgU0xBQUMgdG8gYXNz aWduIGFuIGFkZHJlc3MgZnJvbSB0aGUgcHJlZml4DQo+d2hpY2ggaXQgcGxhbnMgdG8gdXNlIGJl Y3Vhc2UgaXQncyBjb3ZlcmVkIGJ5IFJBLg0KPg0KPj4gQW5vdGhlciBwb2ludCBpcyB0aGlzIG5l dyByZWdpc3RyYXRpb24gaXMgYmktZGlyZWN0aW9uIGludGVyYWN0aW9uLiBJdCBnaXZlcyBJU1Bz DQo+PmEgY2hhbmNlIHRvIG1hbmFnZSB0aGVzZSBob3N0LWdlbmVyYXRlZCBhZGRyZXNzZXMsIHN1 Y2ggYXMgZGVueWluZyBjZXJ0YWluDQo+PmFkZHJlc3MgKHN1Y2ggYXMgbG93IHNlYy12YWx1ZSBD R0EpLCBldGMuIEZvciBub3csIElTUHMgaGFzIHRvIGFjY2VwdCBhbGwNCj4+aG9zdC1nZW5lcmF0 ZWQgYWRkcmVzc2VzLiBJZiBJU1AgZGVuaWVzIGFjY2VzcyBiZWNhdXNlIG9mIGFueQ0KPj5hZGRy ZXNzLXJlbGV2YW50IHJlYXNvbnMsIHRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byB0ZWxsIGhvc3Rz IHdoeSBhbmQgaG93IHRvDQo+PmZpeCBpdC4NCg0KPkludGVyZXN0aW5nIHVzZSBjYXNlLiBJdCdz IG5vdCBpbiB0aGUgZG9jdW1lbnQgaG93ZXZlciwgd2hpY2ggeW91IGRvDQo+aGF2ZSBpcy4NCj4N Cj4gICAgQWZ0ZXIgcmVjZWl2aW5nIHRoaXMgYWRkcmVzcyByZWdpc3RyYXRpb24gcmVxdWVzdCwg dGhlIGFkZHJlc3MNCj4gICAgcmVnaXN0cmF0aW9uIHNlcnZlciBNVVNUIHJlZ2lzdGVyIHRoZSBy ZXF1ZXN0ZWQgYWRkcmVzcyBpbiBpdHMNCj4gICAgYWRkcmVzcyBkYXRhYmFzZSwgd2hpY2ggbWF5 IGZ1cnRoZXIgYmUgdXNlZCBieSBvdGhlciBuZXR3b3JrDQo+ICAgIGZ1bmN0aW9ucywgc3VjaCBh cyBETlMsIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wgbGlzdHMsIGV0Yy4NCj4NCj5zbyBwcmVzdW1h Ymx5IHlvdSB0ZWxsIHRoZSBJQSB0aGF0IGl0IGNhbid0IGhhdmUgYW4gYWRkcmVzcyBieSBzZXR0 aW5nDQo+cHJlZmVycmVkLWxpZmV0aW1lIGFuZCB2YWxpZC1saWZldGltZSBmaWVsZHMgdG8gMCwg dGhhdCBkb2Vucyd0IHNlZW0gbGlrZSBhbg0KPmV4dHJlbWVseSB1c2VmdWwgbWVzc2FnZSB0byBz ZW5kIGJhY2sgb3V0IGEgY2xpZW50IHRyeWluZyB0byByZWdpc3RlciBhbg0KPmFkZHJlc3MuDQoN CkFncmVlLCBtb3JlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBwcm92aWRlZCBpbiB0aGUgY2FzZSBv ZiByZWplY3QgYWRkcmVzcy4gQWN0dWFsbHksIHRoZSBzcGVjaWZpYyBjYXNlIG9mIGRlbnlpbmcg Q0dBIHdpdGggbG93IHNlYy12YWx1ZSB3YXMgc29sdmVkIGJ5IGFub3RoZXIgZGVkaWNhdGVkIGRy YWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1jZ2EtY29uZmln LWRoY3B2NikgLCBpbiB3aGljaCBhIG5ldyBESENQdjYgb3B0aW9uIGhhcyBiZWVuIGRlZmluZWQg dG8gZmVlZGJhY2sgYSByZWNvbW1lbmRlZCBTZWMgdmFsdWUuDQoNCldlIHdpbGwgaW1wcm92ZSB0 aGlzIHBhcnQgaW4gbmV4dCB1cGRhdGUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPkZ1 bmRhbWVudGFsbHkgaWYgeW91IGRvbid0IGNvbnRyb2wgdGhlIG5ldHdvcmsgeW91IHNob3VsZG4n dCBiZSBtYW5hZ2luZw0KPmFkZHJlc3Mgc2VsZWN0aW9uIG9uIGl0IHNpbmNlIHlvdSBkb24ndCBr bm93IHdoYXQgcGVvcGxlIHdpbGwgYXR0YWNoLiBpZg0KPnlvdSBkbyB0aGVuIGJ5IGFsbCBtZWFu cyBkbyBzby4NCj4NCj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+Pj4g QmVzdCByZWdhcmRzLA0KPj4+Pg0KPj4+PiBTaGVuZw0KPj4+Pg0KPj4+Pj4gSWYgYSBzdHJvbmcg YXNzZXJ0aW9uIG9mIEwyIGlkZW50aXR5IGluIHN1cHBvcnQgb2YgbDIvbDMgYmluZGluZ3MgaXMN Cj4+Pj4+IHJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1aXZhbGFuZXQgc2VlbXMg YXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+Pj4+PiB3aGF0IHdlIGRvIHRvZGF5Lg0KPj4+Pj4NCj4+ Pj4+IEF2YWlsaW5nIG9uZXNlbGYgb2YgYSBkaGNwL3JhIG9wdGlvbiBlbnRhaWxzIGEgbG90IG9m IHNpZ25hbGluZyBmb3Igd2hhdA0KPj4+Pj4gaXMgbGlrZWx5IGEgcmVsYXRpdmVseSBlcGhlbWVy YWwgcG9ydCAod2luZG93cyBtYWNoaW5lcyBhbmQgbWFjcw0KPj4+Pj4gcmVnaXN0ZXJpbmcgcHJp dmFjeSBhZGRyZXNzZXMgZm9yIGV4YW1wbGUpLiBzcGVjaWZpeWluZyBhIGJpbmRpbmcNCj4+Pj4+ IGxpZmV0aW1lIHNlZW1zIG9mIGxpbWl0ZWQgdXRpbGl0eSBzaW5jZSB0aGUgaG9zdCB3aWxsIHBy b2JhYmx5IGRpc2NhcmQNCj4+Pj4+IHRoZSBhZGRyZXNzIGxvbmcgYmVmb3JlIHRoZSBsaWZldGlt ZSBleHBpcmVzIGlmIGl0J3Mgc3VmZmljZW50bHkgbG9uZw0KPj4+Pj4gZW5vdWdoIHRvIGFsbG93 IGZvciBsb25nIGxpdmVkIGNvbm5lY3Rpb25zIHVzaW5nIHRoYXQgYWRkcmVzcy4NCj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHY2b3BzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pg0KDQo= From markzzzsmith@yahoo.com.au Thu Nov 15 22:31:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7721F878C for ; Thu, 15 Nov 2012 22:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz2lPjcD1ZKl for ; Thu, 15 Nov 2012 22:31:30 -0800 (PST) Received: from nm36-vm5.bullet.mail.bf1.yahoo.com (nm36-vm5.bullet.mail.bf1.yahoo.com [72.30.238.141]) by ietfa.amsl.com (Postfix) with ESMTP id 819B321F877C for ; Thu, 15 Nov 2012 22:31:30 -0800 (PST) Received: from [98.139.215.142] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 Received: from [98.139.212.233] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 602136.8853.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 99848 invoked by uid 60001); 16 Nov 2012 06:31:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1353047489; bh=HkLkB9MNAaDTsYZnHcEP4T2DHT0uPInRhIGlJ7DUrkM=; 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:Content-Transfer-Encoding; b=OvzMyDlt5W7GopBy+EN6BbOQpUgEQumUtiiedd8qj4OdQNFGQuOe10gDRKQdW/Kj1JevN5vLPwz8Gr5xpXKBeGHCQXm4OwJUeWooe37RnjnMJ/554/lPYmPc+mOMye2QsNFLqd1nmG0MfjVykesmZvMf4FN32xal/hFlUKlT8f0= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dpjyu0tWoAzlcnyWG9jRqqYAL4eYj7lwOOWRAq+fBNS7Mc8l+dpZRo2FsoRqemNO7eg3fhFp9vnu/k6kUFgsQtF0UuMxaXciNAgHjhGKclLpqTiKyxppbW2yRdJP0Cw0hbHewl/BmMJexdLr+BA9d6IYCLp9xtuxrCeGtFC/NgA=; X-YMail-OSG: JBiZBxMVM1mc5PInCGYsde.IJvMiixNrIuFPwEltS4CnVGP Gr5Ysp8Y0D3aQ1piUuvEK.EBkN3VdG11FNF2XXF5iGbYrQA7wogIQ8bm_98e 3OgRGiefRGj94alZ1RxrGKpFNAEYRuZjqCiueHtsnGnMhl4NPzZjkaBcN.FP 5nryDV5ODu6_tbcVxJqSZjo4p9AtvqVpZLoUo6zcYXiwDYahdDy9W_dkQKIA kEoFTEm3aVsiK81mbMPHOux5PATDmwyjAwWEmApO3D464sDe3MOFtcxN_hR4 BPQufth7G3c_rbD3TVKUtQl1GoxcSPZgSYIf2syxZFAtB2EWOPkXbSFDNjIy D5.bHROi0kzOQZ3uzVl_aVSw8AbETLY3evPXEz9.IBl75Dj2BWEKk3Z9KAuF 52hMO_z0pPYSl1YWXvNxy6wG1dd84spzv8mjLpDRsE1UvLaAdJJyHMqJK_or JiSdeKb0qDHa7LB1aBCNIT_MqSCaTawtILdycEPyA.dlnDlsGvxWWUePXnUf HuY.jRA054yXThfdjOipQOlbsGUBQB45xbISxYzwiOvwakhyCdDVg55s_Rpr EH4UNeEnOuPitctkASXK3vrYTWWlYGjfqc7tnvSVg_ShoEQ-- Received: from [121.200.231.211] by web32501.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2012 22:31:28 PST X-Rocket-MIMEInfo: 001.001, SSBhZ3JlZSB3aXRoIEpvZWwsIEkgdGhpbmsgb2JzZXJ2YXRpb24gYnkgbW9zdCBsaWtlbHkgYSByb3V0ZXIgaXMgYSBiZXR0ZXIgbWV0aG9kLCBhcyBpdCB3aWxsIGNhcHR1cmUgYWRkcmVzcyBpbmZvcm1hdGlvbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgd2FzIGNvbmZpZ3VyZWQgdmlhIHN0YXRpYywgU0xBQUMgb3IgREhDUHY2IChvciBhbnkgZnV0dXJlIG1ldGhvZHMpLgoKSSBoYXZlbid0IGhhZCBhIGNoYW5jZSB0byBydW4gRmVybmFuZG8ncyB1dGlsaXR5LCBob3dldmVyIEkgdW5kZXJzdGFuZCBpdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> Message-ID: <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Thu, 15 Nov 2012 22:31:28 -0800 (PST) From: Mark Smith To: Sheng Jiang , joel jaeggli In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 06:31:31 -0000 I agree with Joel, I think observation by most likely a router is a better = method, as it will capture address information regardless of whether it was= configured via static, SLAAC or DHCPv6 (or any future methods).=0A=0AI hav= en't had a chance to run Fernando's utility, however I understand it implem= ents address recording using observation.=0A=0Ahttp://www.si6networks.com/t= ools/ipv6mon/=0A=0A=0A=0A----- Original Message -----=0A> From: Sheng Jiang= =0A> To: joel jaeggli =0A> Cc: "d= hcwg@ietf.org" ; IPv6 Ops WG ; "draft-ietf-= dhc-addr-registration@tools.ietf.org" =0A> Sent: Friday, 16 November 2012 5:11 PM=0A> Subject: Re: [v= 6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-regis= tration-01=0A> =0A>>>>> In reality, malicious hosts do not follow the RFCs.= =0A>>>> untrustworthy hosts aren't necessarily malicious.=0A>>> Ok. Let's= discuss which part you don't trust from hosts. There =0A> are several=0A>>= > possibilities I can think out: a) hosts refuse to register their =0A> add= resses, b) hosts=0A>>> register wrong address/mac on purpose=0A> =0A>> What= is wrong MAC in this case? =0A> =0A> I referred to these malicious hosts, = who uses faked MAC to get network access or =0A> plays to be other hosts.= =0A> =0A>> MACs are generally but not always stable=0A>> (vrrp6 is a pretty= good case for not stable), in any event they are=0A>> reconfigurable. A MA= C is a layer 2 binding and if you have a strong=0A>> layer-2 authentication= (as some centrally managed networks do) then=0A>> forgery is essentially i= rrelvant. beyond that the correctness of a MAC=0A>> absent ACLs, is limited= to it's presence in the bridge table and any=0A>> l2/l3 bindings it may ha= ve.=0A> =0A> Then, why hosts are untrustworthy to register address?=0A> =0A= >>>> I can with relatively minor effort on the part of a vendor capture = =0A> the=0A>>>> same information, with a lot less signaling out of the NDP= cache on =0A> my=0A>>>> routers, and do so without consideration of hosts= behavior.=0A>>> I agree with you if we only discuss the scenario that fir= st-hop router =0A> is fully=0A>>> under management by ISPs. But there are o= ther scenarios, in which =0A> first-hop=0A>>> router is home gateway, mobil= e node and others. For these scenarios, ISP=0A>>> cannot get the address in= formation unless host registering.=0A> =0A>> Either the network is centrall= y managed or it isn't. The draft describes=0A>> a management entity (enterp= rise) which is fully in control of the first=0A>> hop router(s). Here you'r= e describing a transitory trust model where my=0A>> first hop router manage= d by me passes a registration option to my hosts=0A>> to register addresses= used on my network with my ISP. That's not, in=0A>> your document.=0A> =0A= > Yes, it was not in the document. Since this document is a DHC draft, we f= ocused =0A> on the DHCP Protocol interaction and option definition. We did = not do very well =0A> to describe suitable scenarios until recently. We wil= l work on that. Thanks to =0A> help us improve the document.=0A> =0A>> The = network in my house, or my enterprise is managed by me, my ISP once=0A>> th= ey've assigned or delegated a prefix doesn't get to determine if I =0A> can= =0A>> use an address or not. It is no business of my ISP, if my fridge, or= =0A>> thermostat decides to use SLAAC to assign an address from the prefix= =0A>> which it plans to use becuase it's covered by RA.=0A>> =0A>>> Anothe= r point is this new registration is bi-direction interaction. It =0A> gives= ISPs=0A>>> a chance to manage these host-generated addresses, such as deny= ing =0A> certain=0A>>> address (such as low sec-value CGA), etc. For now, I= SPs has to accept =0A> all=0A>>> host-generated addresses. If ISP denies ac= cess because of any=0A>>> address-relevant reasons, there is no mechanism t= o tell hosts why and =0A> how to=0A>>> fix it.=0A> =0A>> Interesting use ca= se. It's not in the document however, which you do=0A>> have is.=0A>> =0A>>= =A0 =A0 After receiving this address registration request, the address=0A>= > =A0 =A0 registration server MUST register the requested address in its=0A= >> =A0 =A0 address database, which may further be used by other network=0A>= > =A0 =A0 functions, such as DNS, network access control lists, etc.=0A>> = =0A>> so presumably you tell the IA that it can't have an address by settin= g=0A>> preferred-lifetime and valid-lifetime fields to 0, that doens't seem= =0A> like an=0A>> extremely useful message to send back out a client tryin= g to register an=0A>> address.=0A> =0A> Agree, more information should be p= rovided in the case of reject address. =0A> Actually, the specific case of = denying CGA with low sec-value was solved by =0A> another dedicated draft = =0A> (http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6) , in whi= ch a new =0A> DHCPv6 option has been defined to feedback a recommended Sec = value.=0A> =0A> We will improve this part in next update.=0A> =0A> Best reg= ards,=0A> =0A> Sheng=0A> =0A>> Fundamentally if you don't control the netwo= rk you shouldn't be =0A> managing=0A>> address selection on it since you do= n't know what people will attach. if=0A>> you do then by all means do so.= =0A>> =0A>> =0A>>> Best regards,=0A>>> =0A>>> Sheng=0A>>> =0A>>>>> Best = regards,=0A>>>>> =0A>>>>> Sheng=0A>>>>> =0A>>>>>> If a strong assertion o= f L2 identity in support of l2/l3 =0A> bindings is=0A>>>>>> required 802.1= x or the wireless equivalanet seems =0A> appropiate, e.g. it's=0A>>>>>> wh= at we do today.=0A>>>>>> =0A>>>>>> Availing oneself of a dhcp/ra option en= tails a lot of =0A> signaling for what=0A>>>>>> is likely a relatively eph= emeral port (windows machines and =0A> macs=0A>>>>>> registering privacy a= ddresses for example). specifiying a =0A> binding=0A>>>>>> lifetime seems = of limited utility since the host will =0A> probably discard=0A>>>>>> the = address long before the lifetime expires if it's =0A> sufficently long=0A>>= >>>> enough to allow for long lived connections using that =0A> address.= =0A>>>>>> _______________________________________________=0A>>>>>> v6ops = mailing list=0A>>>>>> v6ops@ietf.org=0A>>>>>> https://www.ietf.org/mailma= n/listinfo/v6ops=0A>>> =0A> =0A> __________________________________________= _____=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/v6ops=0A> From mohamed.boucadair@orange.com Fri Nov 16 03:59:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1842321F852B for ; Fri, 16 Nov 2012 03:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVixpLaS8WUO for ; Fri, 16 Nov 2012 03:59:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AB21F8528 for ; Fri, 16 Nov 2012 03:59:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8CED522CF98; Fri, 16 Nov 2012 12:59:47 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67DC4238056; Fri, 16 Nov 2012 12:59:47 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 16 Nov 2012 12:59:46 +0100 From: To: Tore Anderson Date: Fri, 16 Nov 2012 12:59:45 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3DQ5sXRF0n9A4RSP6CETaKYS2opQAo1Ijw Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E26A@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <50A5064A.1070208@redpill-linpro.com> In-Reply-To: <50A5064A.1070208@redpill-linpro.com> 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: 2012.11.16.63326 Cc: BERNIER Olivier OLNC/OLN , IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Fri, 16 Nov 2012 11:59:50 -0000 Dear Tore, This is indeed a problem which is encountered with several implementations = (both USB dongles and smartphones). My colleague Olivier (cced) reported to= me four implementations are behaving as you described in your message. This is an implementation issue. We can add a note about these implementati= on but the recommendation is still: be compliant with REQ#8. Cheers, Med >-----Message d'origine----- >De : Tore Anderson [mailto:tore.anderson@redpill-linpro.com]=20 >Envoy=E9 : jeudi 15 novembre 2012 16:12 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt > >Hi, > >REQ#8 (=ABthe cellular host MUST use the interface identifier sent in PDP >Context Accept message to configure its link local address=BB) is rather >tricky to implement for a cellular dongle that emulate an Ethernet >device (such as an USB CDC Ethernet class device). In that case, the >dongle provides an invented Ethernet MAC address from which the host >derives an link local address using EUI-64. > >Since this link local address does not have the correct interface >identifier, ND may (partially) break. In particular, I've experienced >that when sending an RS from such an EUI-64-derived link local address >to the network, the GGSN reponds with an RA that is unicasted to the >link local address the network expects the hosts to have. The host has >no knowledge of this address, and discards the RA. > >I don't have a good answer to how this problem should be solved. >However, if the document could make some recommendations (or at least >describe the problem), that would be good. > >Best regards, >--=20 >Tore Anderson >Redpill Linpro AS - http://www.redpill-linpro.com >= From mohamed.boucadair@orange.com Fri Nov 16 04:07:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B488E21F8792 for ; Fri, 16 Nov 2012 04:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uicBbk+d-E8P for ; Fri, 16 Nov 2012 04:07:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5195221F84BA for ; Fri, 16 Nov 2012 04:07:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7FCBF3B4AC6; Fri, 16 Nov 2012 13:07:03 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6096E27C064; Fri, 16 Nov 2012 13:07:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 16 Nov 2012 13:07:03 +0100 From: To: Jouni Date: Fri, 16 Nov 2012 13:07:01 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 Thread-Index: Ac3DR3BawJZCqID3QzC8fxH1HFYwxwAqnRVg Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> In-Reply-To: <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> 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: 2012.11.16.63326 Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 12:07:08 -0000 Hi Jouni, What I understood from the v6ops meeting is that wg participants see these = two documents have distinct objectives. As such the question of overlapping= does not apply as these documents serve two distinct objectives. Furthermo= re, because draft-binet-*'s objective is to define an IPv6 profile for cell= ular, we prefer the document be self-contained and use consistent language = for all requirements. Cheers, Med=20 >-----Message d'origine----- >De : Jouni [mailto:jouni.nospam@gmail.com]=20 >Envoy=E9 : jeudi 15 novembre 2012 16:40 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 > > >Med, > >I am slightly confused about the overlap of=20 >draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >recollection was that overlaps were supposed to be removed and=20 >then concentrate on the remaining part in draft-binet-v6ops-*,=20 >no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >#22, #23, #25, #26, #27. My recommendation would be removing=20 >those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >because the base IPv6 compliancy would come from there and I=20 >see no reason to repeat those here. > >Then a question about the relevance of #24. Given the current=20 >bandwidth in 3G/LTE is there really a need to compress=20 >headers? And if people really see it as a life critical=20 >feature to have, I would appreciate listing the ROHC profiles=20 >that are essential (e.g., align with IR.92 & IR.58 that will=20 >be implemented on the network side). > >- Jouni > > >On Nov 15, 2012, at 4:59 PM, =20 > wrote: > >> Dear all, >>=20 >> We submitted a new version of the draft to take into account=20 >the comments received from M. Abrahamsson and P. Vickers. >>=20 >> The main changes are: >>=20 >> * Add some clarification text for REQ#3 >> * Mention stateless dhcpv6 is useful to retrieve other=20 >information than DNS >> * Re-word REQ#15 >> * Cite "Happy Eyeballs" in REQ#16 >> * Update the text of REQ#17 >> * Add two sub-requirements to REQ#19: IPv6-only connectivity + SLAAC >> * Precise the ordering in REQ#21 >>=20 >> A more detailed diff is available at: >>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >t-requirements-01 >>=20 >>=20 >> Chairs, would it be possible to issue a Call For Adoption=20 >for this document? Thanks. >>=20 >> Cheers, >> Med >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >> Envoy=E9 : jeudi 15 novembre 2012 15:53 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action:=20 >draft-binet-v6ops-cellular-host-requirements-01.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >>=20 >>=20 >> Title : Internet Protocol Version 6 (IPv6)=20 >Requirements for Cellular Hosts >> Author(s) : David Binet >> Mohamed Boucadair >> Ales Vizdal >> Cameron Byrne >> Gang Chen >> Filename :=20 >draft-binet-v6ops-cellular-host-requirements-01.txt >> Pages : 16 >> Date : 2012-11-15 >>=20 >> Abstract: >> This document lists a set of IPv6-related requirements to be >> supported by cellular hosts. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >>=20 >https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >t-requirements >>=20 >> There's also a htmlized version available at: >>=20 >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >irements-01 >>=20 >> A diff from the previous version is available at: >>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >t-requirements-01 >>=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 jouni.nospam@gmail.com Fri Nov 16 05:09:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DF21F851F for ; Fri, 16 Nov 2012 05:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hboaj6KWYR6h for ; Fri, 16 Nov 2012 05:09:35 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43B921F850E for ; Fri, 16 Nov 2012 05:09:34 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1799491eek.31 for ; Fri, 16 Nov 2012 05:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dqbumMt17j5EbHRhycSMgsLC36CVkpo0M2jFvAJtHHs=; b=ha3a9A9UW0UBAOUGywxLSXmEiA33BoHEEVCrhZ+1WRxXi0PIG908hI+v6XbyhqLguD Hk8MGT3Vkq4+RA2dAjwQpw30xkfb8fMtz8ULv6iDdXBgmd9npDj+sH/K7+ygOsNeY6ZK cQPqR0LF1sSoSwB9LwpXeuCMdLCCxdESIwZjQyn6mA2SNhHI4T/tAHFFhjCqJ/KdVuww J+c6ECUZi4LRvtiv+EgUAYeAUSgBRQ1MFQZWaCqiygXAMN3a4OoIXqryqld3SEGhNiDd y10Q/zUd6xBA+88ueEpCGbU0uezN9plM6XTaPgfalH0a2adhFAAiJZ5RiRf8Ng7ITcu4 LIuA== Received: by 10.14.199.134 with SMTP id x6mr13456246een.31.1353071374021; Fri, 16 Nov 2012 05:09:34 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id s1sm3403529eem.9.2012.11.16.05.09.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 05:09:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 16 Nov 2012 15:09:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1085) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 13:09:36 -0000 Med, I still see no reason to replicate information since what comes to "a = pure IPv6 profile for a 3GPP link", it should be exactly the same in = both documents. I am just trying to avoid misalignment now and in the = future. I would also argue that draft-binet-* is a profile for a = specific deployment(s) in mind, not a generic IPv6 profile for cellular. = It is a way more (not that it would be a bad thing though..). - Jouni On Nov 16, 2012, at 2:07 PM, = wrote: > Hi Jouni, >=20 > What I understood from the v6ops meeting is that wg participants see = these two documents have distinct objectives. As such the question of = overlapping does not apply as these documents serve two distinct = objectives. Furthermore, because draft-binet-*'s objective is to define = an IPv6 profile for cellular, we prefer the document be self-contained = and use consistent language for all requirements. >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : Jouni [mailto:jouni.nospam@gmail.com]=20 >> Envoy=E9 : jeudi 15 novembre 2012 16:40 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>=20 >>=20 >> Med, >>=20 >> I am slightly confused about the overlap of=20 >> draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >> recollection was that overlaps were supposed to be removed and=20 >> then concentrate on the remaining part in draft-binet-v6ops-*,=20 >> no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >> #22, #23, #25, #26, #27. My recommendation would be removing=20 >> those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >> because the base IPv6 compliancy would come from there and I=20 >> see no reason to repeat those here. >>=20 >> Then a question about the relevance of #24. Given the current=20 >> bandwidth in 3G/LTE is there really a need to compress=20 >> headers? And if people really see it as a life critical=20 >> feature to have, I would appreciate listing the ROHC profiles=20 >> that are essential (e.g., align with IR.92 & IR.58 that will=20 >> be implemented on the network side). >>=20 >> - Jouni >>=20 >>=20 >> On Nov 15, 2012, at 4:59 PM, =20 >> wrote: >>=20 >>> Dear all, >>>=20 >>> We submitted a new version of the draft to take into account=20 >> the comments received from M. Abrahamsson and P. Vickers. >>>=20 >>> The main changes are: >>>=20 >>> * Add some clarification text for REQ#3 >>> * Mention stateless dhcpv6 is useful to retrieve other=20 >> information than DNS >>> * Re-word REQ#15 >>> * Cite "Happy Eyeballs" in REQ#16 >>> * Update the text of REQ#17 >>> * Add two sub-requirements to REQ#19: IPv6-only connectivity + SLAAC >>> * Precise the ordering in REQ#21 >>>=20 >>> A more detailed diff is available at: >>>=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >> t-requirements-01 >>>=20 >>>=20 >>> Chairs, would it be possible to issue a Call For Adoption=20 >> for this document? Thanks. >>>=20 >>> Cheers, >>> Med >>>=20 >>> -----Message d'origine----- >>> De : i-d-announce-bounces@ietf.org=20 >> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >> internet-drafts@ietf.org >>> Envoy=E9 : jeudi 15 novembre 2012 15:53 >>> =C0 : i-d-announce@ietf.org >>> Objet : I-D Action:=20 >> draft-binet-v6ops-cellular-host-requirements-01.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line=20 >> Internet-Drafts directories. >>>=20 >>>=20 >>> Title : Internet Protocol Version 6 (IPv6)=20 >> Requirements for Cellular Hosts >>> Author(s) : David Binet >>> Mohamed Boucadair >>> Ales Vizdal >>> Cameron Byrne >>> Gang Chen >>> Filename :=20 >> draft-binet-v6ops-cellular-host-requirements-01.txt >>> Pages : 16 >>> Date : 2012-11-15 >>>=20 >>> Abstract: >>> This document lists a set of IPv6-related requirements to be >>> supported by cellular hosts. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>>=20 >> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >> t-requirements >>>=20 >>> There's also a htmlized version available at: >>>=20 >> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >> irements-01 >>>=20 >>> A diff from the previous version is available at: >>>=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >> t-requirements-01 >>>=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 >>=20 From mohamed.boucadair@orange.com Fri Nov 16 05:17:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70C21F850E for ; Fri, 16 Nov 2012 05:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD+J91hFDwLX for ; Fri, 16 Nov 2012 05:17:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B444621F84BA for ; Fri, 16 Nov 2012 05:17:21 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2EF0118CDAD; Fri, 16 Nov 2012 14:17:20 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F26824C06E; Fri, 16 Nov 2012 14:17:19 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 16 Nov 2012 14:17:19 +0100 From: To: jouni korhonen Date: Fri, 16 Nov 2012 14:17:18 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 Thread-Index: Ac3D+5/hhbwPGl9rSaiXXwgRtnMnbwAAKM3Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> In-Reply-To: <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> 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: 2012.10.24.110314 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 13:17:22 -0000 Re-, draft-binet-* assumes both DS and IPv6-only deployment modes. Nothing speci= fic there. Cheers, Med >-----Message d'origine----- >De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >Envoy=E9 : vendredi 16 novembre 2012 14:09 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : v6ops@ietf.org WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 > > >Med, > >I still see no reason to replicate information since what=20 >comes to "a pure IPv6 profile for a 3GPP link", it should be=20 >exactly the same in both documents. I am just trying to avoid=20 >misalignment now and in the future. I would also argue that=20 >draft-binet-* is a profile for a specific deployment(s) in=20 >mind, not a generic IPv6 profile for cellular. It is a way=20 >more (not that it would be a bad thing though..). > >- Jouni > > >On Nov 16, 2012, at 2:07 PM, =20 > wrote: > >> Hi Jouni, >>=20 >> What I understood from the v6ops meeting is that wg=20 >participants see these two documents have distinct objectives.=20 >As such the question of overlapping does not apply as these=20 >documents serve two distinct objectives. Furthermore, because=20 >draft-binet-*'s objective is to define an IPv6 profile for=20 >cellular, we prefer the document be self-contained and use=20 >consistent language for all requirements. >>=20 >> Cheers, >> Med=20 >>=20 >>> -----Message d'origine----- >>> De : Jouni [mailto:jouni.nospam@gmail.com]=20 >>> Envoy=E9 : jeudi 15 novembre 2012 16:40 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >>> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>>=20 >>>=20 >>> Med, >>>=20 >>> I am slightly confused about the overlap of=20 >>> draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >>> recollection was that overlaps were supposed to be removed and=20 >>> then concentrate on the remaining part in draft-binet-v6ops-*,=20 >>> no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >>> #22, #23, #25, #26, #27. My recommendation would be removing=20 >>> those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >>> because the base IPv6 compliancy would come from there and I=20 >>> see no reason to repeat those here. >>>=20 >>> Then a question about the relevance of #24. Given the current=20 >>> bandwidth in 3G/LTE is there really a need to compress=20 >>> headers? And if people really see it as a life critical=20 >>> feature to have, I would appreciate listing the ROHC profiles=20 >>> that are essential (e.g., align with IR.92 & IR.58 that will=20 >>> be implemented on the network side). >>>=20 >>> - Jouni >>>=20 >>>=20 >>> On Nov 15, 2012, at 4:59 PM, =20 >>> wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> We submitted a new version of the draft to take into account=20 >>> the comments received from M. Abrahamsson and P. Vickers. >>>>=20 >>>> The main changes are: >>>>=20 >>>> * Add some clarification text for REQ#3 >>>> * Mention stateless dhcpv6 is useful to retrieve other=20 >>> information than DNS >>>> * Re-word REQ#15 >>>> * Cite "Happy Eyeballs" in REQ#16 >>>> * Update the text of REQ#17 >>>> * Add two sub-requirements to REQ#19: IPv6-only=20 >connectivity + SLAAC >>>> * Precise the ordering in REQ#21 >>>>=20 >>>> A more detailed diff is available at: >>>>=20 >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>> t-requirements-01 >>>>=20 >>>>=20 >>>> Chairs, would it be possible to issue a Call For Adoption=20 >>> for this document? Thanks. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> -----Message d'origine----- >>>> De : i-d-announce-bounces@ietf.org=20 >>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>> internet-drafts@ietf.org >>>> Envoy=E9 : jeudi 15 novembre 2012 15:53 >>>> =C0 : i-d-announce@ietf.org >>>> Objet : I-D Action:=20 >>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line=20 >>> Internet-Drafts directories. >>>>=20 >>>>=20 >>>> Title : Internet Protocol Version 6 (IPv6)=20 >>> Requirements for Cellular Hosts >>>> Author(s) : David Binet >>>> Mohamed Boucadair >>>> Ales Vizdal >>>> Cameron Byrne >>>> Gang Chen >>>> Filename :=20 >>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>> Pages : 16 >>>> Date : 2012-11-15 >>>>=20 >>>> Abstract: >>>> This document lists a set of IPv6-related requirements to be >>>> supported by cellular hosts. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>>=20 >>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >>> t-requirements >>>>=20 >>>> There's also a htmlized version available at: >>>>=20 >>> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >>> irements-01 >>>>=20 >>>> A diff from the previous version is available at: >>>>=20 >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>> t-requirements-01 >>>>=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 >>>=20 > >= From Ted.Lemon@nominum.com Fri Nov 16 05:41:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BD221F8C23; Fri, 16 Nov 2012 05:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-o5+etsSt1w; Fri, 16 Nov 2012 05:41:00 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id AE61C21F8BA0; Fri, 16 Nov 2012 05:40:59 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUKZCa09AH3GM28ojK8OpYcpiMl2x3fdF@postini.com; Fri, 16 Nov 2012 05:40:59 PST 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 81BF41B8056; Fri, 16 Nov 2012 05:40:58 -0800 (PST) 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 719EC190043; Fri, 16 Nov 2012 05:40:58 -0800 (PST) (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; Fri, 16 Nov 2012 05:40:52 -0800 From: Ted Lemon To: Mark Smith Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw8QMn+T7t8ukdkiHzcz0NllQQpfs/pEA Date: Fri, 16 Nov 2012 13:40:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: <1353047488.86944.YahooMailNeo@web32501.mail.mud.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: <3FFE0540E124744A8C609D584A5FED1D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2012 13:41:01 -0000 On Nov 16, 2012, at 1:31 AM, Mark Smith wrote: > I agree with Joel, I think observation by most likely a router is a bette= r method, as it will capture address information regardless of whether it w= as configured via static, SLAAC or DHCPv6 (or any future methods). It's certainly true that a router can capture all the IPv4 and IPv6 address= es that a device with a particular MAC address uses. However, what a rout= er _can't_ do, and what this option allows to be done, is for a device that= has autoconfigured to then provide the network administrator with a hint a= s to what its FQDN should be. This information isn't available to the rou= ter. It seems to me that although it is true that it is worthwhile to define a m= echanism for getting common address information from a router, this is orth= ogonal to the question of whether a client-based mechanism for address regi= stration is useful. It seems to me that there are three broad classificat= ions of use cases here: 1. In an environment where address registration is mandatory, and hosts are= tightly controlled, this protocol may suffice. 2. In an environment where address registration is optional/advisory, this = protocol may suffice, since presumably the reason you register addresses is= to track client-sourced information like hostname that relates to the addr= ess. 3. In an environment where address registration is mandatory and hosts are = not tightly controlled, you need support for address registration on the ro= uter. However, you can _still_ benefit in this case from the DHCP-based a= ddress registration protocol; devices that support it can still provide hin= ts about the FQDN they want. I point this out because the reason I support this draft is the FQDN use ca= se. This is a use case that has seen substantial use in enterprise enviro= nments in IPv4. We do not currently have a solution to the problem for IP= v6, because in IPv6 we don't require DHCP for host configuration. This DH= CP extension allows us to leverage a DHCP infrastructure without _requiring= _ that hosts autoconfigure using DHCP, and without even _requiring_ that ho= sts register their addresses at all. I think Sheng has a different use case in mind, and from what I can tell hi= s use case falls into the first category, where mine falls into the second.= I know of other enterprise users who have use cases that fall into categ= ory 3; for them, this protocol will not be sufficient, and they will need t= he router-based protocol either instead, or as well. From markzzzsmith@yahoo.com.au Fri Nov 16 15:49:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41DB21F8A22 for ; Fri, 16 Nov 2012 15:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bG162pOqrj4 for ; Fri, 16 Nov 2012 15:49:17 -0800 (PST) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with ESMTP id A28BF21F8924 for ; Fri, 16 Nov 2012 15:49:16 -0800 (PST) Received: from [98.139.215.141] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 Received: from [98.139.212.237] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 954847.88684.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 96796 invoked by uid 60001); 16 Nov 2012 23:49:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1353109754; bh=qZuG2Il6poJVkp1h78Cou8s8va6f5K4j9d6B7bWaL7s=; 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:Content-Transfer-Encoding; b=x2AbUiggxG3mchadIMDuo/tuyvD2iHJdO4LttCetGF0qy3XInDsujqHYkrOiYRtmDCXM8MS2C7w9kv0hI2IPQ8QsEDtTbVcVabLGUzl7xd5vV4IvzTuPt21heVjkrkWz0Gs84pS/lbPUlsjX6Nqn69S8tSZfwXp464MJddNOlMY= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jJIhcYoL0/13l05gJQNrcyfhgjYhJc5zbpOV/PUTIKokLkcchv+SU2St66DhxEV3PDgg83aSZXNJ9/w003t0CA0zY3v7ToW6Lu5xZe6s28daMuaNVHaMrJrmvNIfuhuUp/QUYJuSQcdmV3pfWzmEmXuxjYUcbniEC1Vgsq8/U3U=; X-YMail-OSG: Eaqq5egVM1llOtuiR5OIDPfgPU_OaoK0XBsvxwnQMvm2lLJ 7ZOankvcrPdTo0FlX4836Mpp_Yoj0qA50fsP5q6SZRvPrU3k_si35MaUVmOZ DB5Jt5wTPpR3OVH6Juy_PdYhKrtbwrSDCsnrmgZ9zdX3LgmrYad2w1Wf8ZbD VhtPG9BQ3iNKEpWNhB6rHYWH_tN7eaSJqjx5oX02.ihP80yN4UiJROzQPX6A oW_Zs0L0EXfM4RaA3LyuLYtgi9yNxead.5SX6FycuTVxMuBUpZ3BEU44kmD3 q07ER261HFPdQj5vQgrZr6JoSXcniOE6cHmzXTee71kG0EsJ31FpvbwGEFBE ucCCEHxLPc0dHCXMxy5dfQ9YnJApHrW2d7iRjj4zhcQ99O49O9GGohe5KUBk T6jfGutYMTiS4mu9cOiomY0kik4jrq8yyPx_1Zjm2dat9WkspmJ8KoqlOitZ q81DeI3.sjWcOHSPuJpq7p1jRmdlbGZrGQ7_2DkDdVqpQT_lDlqs576raee9 invmz16WaQ1KRaizE Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Fri, 16 Nov 2012 15:49:14 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IFRlZCBMZW1vbiA8VGVkLkxlbW9uQG5vbWludW0uY29tPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsgImRoY3dnQGlldGYub3JnIiA8ZGhjd2dAaWV0Zi5vcmc.OyBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc.OyAiZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> Message-ID: <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Fri, 16 Nov 2012 15:49:14 -0800 (PST) From: Mark Smith To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 23:49:17 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Ted Lemon =0A> To: Mark Smith =0A> Cc: Sheng Jian= g ; joel jaeggli ; "dhcwg@ietf.org= " ; IPv6 Ops WG ; "draft-ietf-dhc-addr-regi= stration@tools.ietf.org" = =0A> Sent: Saturday, 17 November 2012 12:40 AM=0A> Subject: Re: [v6ops] som= e feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-0= 1=0A> =0A> On Nov 16, 2012, at 1:31 AM, Mark Smith wrote:=0A>> I agree with Joel, I think observation by most likely a ro= uter is a better =0A> method, as it will capture address information regard= less of whether it was =0A> configured via static, SLAAC or DHCPv6 (or any = future methods).=0A> =0A> It's certainly true that a router can capture all= the IPv4 and IPv6 =0A> addresses that a device with a particular MAC addre= ss uses.=A0 However, what a =0A> router _can't_ do, and what this option a= llows to be done, is for a device =0A> that has autoconfigured to then prov= ide the network administrator with a hint as =0A> to what its FQDN should b= e.=A0 This information isn't available to the =0A> router.=0A> =0A> It see= ms to me that although it is true that it is worthwhile to define a =0A> me= chanism for getting common address information from a router, this is =0A> = orthogonal to the question of whether a client-based mechanism for address = =0A> registration is useful.=A0 It seems to me that there are three broad = =0A> classifications of use cases here:=0A> =0A> 1. In an environment where= address registration is mandatory, and hosts are =0A> tightly controlled, = this protocol may suffice.=0A> 2. In an environment where address registrat= ion is optional/advisory, this=A0=0A=0A> protocol may suffice, since presum= ably the reason you register addresses is to =0A> track client-sourced info= rmation like hostname that relates to the address.=0A> 3. In an environment= where address registration is mandatory and hosts are not =0A> tightly con= trolled, you need support for address registration on the router.=A0 =0A> H= owever, you can _still_ benefit in this case from the DHCP-based address = =0A> registration protocol; devices that support it can still provide hints= about the =0A> FQDN they want.=0A> =0A> I point this out because the reaso= n I support this draft is the FQDN use case.=A0 =0A> This is a use case tha= t has seen substantial use in enterprise environments in =0A> IPv4.=A0 We = do not currently have a solution to the problem for IPv6, because in =0A> I= Pv6 we don't require DHCP for host configuration.=A0 This DHCP extension = =0A> allows us to leverage a DHCP infrastructure without _requiring_ that h= osts =0A> autoconfigure using DHCP, and without even _requiring_ that hosts= register their =0A> addresses at all.=0A> =0A> I think Sheng has a differe= nt use case in mind, and from what I can tell his use =0A> case falls into = the first category, where mine falls into the second.=A0 I know =0A> of ot= her enterprise users who have use cases that fall into category 3; for =0A>= them, this protocol will not be sufficient, and they will need the router-= based =0A> protocol either instead, or as well.=0A> =0A=0AIt seems to me th= at either RFC3122 - "Extensions to IPv6 Neighbor Discovery=0A=0Afor Inverse= Discovery Specification" and/or RFC4620 - "IPv6 Node Information=0AQueries= " might be able to meet those needs. Where they considered?=0A=0AI think th= ere are advantages to keeping the mechanisms to collect information=0Aabout= hosts and their addresses independent of how those addresses are=0Aassigne= d or derived. For example, it seems that it might be valid to have=0Aa host= use both SLAAC (i.e. PIO with the A bit on) and DHCPv6 (RA with the=0AM bi= t on) to configure it's addresses, as the M bit doesn't say that A bits=0Ai= n PIOs must be ignored or vice versa. While a link will usually use one or = the other=0Aof the methods, the use case is a period of transition between = the two=0Ae.g. moving from SLAAC to DHCPv6. There is some evidence that Win= dows 7=0Ahas adopted the exclusive one or the other approach to SLAAC and D= HCPv6,=0Aand that is causing an issue when there is a later RA that has a d= ifferent M=0Abit value i.e. the later RA has the M bit switched off, to mov= e the subnet=0Afrom DHCPv6 address assignment to SLAAC based assignment, an= d the DHCPv6=0Aaddresses are being expired immediately, regardless of the p= referred and=0Avalid lifetimes that the DHCPv6 server announced. In other w= ords, instead=0Aof being able to do a phased and gradual transition from DH= CPv6 to SLAAC=0Avia preferred and valid lifetimes, this is forcing a disrup= tive change.=0A=0AStatic addresses, and Tokenised IPv6 identifiers=0A(http:= //tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02)=0Awou= ld also be a reason to try to use address and host information query=0Ameth= ods that are address configuration method independent.=0A=0ARegards,=0AMark= . From tjc@ecs.soton.ac.uk Sat Nov 17 04:19:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3F21F8765; Sat, 17 Nov 2012 04:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN-3RTB2UBT3; Sat, 17 Nov 2012 04:19:34 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5161E21F8206; Sat, 17 Nov 2012 04:19:34 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAHCJSkg010501; Sat, 17 Nov 2012 12:19:30 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qAHCJSkg010501 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1353154770; bh=AWseN6Y2Uw8r40TUiuVKxt3HbbI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=t6LbBvtCvVgg+/rMQeiKEmj+jsLgaN3kZMlRt0NoMp8hHgesidteMS69GG3OqSu+n LvNTYTY1kuhvv+DqNXqMdeZrzumOiBBiXU64bJPsrHUu98WbV1uLcxtX/UDV7MSH0Y AestAkookjTcUx3mhxUTZoy3o8sV9pJtuxqT8vRM= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id oAGCJS04306320666p ret-id none; Sat, 17 Nov 2012 12:19:30 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAHCI5Yc026344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Nov 2012 12:18:06 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Sat, 17 Nov 2012 12:18:05 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> To: dhcwg@ietf.org, IPv6 Ops WG , draft-ietf-dhc-addr-registration@tools.ietf.org X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oAGCJS043063206600; tid=oAGCJS04306320666p; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qAHCJSkg010501 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2012 12:19:35 -0000 On 16 Nov 2012, at 23:49, Mark Smith wrote: > Hi, >=20 > I think there are advantages to keeping the mechanisms to collect = information > about hosts and their addresses independent of how those addresses are > assigned or derived.=20 I think this is a fair point. I also can't help but think that there is likely to be some overlap = between what this draft is trying to do, and what we might end up with = as a result of the homenet and/or mdnsext work in extending zeroconf = methods to home and enterprise/campus networks. Simply for address usage tracking, we've found it sufficient to run = tools that poll the switch/router infrastructure. We do that on a campus = using open source tools and it works just fine, provided the polling is = configured to take into account the expiration timers of the data being = gathered from the devices. Where the tool is also aware of the all the = network devices, their connectivity, prefix allocations, VLANs, switch = port configurations, etc, then you have pretty much all you need for = accountability. We also use 802.1X for wireless (eduroam) and are = beginning to use it for wired ports as well. I've not looked at Fernando's tool. I would assume it achieves the same = thing in terms of address tracking, but I'd argue that integrating the = polling/tracking with network monitoring/management tools that have the = 'bigger picture' is advantageous. Tim= From denghui02@gmail.com Sat Nov 17 08:56:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31F21F8708 for ; Sat, 17 Nov 2012 08:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ofGjRDTcasb for ; Sat, 17 Nov 2012 08:56:14 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6338F21F846C for ; Sat, 17 Nov 2012 08:56:14 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so2449279qaa.10 for ; Sat, 17 Nov 2012 08:56:13 -0800 (PST) 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=ukyvS39imvXeLun/v1vlz0nSKlGL8sUK/ISbMQxxJIs=; b=n7q023eYIYE3RfZqFNgZ1nJSZIVXHLK2soJBKL8X8dcDDW9rCM65R4gBh3sGmD38Fz FUR6bqZDZsOO+Kvy7Hf9yM3SHQQwA0HpOkJGPQnyGJD9WOpu1/td89uwCEwDH4wdldUo Q/Cq744yYw7a0zJhohAFBK2hFfCAEFUA8qy2Yj1yAW9Ex9Zy9nRDZwnJvOSHOT6WfVg9 FsIGynaoq/Sj/tz7ppoAjkrIeLH/sJWsHRJ+oCGb6Vf3CNKGkjH502dQjjMtGX2Dqx0q oL4TenN0z3p8b/uYBAu6vN4kNPUk2l5u70TtUXVVsYYoilcJXda7IwRABSc2cNX56QiP Xl0g== MIME-Version: 1.0 Received: by 10.224.201.73 with SMTP id ez9mr7550406qab.92.1353171373805; Sat, 17 Nov 2012 08:56:13 -0800 (PST) Received: by 10.49.97.4 with HTTP; Sat, 17 Nov 2012 08:56:13 -0800 (PST) Date: Sat, 17 Nov 2012 10:56:13 -0600 Message-ID: From: Hui Deng To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=20cf3010edaf0e4f1a04ceb3c3f2 Subject: [v6ops] Clarifications on draft-ietf-v6ops-rfc3316bis-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: Sat, 17 Nov 2012 16:56:15 -0000 --20cf3010edaf0e4f1a04ceb3c3f2 Content-Type: text/plain; charset=ISO-8859-1 Hello, authors, in section 2.11, it says "learning the DNS server addresses from the link layer signaling can be cumbersome when the MT and the TE are separated using other techniques than PPP interface" Can you be more specific about what else could be used? and what can be cumbersome? for privacy consideration, can you help to write some analysis text about the relationship with "always on capability in 3GPP" Does SIPTO/LIPA has some influence on this document? thanks -Hui --20cf3010edaf0e4f1a04ceb3c3f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, authors,
=A0
in section 2.11, it says
"learning the DNS server=A0 addresses from the link layer signal= ing can be cumbersome when the MT
=A0=A0 and the TE are separated using = other techniques than PPP interface"
Can you be more specific about what else could be used? and what can b= e cumbersome?
=A0
for privacy consideration,
can you help to write some analysis text about the relationship with "= ;always on capability in 3GPP"
=A0
Does SIPTO/LIPA has some influence on this document?
=A0
thanks
=A0
-Hui
--20cf3010edaf0e4f1a04ceb3c3f2-- From jouni.nospam@gmail.com Sat Nov 17 15:14:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759821F862B for ; Sat, 17 Nov 2012 15:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCwK29kdn+li for ; Sat, 17 Nov 2012 15:14:10 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69BFF21F84CE for ; Sat, 17 Nov 2012 15:14:10 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2512869eek.31 for ; Sat, 17 Nov 2012 15:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WrkXvmBEvccC1aMy+sR5eOGOu4M0VYVbKB0P2lp7F4Y=; b=rojIYvBSND0WBdesepy+ywtkN1fg38cT8J7hZpYFaOLmSGYjNKuF0MAoRpeOK64+jm urph/3+fy7aIeL6jv7sjbfXYX4XPPrP7TDGxGXXmFcKQjjzaPRpFL+AX/4mYiRxHXa0b 791R2veDRJC0ODGsIzaAu2GTcCAkpY0sOZarVaLz4jsC43y3TL1LnojQ4DQdGRGeFSPn dRiJ5t+6SLuj6dmDZL9paS1aV99z0IvOs0HJCGOe0lQUGJ4byZpfKZyqFpgYoMnhD1u+ ptN9WPYAChYjMpkbPvHeV8FwwJy7Pp/eUv7bvibvI8qYga7jrECd0JBqe0saDldgRmX0 /xvA== Received: by 10.14.200.194 with SMTP id z42mr9741449een.13.1353194049622; Sat, 17 Nov 2012 15:14:09 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id e7sm13527212eep.1.2012.11.17.15.14.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Nov 2012 15:14:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 18 Nov 2012 01:14:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F49F841-FD9E-4996-9C17-245F46C6EABE@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1085) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2012 23:14:17 -0000 Hi, Likewise rfc3316bis assumes IPv6-only or dual-stack. Point being, = rfc3316bis does not do in direction that is not necessary to run IPv6 = (in a possibly multi interfaced host). IMHO the rest like NAT related = recommendations, transition recommendations, WLAN specifics, tethering = recommendations are then well served in draft-bonet-*. - Jouni On Nov 16, 2012, at 3:17 PM, = wrote: > Re-, >=20 > draft-binet-* assumes both DS and IPv6-only deployment modes. Nothing = specific there. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >> Envoy=E9 : vendredi 16 novembre 2012 14:09 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : v6ops@ietf.org WG >> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>=20 >>=20 >> Med, >>=20 >> I still see no reason to replicate information since what=20 >> comes to "a pure IPv6 profile for a 3GPP link", it should be=20 >> exactly the same in both documents. I am just trying to avoid=20 >> misalignment now and in the future. I would also argue that=20 >> draft-binet-* is a profile for a specific deployment(s) in=20 >> mind, not a generic IPv6 profile for cellular. It is a way=20 >> more (not that it would be a bad thing though..). >>=20 >> - Jouni >>=20 >>=20 >> On Nov 16, 2012, at 2:07 PM, =20 >> wrote: >>=20 >>> Hi Jouni, >>>=20 >>> What I understood from the v6ops meeting is that wg=20 >> participants see these two documents have distinct objectives.=20 >> As such the question of overlapping does not apply as these=20 >> documents serve two distinct objectives. Furthermore, because=20 >> draft-binet-*'s objective is to define an IPv6 profile for=20 >> cellular, we prefer the document be self-contained and use=20 >> consistent language for all requirements. >>>=20 >>> Cheers, >>> Med=20 >>>=20 >>>> -----Message d'origine----- >>>> De : Jouni [mailto:jouni.nospam@gmail.com]=20 >>>> Envoy=E9 : jeudi 15 novembre 2012 16:40 >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>> Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >>>> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>>>=20 >>>>=20 >>>> Med, >>>>=20 >>>> I am slightly confused about the overlap of=20 >>>> draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >>>> recollection was that overlaps were supposed to be removed and=20 >>>> then concentrate on the remaining part in draft-binet-v6ops-*,=20 >>>> no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >>>> #22, #23, #25, #26, #27. My recommendation would be removing=20 >>>> those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >>>> because the base IPv6 compliancy would come from there and I=20 >>>> see no reason to repeat those here. >>>>=20 >>>> Then a question about the relevance of #24. Given the current=20 >>>> bandwidth in 3G/LTE is there really a need to compress=20 >>>> headers? And if people really see it as a life critical=20 >>>> feature to have, I would appreciate listing the ROHC profiles=20 >>>> that are essential (e.g., align with IR.92 & IR.58 that will=20 >>>> be implemented on the network side). >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>> On Nov 15, 2012, at 4:59 PM, =20 >>>> wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> We submitted a new version of the draft to take into account=20 >>>> the comments received from M. Abrahamsson and P. Vickers. >>>>>=20 >>>>> The main changes are: >>>>>=20 >>>>> * Add some clarification text for REQ#3 >>>>> * Mention stateless dhcpv6 is useful to retrieve other=20 >>>> information than DNS >>>>> * Re-word REQ#15 >>>>> * Cite "Happy Eyeballs" in REQ#16 >>>>> * Update the text of REQ#17 >>>>> * Add two sub-requirements to REQ#19: IPv6-only=20 >> connectivity + SLAAC >>>>> * Precise the ordering in REQ#21 >>>>>=20 >>>>> A more detailed diff is available at: >>>>>=20 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>> t-requirements-01 >>>>>=20 >>>>>=20 >>>>> Chairs, would it be possible to issue a Call For Adoption=20 >>>> for this document? Thanks. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : i-d-announce-bounces@ietf.org=20 >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>> internet-drafts@ietf.org >>>>> Envoy=E9 : jeudi 15 novembre 2012 15:53 >>>>> =C0 : i-d-announce@ietf.org >>>>> Objet : I-D Action:=20 >>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line=20 >>>> Internet-Drafts directories. >>>>>=20 >>>>>=20 >>>>> Title : Internet Protocol Version 6 (IPv6)=20 >>>> Requirements for Cellular Hosts >>>>> Author(s) : David Binet >>>>> Mohamed Boucadair >>>>> Ales Vizdal >>>>> Cameron Byrne >>>>> Gang Chen >>>>> Filename :=20 >>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>> Pages : 16 >>>>> Date : 2012-11-15 >>>>>=20 >>>>> Abstract: >>>>> This document lists a set of IPv6-related requirements to be >>>>> supported by cellular hosts. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>>=20 >>>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >>>> t-requirements >>>>>=20 >>>>> There's also a htmlized version available at: >>>>>=20 >>>> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >>>> irements-01 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>>=20 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>> t-requirements-01 >>>>>=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 >>>>=20 >>=20 From jouni.nospam@gmail.com Sat Nov 17 15:31:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9B21F8450 for ; Sat, 17 Nov 2012 15:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw3T+rnlYtOX for ; Sat, 17 Nov 2012 15:31:29 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50021F8438 for ; Sat, 17 Nov 2012 15:31:28 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so817385eaa.31 for ; Sat, 17 Nov 2012 15:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=U8SEK38sQDZseOmhc2zqc1yHdkpkQh5/+bXi2u+aCk0=; b=jqF3FbvUQgpLhzzR8zkvdy877qF80pFbJBJHBIqW7oOavV2X9RGoh57PKn0zYdIaML c3Ytx7SinzmgXremPJStLuO6WWAGvlLLGDOLnt8X7V55FhiYowCFFtleAOqEHcTpdEHL Es59QlCMrhbQCKGhgAE7xO3J6GHBk2bxA4W8BpaLvL1DjefC9nrvS4euf/hPaROnDc1x uBRt9Te+HJQmEQEgmDPYaW5ZHVGoJtyfLTRQu6kdNnuobAyPyYq/hav/HyGds5Sqf1z2 Z8qnEDLT0/VTtMLUitaKiMfKKIvCTHzMyLKGeKOGFpfh70PUOfiVEIauu4+obWSgAlcz 0B/Q== Received: by 10.14.172.195 with SMTP id t43mr9910963eel.17.1353195088107; Sat, 17 Nov 2012 15:31:28 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id y44sm13565310eel.14.2012.11.17.15.31.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Nov 2012 15:31:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Sun, 18 Nov 2012 01:31:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45B89E2C-1BB2-4212-9126-B1F377784474@gmail.com> References: To: Hui Deng X-Mailer: Apple Mail (2.1085) Cc: v6ops@ietf.org Subject: Re: [v6ops] Clarifications on draft-ietf-v6ops-rfc3316bis-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: Sat, 17 Nov 2012 23:31:30 -0000 Hi, On Nov 17, 2012, at 6:56 PM, Hui Deng wrote: > Hello, authors, > =20 > in section 2.11, it says > "learning the DNS server addresses from the link layer signaling can = be cumbersome when the MT > and the TE are separated using other techniques than PPP interface" > Can you be more specific about what else could be used? and what can = be cumbersome? Like proprietary APIs or USB cdc etc between the MT and the TE. There = might not be "easy" or standard way to let the TE stack to learn DNS = information that the network sent in NAS signaling. PPP had one. = Learning the DNS information using IP protocols between the TE stack and = the gateway just makes the MT implementation easier and avoids OS = specific hacks there. > for privacy consideration, > can you help to write some analysis text about the relationship with = "always on capability in 3GPP" Do you mean analysis of a cellular host having the same prefix in use = for a long periods of time? > Does SIPTO/LIPA has some influence on this document? I am not sure yet. Maybe a recommendation to use DNA might be useful = here? - Jouni > =20 > thanks > =20 > -Hui > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Sun Nov 18 19:04:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CFC21F85AE; Sun, 18 Nov 2012 19:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgvChnhR3Q-z; Sun, 18 Nov 2012 19:04:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5573621F8596; Sun, 18 Nov 2012 19:04:28 -0800 (PST) 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 AMX53423; Mon, 19 Nov 2012 03:04:23 +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.3; Mon, 19 Nov 2012 03:03:57 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 11:04:22 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 11:04:15 +0800 From: Sheng Jiang To: Ted Lemon , Mark Smith Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxAAG5EreTzevi0GNq9gcFwidkJfwdtFw Date: Mon, 19 Nov 2012 03:03:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 03:04:30 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogVGVkIExlbW9uIFttYWlsdG86VGVk LkxlbW9uQG5vbWludW0uY29tXQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgOTo0 MSBQTQ0KPlRvOiBNYXJrIFNtaXRoDQo+Q2M6IFNoZW5nIEppYW5nOyBqb2VsIGphZWdnbGk7IGRo Y3dnQGlldGYub3JnOyBJUHY2IE9wcyBXRzsNCj5kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJh dGlvbkB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIHNvbWUgZmVlZGJhY2sg b24NCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lz dHJhdGlvbi0wMQ0KPg0KPk9uIE5vdiAxNiwgMjAxMiwgYXQgMTozMSBBTSwgTWFyayBTbWl0aCA8 bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4NCj53cm90ZToNCj4+IEkgYWdyZWUgd2l0aCBKb2Vs LCBJIHRoaW5rIG9ic2VydmF0aW9uIGJ5IG1vc3QgbGlrZWx5IGEgcm91dGVyIGlzIGEgYmV0dGVy DQo+bWV0aG9kLCBhcyBpdCB3aWxsIGNhcHR1cmUgYWRkcmVzcyBpbmZvcm1hdGlvbiByZWdhcmRs ZXNzIG9mIHdoZXRoZXIgaXQgd2FzDQo+Y29uZmlndXJlZCB2aWEgc3RhdGljLCBTTEFBQyBvciBE SENQdjYgKG9yIGFueSBmdXR1cmUgbWV0aG9kcykuDQo+DQo+SXQncyBjZXJ0YWlubHkgdHJ1ZSB0 aGF0IGEgcm91dGVyIGNhbiBjYXB0dXJlIGFsbCB0aGUgSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMN Cj50aGF0IGEgZGV2aWNlIHdpdGggYSBwYXJ0aWN1bGFyIE1BQyBhZGRyZXNzIHVzZXMuICAgSG93 ZXZlciwgd2hhdCBhIHJvdXRlcg0KPl9jYW4ndF8gZG8sIGFuZCB3aGF0IHRoaXMgb3B0aW9uIGFs bG93cyB0byBiZSBkb25lLCBpcyBmb3IgYSBkZXZpY2UgdGhhdCBoYXMNCj5hdXRvY29uZmlndXJl ZCB0byB0aGVuIHByb3ZpZGUgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB3aXRoIGEgaGludCBh cyB0bw0KPndoYXQgaXRzIEZRRE4gc2hvdWxkIGJlLiAgIFRoaXMgaW5mb3JtYXRpb24gaXNuJ3Qg YXZhaWxhYmxlIHRvIHRoZSByb3V0ZXIuDQo+DQo+SXQgc2VlbXMgdG8gbWUgdGhhdCBhbHRob3Vn aCBpdCBpcyB0cnVlIHRoYXQgaXQgaXMgd29ydGh3aGlsZSB0byBkZWZpbmUgYQ0KPm1lY2hhbmlz bSBmb3IgZ2V0dGluZyBjb21tb24gYWRkcmVzcyBpbmZvcm1hdGlvbiBmcm9tIGEgcm91dGVyLCB0 aGlzIGlzDQo+b3J0aG9nb25hbCB0byB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBhIGNsaWVudC1i YXNlZCBtZWNoYW5pc20gZm9yIGFkZHJlc3MNCj5yZWdpc3RyYXRpb24gaXMgdXNlZnVsLiAgIEl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgYXJlIHRocmVlIGJyb2FkDQo+Y2xhc3NpZmljYXRpb25z IG9mIHVzZSBjYXNlcyBoZXJlOg0KPg0KPjEuIEluIGFuIGVudmlyb25tZW50IHdoZXJlIGFkZHJl c3MgcmVnaXN0cmF0aW9uIGlzIG1hbmRhdG9yeSwgYW5kIGhvc3RzIGFyZQ0KPnRpZ2h0bHkgY29u dHJvbGxlZCwgdGhpcyBwcm90b2NvbCBtYXkgc3VmZmljZS4NCj4yLiBJbiBhbiBlbnZpcm9ubWVu dCB3aGVyZSBhZGRyZXNzIHJlZ2lzdHJhdGlvbiBpcyBvcHRpb25hbC9hZHZpc29yeSwgdGhpcw0K PnByb3RvY29sIG1heSBzdWZmaWNlLCBzaW5jZSBwcmVzdW1hYmx5IHRoZSByZWFzb24geW91IHJl Z2lzdGVyIGFkZHJlc3NlcyBpcyB0bw0KPnRyYWNrIGNsaWVudC1zb3VyY2VkIGluZm9ybWF0aW9u IGxpa2UgaG9zdG5hbWUgdGhhdCByZWxhdGVzIHRvIHRoZSBhZGRyZXNzLg0KPjMuIEluIGFuIGVu dmlyb25tZW50IHdoZXJlIGFkZHJlc3MgcmVnaXN0cmF0aW9uIGlzIG1hbmRhdG9yeSBhbmQgaG9z dHMgYXJlDQo+bm90IHRpZ2h0bHkgY29udHJvbGxlZCwgeW91IG5lZWQgc3VwcG9ydCBmb3IgYWRk cmVzcyByZWdpc3RyYXRpb24gb24gdGhlIHJvdXRlci4NCj5Ib3dldmVyLCB5b3UgY2FuIF9zdGls bF8gYmVuZWZpdCBpbiB0aGlzIGNhc2UgZnJvbSB0aGUgREhDUC1iYXNlZCBhZGRyZXNzDQo+cmVn aXN0cmF0aW9uIHByb3RvY29sOyBkZXZpY2VzIHRoYXQgc3VwcG9ydCBpdCBjYW4gc3RpbGwgcHJv dmlkZSBoaW50cyBhYm91dCB0aGUNCj5GUUROIHRoZXkgd2FudC4NCj4NCj5JIHBvaW50IHRoaXMg b3V0IGJlY2F1c2UgdGhlIHJlYXNvbiBJIHN1cHBvcnQgdGhpcyBkcmFmdCBpcyB0aGUgRlFETiB1 c2UgY2FzZS4NCj5UaGlzIGlzIGEgdXNlIGNhc2UgdGhhdCBoYXMgc2VlbiBzdWJzdGFudGlhbCB1 c2UgaW4gZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMgaW4NCj5JUHY0LiAgIFdlIGRvIG5vdCBjdXJy ZW50bHkgaGF2ZSBhIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIGZvciBJUHY2LCBiZWNhdXNlDQo+ aW4gSVB2NiB3ZSBkb24ndCByZXF1aXJlIERIQ1AgZm9yIGhvc3QgY29uZmlndXJhdGlvbi4gICBU aGlzIERIQ1AgZXh0ZW5zaW9uDQo+YWxsb3dzIHVzIHRvIGxldmVyYWdlIGEgREhDUCBpbmZyYXN0 cnVjdHVyZSB3aXRob3V0IF9yZXF1aXJpbmdfIHRoYXQgaG9zdHMNCj5hdXRvY29uZmlndXJlIHVz aW5nIERIQ1AsIGFuZCB3aXRob3V0IGV2ZW4gX3JlcXVpcmluZ18gdGhhdCBob3N0cyByZWdpc3Rl cg0KPnRoZWlyIGFkZHJlc3NlcyBhdCBhbGwuDQo+DQo+SSB0aGluayBTaGVuZyBoYXMgYSBkaWZm ZXJlbnQgdXNlIGNhc2UgaW4gbWluZCwgYW5kIGZyb20gd2hhdCBJIGNhbiB0ZWxsIGhpcyB1c2UN Cj5jYXNlIGZhbGxzIGludG8gdGhlIGZpcnN0IGNhdGVnb3J5LCB3aGVyZSBtaW5lIGZhbGxzIGlu dG8gdGhlIHNlY29uZC4gICBJIGtub3cNCj5vZiBvdGhlciBlbnRlcnByaXNlIHVzZXJzIHdobyBo YXZlIHVzZSBjYXNlcyB0aGF0IGZhbGwgaW50byBjYXRlZ29yeSAzOyBmb3INCj50aGVtLCB0aGlz IHByb3RvY29sIHdpbGwgbm90IGJlIHN1ZmZpY2llbnQsIGFuZCB0aGV5IHdpbGwgbmVlZCB0aGUg cm91dGVyLWJhc2VkDQo+cHJvdG9jb2wgZWl0aGVyIGluc3RlYWQsIG9yIGFzIHdlbGwuDQoNCkhp LCBUZWQsDQoNClRoYW5rcyBmb3IgeW91ciBlbWFpbC4gWWVzLCBteSBvcmlnaW5hbCB1c2UgY2Fz ZSBmYWxscyBpbnRvIHRoZSBmaXJzdCBjYXRlZ29yeS4gSG93ZXZlciwgc2luY2Ugd2UgYXJlIHRy eWluZyB0byBkZWZpbmUgYSBnZW5lcmljIGFkZHIgcmVnaXN0cmF0aW9uIG1lY2hhbmlzbSwgd2Ug Y291bGQgaW5jbHVkZSBtb3JlIGFwcGxpY2FibGUgdXNlIGNhc2VzLiBJIGd1ZXNzIHdoYXQgd2Ug c2hvdWxkIGRvIG5vdyBpcyB0byBhZGQgYSAiQXBwbGljYWJpbGl0eSIgc2VjdGlvbiBpbnRvIHRo ZSBkcmFmdC4gQXJlIHlvdSBpbnRlcmVzdGVkIGFuZCBoYXZlIHRpbWUgdG8gY29udHJpYnV0ZSBz b21lIHRleHQ/DQoNCkZvciBtZSwgcm91dGVyLWJhc2VkIGFkZHIgcmVnaXN0cmF0aW9uIG1heSBu ZWVkIGFub3RoZXIgZGVkaWNhdGVkIGRyYWZ0LiBBbHRob3VnaCBjdXJyZW50IElBIGNhbiB3b3Jr IG91dCwgYSBuZXcgREhDUCBvcHRpb24gdGhhdCBzdXBwb3J0IGJ1bGsgYWRkciByZWdpc3RyYXRp b24gbWF5IGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gb25lIGFkZHIgcGVyIHRpbWUuIFdoYXQncyB5 b3VyIG9waW5pb24/DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg== From Ted.Lemon@nominum.com Sun Nov 18 19:14:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE4E21F85D9; Sun, 18 Nov 2012 19:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahS2PTJlyHAk; Sun, 18 Nov 2012 19:14:14 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E3B4721F85D6; Sun, 18 Nov 2012 19:14:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUKmkBCCvqyWxevgBXRUDaRrapNoeoAD/@postini.com; Sun, 18 Nov 2012 19:14:13 PST 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 247941B80A9; Sun, 18 Nov 2012 19:14:12 -0800 (PST) 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 186FD190043; Sun, 18 Nov 2012 19:14:12 -0800 (PST) (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; Sun, 18 Nov 2012 19:14:12 -0800 From: Ted Lemon To: Sheng Jiang Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxgKaF9DIw6/Nnk+UmCfAcna/WpfxAfqA Date: Mon, 19 Nov 2012 03:14:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.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: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] [dhcwg] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 03:14:15 -0000 On Nov 18, 2012, at 10:03 PM, Sheng Jiang wrote: > Thanks for your email. Yes, my original use case falls into the first cat= egory. However, since we are trying to define a generic addr registration m= echanism, we could include more applicable use cases. I guess what we shoul= d do now is to add a "Applicability" section into the draft. Are you intere= sted and have time to contribute some text? I can try. I have a lot of things on my list. :} > For me, router-based addr registration may need another dedicated draft. = Although current IA can work out, a new DHCP option that support bulk addr = registration may be more efficient than one addr per time. What's your opin= ion? I think that bulk registration won't work because hosts aren't discovered a= ll at the same time; either the router waits until it's accumulated enough = to fill a packet, or it sends an update each time it discovers a new one. From lorenzo@google.com Sun Nov 18 21:06:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B60221F89C1 for ; Sun, 18 Nov 2012 21:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ0hRrwLacjJ for ; Sun, 18 Nov 2012 21:06:43 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67A21F881A for ; Sun, 18 Nov 2012 21:06:43 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so4827039obb.31 for ; Sun, 18 Nov 2012 21:06:43 -0800 (PST) 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=uw7v7F1gCteUtnjBhP+8W6M0tbSAxSjU6HSc7Ypn+5s=; b=OfAd01h6Guj7bhSlpbGSwrSc8VrIlZQJJpYOm3RyABK8QYdc3IyB/Kgt75bpeDb6Uw FxBUpd9faZhKuGvxhF0fC2I7iX5S2j/njIygpn72EpKGTwR5b+T0IsOqkKc+LFdFJXkx rRsooK1+vAbmrboCl0TO8+mDtJNLrbaatuhRjZAGDAEasX/aSUfzNUZG0gDmCHC6exNr yE2Ju7yqAdAIAip5+601+b8wUKw/emq7C86tPG9N0LYzuWhvAiWGhecwJ4Nn0g7DeJ+U 909RJc1I8IyaQOkkJk63TU1gxa3ZVuoCyWUzxCvxTYVaIp3pX+hkW45IGUSOlpxoCHvI mAwA== 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=uw7v7F1gCteUtnjBhP+8W6M0tbSAxSjU6HSc7Ypn+5s=; b=GLfRJWU/Igj+rBmC9SQ0uYMoFHjt7MPqVRepvHMg8wZaBVzYHx/8gqcffN2/De8LSx bm/iaGj4fzqj4W/FVNCb3O6bdCghSdoQH9cT0U1GCccJC7tFuJZbpi/9OxtWynz4suoC AoIpNbA616QgcLofibfRC0JHmsYXBfD1WsPvmkLwNjb1wf5NET6FRivtRNqK54XFMtUG P9aazaESbrAVJ3rxhHHVCSkQ00Q33oYi2orO8mn6T2LkjDYUXOnFfpMJW0zbheqodr5Z x9XvzW3n7Vx3Ud3s79zxSGAT3oJDq9iHWM03fVvadyHaaliKWdfqS0V7hKs+QQ/q1zGD Tmlw== Received: by 10.182.127.102 with SMTP id nf6mr9863983obb.14.1353301602889; Sun, 18 Nov 2012 21:06:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.111.99 with HTTP; Sun, 18 Nov 2012 21:06:22 -0800 (PST) In-Reply-To: <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> From: Lorenzo Colitti Date: Sun, 18 Nov 2012 21:06:22 -0800 Message-ID: To: Jouni Content-Type: multipart/alternative; boundary=14dae93b5dec506e6104ced215bd X-Gm-Message-State: ALoCoQmEjP/hfaaMJWHVuit0C/plzMrtsRDrPfUbaxdNREvkdQCRyfXvCffzjkWS8XrTd/YWUqw3nkTXEv70noiCDw0VcXPZYDdZ+U+RNmxJ74XQOmb8u+ut7s3GFcOqWtqoPn7HEF4hQC/t6GgjuAsZtcO3wudl5qCdEnaDYBmKlN+s7J3QkTQEYLSz1ln0nygOTBw0HEL8 Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 05:06:44 -0000 --14dae93b5dec506e6104ced215bd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 15, 2012 at 7:39 AM, Jouni wrote: > My recollection was that overlaps were supposed to be removed and then > concentrate on the remaining part in draft-binet-v6ops-*, no? This would > concern requirements #1, #6, #7, #8, #9, #17, #22, #23, #25, #26, #27. My > recommendation would be removing those and just reference to > [draft-ietf-v6ops-rfc3316bis] because the base IPv6 compliancy would come > from there and I see no reason to repeat those here. > That's what I remember from the meeting as well. --14dae93b5dec506e6104ced215bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu= , Nov 15, 2012 at 7:39 AM, Jouni <jouni.nospam@gmail.com> wrote:
My recollection w= as that overlaps were supposed to be removed and then concentrate on the re= maining part in draft-binet-v6ops-*, no? This would concern requirements #1= , #6, #7, #8, #9, #17, #22, #23, #25, #26, #27. My recommendation would be = removing those and just reference to [draft-ietf-v6ops-rfc3316bis] because = the base IPv6 compliancy would come from there and I see no reason to repea= t those here.

That's what I remember from the meetin= g as well.
--14dae93b5dec506e6104ced215bd-- From joelja@bogus.com Sun Nov 18 21:08:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2F21F8462 for ; Sun, 18 Nov 2012 21:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIVmYzvXderw for ; Sun, 18 Nov 2012 21:08:38 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 213B621F8459 for ; Sun, 18 Nov 2012 21:08:38 -0800 (PST) Received: from joels-MacBook-Air.local (33.sub-70-199-70.myvzw.com [70.199.70.33]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAJ58aha018077 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 19 Nov 2012 05:08:37 GMT (envelope-from joelja@bogus.com) Message-ID: <50A9BECE.8040203@bogus.com> Date: Sun, 18 Nov 2012 21:08:30 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: multipart/mixed; boundary="------------050209000500080805070107" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 19 Nov 2012 05:08:37 +0000 (UTC) Subject: [v6ops] Draft minutes from IETF 85 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 05:08:39 -0000 This is a multi-part message in MIME format. --------------050209000500080805070107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached. --------------050209000500080805070107 Content-Type: text/plain; charset=UTF-8; name="ietf85-v6ops-notes.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ietf85-v6ops-notes.txt" IETF 85 V6ops thursday 1300 4 hour session, 10 minute break at hour 2 - Note Well - Document status three in Ron's queue three in rfc editor queue - agenda bash 11 documents on our agenda one doc from dhc that will be discussed here 1. Sharing /64 3GPP Mobile Interface Subnet to a LAN http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-3.pdf cameron b - presented Lorenzo C - support, this work because the upstream is point-to-point Cameron B - specifically scope to 3gpp? Alex B - question of interoperability Jonne S - we think is is good document Keith M - this is way batter than nat. Eric K - what happens when the 3gpp context goes away. should be tightly coupled with ra timingi Bechet S - is this a standard tethering case? Joel J - Be careful around prefix size discussion Fred B - taking a quick hum. Several people want this as a working group draft. hum in favor (substantial) hum opposed (none) 2. NAT64 Operational Experiences 8-Aug-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-8.pdf gang c - presented Philip M - change title consistent with other documents change to deployment considerations rather than operational consideration Fred B - you have another version coming - we'll take comments on that and if it looks resvolved perahps take it to WGLC 3. Enterprise IPv6 Deployment Guidelines 15-Sep-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-9.pdf Lee h - presented -questions for the working group MTU size recomendations? Bechet S - 1500 Fred T - can't necessarily if there are two tunnels Fred B - would hesitant to set the mtu to low 2460 says minimum is 1280 Eric K - tests with large operators have more to do with avoiding fragments and less to do with available mtu Enterprise interest in deploying native? Lorenzo C - If you take out native the statement is meaningless. Keith M - Try to think of a reason why an enterprise would not deploy v6. Dual stack, where you can tunnel when you must? Alain D - Disagree with that statement. Fred B - Be careful with the arguement, I can never turn off v4. Keith M - Native support for v 6 is better than any transition. Brian C - It's important not to frighten network operators. Prefix size for a site? you may want to allocate less than a 48 Lorenzo C- Structure of rir assignment allows reader to reach this own conclusions. PI vs PA Philip M - do you want to multihome? Dan Y - +1 to these comments about including something about PI more in the context of multihoming Eric V - A firm with a network team? Victor K - these are considerations about routing implications Bob Hinden - not so bothered by the size issue Slide us NPT66 Fred B - provides no security whatsoever. if you're going to say that you have to address that you need to address ilnp Lorenzo C- my sense is that it's not widely deployed so you may have breakage Lee H - I think I have my answer of no consensus Tim C - do we consider SeND dead? 4. Internet Protocol Version 6 (IPv6) for Cellular Hosts 5-Oct-12, http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-4.pdf Fred B - we're going to discuss both documents and what we should do with them Eric K - requirement 17. Don't do DAD. 5. IPv6 for 3GPP Cellular Hosts 14-Oct-12, http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-7.pptx ? - will this conform to 3gpp specs? Jouni K - Uses non-normative language. Fred B - Let me have a little different discussion - try to figure out what v6ops wants to do in this area. Two sets of authors that belive this needs to be updated. Bob H − 6man updated the node requirements. Fred B - Hum do we agree that 3316 needs to be updated? Fred B - Do we want to have a working group document Lorenzo C - Doc 1 is a shopping list document 2 is a treatis on how you implment ipv6 on 3316. they're not covering the same domain Jouni K - Agree with Lorenzo - different objectives so they need to be treated differently Fred B - Thinking on my feet, lets talk about the first document. It's coming from a set of operators, do you find it useful in your environment? Eric K - How much of the first document would be left after the second document? Jonne S - The first one is operator requirments - 2nds one says this is how it should work . there is some confusion in the industry. Jouni K - With most of comments. first one goes beyond whats required from the current ietf or 3gpp specifications. Jari A - My motivation, we need to keep our specifications up to date. On the first doc, questions as to where it should be done? 3gpp transition mechnanisms where should that work be done. Bechet S - both of them are called 3316 update Gang C - At first I agreed they're complementary, I guess 3gpp they produced a technical report not a standard. Lorenzo C - Need to harmonize with new host requirements lets make a decision on the second one as a natural update of 3316. If we come to consensus on that as update, then we take the first document and add the chrome wheels and the spoiler. Fred B - Calling the question, we wanted to update 3316 is this document (2nd) 3316 update? hum(some) none opposed. Yes, we'll take you up on the offer for the resubmission of the 1st document with a new title 6. A Larger Loopback Prefix for IPv6 17-Aug-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-11.pdf Presented by chairs. Brian C - 1:: is virgin space Fred B - Do we fell that a large loopback is useful? Hum - some in favor some opposed 7. Design Guidelines for IPv6 Networks 22-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-6.ppt slide mix ipv6 and ipv4 Tony H - option a is braindead slide mix ipv6 and ipv4 Fred B - assume you've read michale behringers lla only draft? Philip M - I have slide - one or two ebgp sessions Rudiger V - less fate sharing in option b. ? - amsix considering option a new topic - seperate rrs for v4 and v6 Gunter V - As a pro for seperate is avoid v4 breaking v6 stuff Lorenzo C - Pption a has the advantage that the ops guys know where to look. Fred B - We're pretty close. K K C - I like the document Philip M - Would like to look at vpns, opsf vs isis Tim C - Will try again on address plan after this. Fred B - wg yes or no? (hum) some in favor none opposed resubmitt as draft ietf. 8. IPv6 Operational Guidelines for Datacenters 20-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-5.pptx Fred B - comments ? let me ask this working group a question? do you like the direction? Dan Y - Yes Fred B - Hum: yes? none in room for take it up bake for longer. Philip Mathews - align DC and Enterprise message? 9. IPv6 Transition Technologies Selection using DHCP/DHCPv6 15-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-1.pptx Wes G - wearing my sunset4 co-chair hat - this is a bigger issue than just around which IPv6 transition technology to choose. We've been discussing in sunset4 the need for a means to signal preference between IPv4 and IPv6 under the assumption that there will be multiple permutations of networks: some that offer IPv4 with or without NAT, IPv6, IPv6 with NAT64 and DNS64, DNS servers that only listen on IPv4, only on IPv6, or both such that happy eyeballs by itself may not make the right decision. I'd rather see us solve this problem of conveying preference based on the network's capabilities and offered translation services once, rather than multiple times for multiple use cases. Tony H - The focus has been completely myopic and biased toward lethargic network operators that want to tell the device what to do. there needs to be input from the applications side as well that balances the reality so that networks don't preclude deployment of applications that people actually use. As for the topic of focusing on dhcp, the problem statement appears to be broken in that it requires adding a new option to resolve the problem of inconsistency in current implementations. Philip M - we've identified that there is a gap. Fred B - it is fair to say there's limited support for this? 10. Why Operators Filter Fragments and What It Implies 15-Oct-12 , Why Operators Filter Fragments and What It Implies Joel J - fragment dropping is a different issue than breaking PMTU, goal is to document practice not define rational Ron B - document practice, maybe the why, maybe if the why's are valid documenting this tells folks that fragments are less reliable Brian C - no data in document, having that would be good RIPE study is quoted - 10% of paths drop fragments could use more specific/granular data Tony H - This is a time sensitive issue in that 15 years from now what constitutes a fragment is likely to be different. There is no justification for dropping them in IPv6. In IPv4 overlaps were valid, so there was an attack vector to protect against. THat is no longer true, so we shoudl document why the concept needs to go away. Lorenzo C - we filter fragments and have good reasons / we can; document problem, document reasons, document advice / advice won't work because we won't agree / reasons is out / as an ops group we have a duty to report what happens to others. Ron B: more information would be good DNS impacts? documenting the problem is good but looking for consensus on recomendations is better / can we solve the ops issues Joel J - educational problem Igor G - we fragment, we have reasons / lets document this with basic recomendations to break less Philip M: can those that filter tell us why? Igor G - this is a security issue, details would open attack. 11. Operational Issues with Tunnel Maximum Transmission Unit (MTU) 18-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-0.pptx Ron B - If you had a signaling mechanism you could use it to just send smaller packets. Philip M - need a sense of how common this problem is. Fred B - We know a number of firewalls that does this intentionly or inadvertantly filter path mtu. Fred T - we don't control the wholE path so we can't wire up the mtu. 12. next presentation from dhc wg. http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-12.pdf Eric K - I think this is a good idea Eric V - good thing to do, dhcp is not the right thing. Sheng J - It's frustrsting we bring up this issue in 6man -we have dhcp as a choice, 6man preffered it. Tony H - In general I agree with Eric Kline, but I would prefer to allow the host to at least inform about its preference as to what gets registered in DNS and with the firewall config, because it may only want to allow inbound on one address, which the network can't figure out. Lorenzo C - as a matter of advice, it's in your interest to have consensus. I agree with eric that doing this for security purposes is silly Tim C - you can also use savi Fred B - me speaking as an individual - wheter therre should be registration the protocol to do that is (i asume syslog) etiher dhcpv6 or ipfix Eric K - creating an auditable process Lee H - draft-ietf-dhc-addr-registration Tim C - we use snmp Lorenzo C - there is a use case you can scrape neighbor table - wouldn't be nice that we had a way to do that that was more reliable Meeting is adjurned. --------------050209000500080805070107-- From jiangsheng@huawei.com Sun Nov 18 22:27:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0574521F8471; Sun, 18 Nov 2012 22:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW1GA2T8aoAG; Sun, 18 Nov 2012 22:27:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3321F8616; Sun, 18 Nov 2012 22:27:12 -0800 (PST) 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 AMX65672; Mon, 19 Nov 2012 06:27:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:26:41 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:27:06 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 14:27:01 +0800 From: Sheng Jiang To: Tim Chown , "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxL3VwLXtCQncR0mp9Eo3CReCeZfwsS2w Date: Mon, 19 Nov 2012 06:27:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8EDD8@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: 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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] [dhcwg] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 06:27:14 -0000 Pj4gSSB0aGluayB0aGVyZSBhcmUgYWR2YW50YWdlcyB0byBrZWVwaW5nIHRoZSBtZWNoYW5pc21z IHRvIGNvbGxlY3QNCj5pbmZvcm1hdGlvbg0KPj4gYWJvdXQgaG9zdHMgYW5kIHRoZWlyIGFkZHJl c3NlcyBpbmRlcGVuZGVudCBvZiBob3cgdGhvc2UgYWRkcmVzc2VzIGFyZQ0KPj4gYXNzaWduZWQg b3IgZGVyaXZlZC4NCj4NCj5JIHRoaW5rIHRoaXMgaXMgYSBmYWlyIHBvaW50Lg0KDQpUaW0gYW5k IE1hcmssDQoNCkFsdGhvdWdoIHdlIHVzZWQgREhDUHY2IHByb3RvY29sIHRvIGNhcnJ5IHRoZSBh ZGRyIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbi4gVGhlIHByb2NlZHVyZSBpcyBub3QgbmVjZXNz YXJ5IHRvIGJlIG1peGVkIHdpdGggdGhlIHdheSB0aG9zZSBhZGRyZXNzZXMgYXJlIGFzc2lnbmVk IG9yIGRlcml2ZWQuIFRoZXkgYXJlIGluZGVwZW5kZW50IG9wZXJhdGlvbnMuDQoNCj5JIGFsc28g Y2FuJ3QgaGVscCBidXQgdGhpbmsgdGhhdCB0aGVyZSBpcyBsaWtlbHkgdG8gYmUgc29tZSBvdmVy bGFwIGJldHdlZW4gd2hhdA0KPnRoaXMgZHJhZnQgaXMgdHJ5aW5nIHRvIGRvLCBhbmQgd2hhdCB3 ZSBtaWdodCBlbmQgdXAgd2l0aCBhcyBhIHJlc3VsdCBvZiB0aGUNCj5ob21lbmV0IGFuZC9vciBt ZG5zZXh0IHdvcmsgaW4gZXh0ZW5kaW5nIHplcm9jb25mIG1ldGhvZHMgdG8gaG9tZSBhbmQNCj5l bnRlcnByaXNlL2NhbXB1cyBuZXR3b3Jrcy4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBz aG91bGQgbWFrZSB3YXkgdG8gZnV0dXJlIHdvcmsgd2hpY2ggaGFzIG5vdCBoYXBwZW4geWV0LiBU aGV5IG1heSB1c2Ugb3VyIG91dHB1dCBpZiB0aGVyZSBpcyBvdmVybGFwLg0KDQo+U2ltcGx5IGZv ciBhZGRyZXNzIHVzYWdlIHRyYWNraW5nLCB3ZSd2ZSBmb3VuZCBpdCBzdWZmaWNpZW50IHRvIHJ1 biB0b29scyB0aGF0DQo+cG9sbCB0aGUgc3dpdGNoL3JvdXRlciBpbmZyYXN0cnVjdHVyZS4gV2Ug ZG8gdGhhdCBvbiBhIGNhbXB1cyB1c2luZyBvcGVuDQo+c291cmNlIHRvb2xzIGFuZCBpdCB3b3Jr cyBqdXN0IGZpbmUsIHByb3ZpZGVkIHRoZSBwb2xsaW5nIGlzIGNvbmZpZ3VyZWQgdG8gdGFrZQ0K PmludG8gYWNjb3VudCB0aGUgZXhwaXJhdGlvbiB0aW1lcnMgb2YgdGhlIGRhdGEgYmVpbmcgZ2F0 aGVyZWQgZnJvbSB0aGUNCj5kZXZpY2VzLiBXaGVyZSB0aGUgdG9vbCBpcyBhbHNvIGF3YXJlIG9m IHRoZSBhbGwgdGhlIG5ldHdvcmsgZGV2aWNlcywgdGhlaXINCj5jb25uZWN0aXZpdHksIHByZWZp eCBhbGxvY2F0aW9ucywgVkxBTnMsIHN3aXRjaCBwb3J0IGNvbmZpZ3VyYXRpb25zLCBldGMsIHRo ZW4NCj55b3UgaGF2ZSBwcmV0dHkgbXVjaCBhbGwgeW91IG5lZWQgZm9yIGFjY291bnRhYmlsaXR5 LiBXZSBhbHNvIHVzZSA4MDIuMVggZm9yDQo+d2lyZWxlc3MgKGVkdXJvYW0pIGFuZCBhcmUgYmVn aW5uaW5nIHRvIHVzZSBpdCBmb3Igd2lyZWQgcG9ydHMgYXMgd2VsbC4NCg0KSSBoYXZlIG5vIGRv dWJ0IHRvb2xzIHdpdGggdGhlaXIgcHJpdmF0ZSBwcm90b2NvbCBjYW4gY29tcGxldGUgdGhlIHdv cmsgdG9vLiBIZXJlLCB3ZSBhcmUgdHJ5aW5nIHRvIHVzZSBhIHN0YW5kYXJkIHByb3RvY29sIHRv IGNhcnJ5IHRoZSBpbmZvcm1hdGlvbi4gVGhpcyB3b3VsZCBhbHNvIGJlbmVmaXQgZm9yIHZhcmlv dXMgaW1wbGVtZW50YXRpb25zLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5JJ3ZlIG5v dCBsb29rZWQgYXQgRmVybmFuZG8ncyB0b29sLiBJIHdvdWxkIGFzc3VtZSBpdCBhY2hpZXZlcyB0 aGUgc2FtZSB0aGluZw0KPmluIHRlcm1zIG9mIGFkZHJlc3MgdHJhY2tpbmcsIGJ1dCBJJ2QgYXJn dWUgdGhhdCBpbnRlZ3JhdGluZyB0aGUgcG9sbGluZy90cmFja2luZw0KPndpdGggbmV0d29yayBt b25pdG9yaW5nL21hbmFnZW1lbnQgdG9vbHMgdGhhdCBoYXZlIHRoZSAnYmlnZ2VyIHBpY3R1cmUn IGlzDQo+YWR2YW50YWdlb3VzLg0KPg0KPlRpbQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From jiangsheng@huawei.com Sun Nov 18 22:59:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E58321F862B; Sun, 18 Nov 2012 22:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpZIVoHEWqxP; Sun, 18 Nov 2012 22:59:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3434D21F8706; Sun, 18 Nov 2012 22:59:22 -0800 (PST) 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 AMX68527; Mon, 19 Nov 2012 06:59:18 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:58:55 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:59:17 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 14:59:09 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxgP73Bu344hO/0adTOoIrKqbXZfwuOHA Date: Mon, 19 Nov 2012 06:59:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8EE40@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [v6ops] [dhcwg] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 06:59:23 -0000 Pj4gRm9yIG1lLCByb3V0ZXItYmFzZWQgYWRkciByZWdpc3RyYXRpb24gbWF5IG5lZWQgYW5vdGhl ciBkZWRpY2F0ZWQgZHJhZnQuDQo+PkFsdGhvdWdoIGN1cnJlbnQgSUEgY2FuIHdvcmsgb3V0LCBh IG5ldyBESENQIG9wdGlvbiB0aGF0IHN1cHBvcnQgYnVsayBhZGRyDQo+PnJlZ2lzdHJhdGlvbiBt YXkgYmUgbW9yZSBlZmZpY2llbnQgdGhhbiBvbmUgYWRkciBwZXIgdGltZS4gV2hhdCdzIHlvdXIN Cj4+b3Bpbmlvbj8NCj4NCj5JIHRoaW5rIHRoYXQgYnVsayByZWdpc3RyYXRpb24gd29uJ3Qgd29y ayBiZWNhdXNlIGhvc3RzIGFyZW4ndCBkaXNjb3ZlcmVkIGFsbCBhdA0KPnRoZSBzYW1lIHRpbWU7 IGVpdGhlciB0aGUgcm91dGVyIHdhaXRzIHVudGlsIGl0J3MgYWNjdW11bGF0ZWQgZW5vdWdoIHRv IGZpbGwgYQ0KPnBhY2tldCwgb3IgaXQgc2VuZHMgYW4gdXBkYXRlIGVhY2ggdGltZSBpdCBkaXNj b3ZlcnMgYSBuZXcgb25lLg0KDQpNYWtlIHNlbnNlLiBTbywgd2Ugd2lsbCBleHBhbmQgdGhlIGN1 cnJlbnQgYWRkciByZWdpc3RyYXRpb24gdG8gYmUgY2xpZW50LWJhc2VkIG1vZGVsLCBpbiB3aGlj aCB0aGUgY2xpZW50IG1heWJlIHJvdXRlci4NCg0KU2hlbmcNCg== From mohamed.boucadair@orange.com Sun Nov 18 23:30:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB521F8646 for ; Sun, 18 Nov 2012 23:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7mEe-OW11bc for ; Sun, 18 Nov 2012 23:30:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A4EFA21F85A3 for ; Sun, 18 Nov 2012 23:30:58 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0CEF522C33D; Mon, 19 Nov 2012 08:30:57 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D601727C06A; Mon, 19 Nov 2012 08:30:56 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 19 Nov 2012 08:30:56 +0100 From: To: jouni korhonen Date: Mon, 19 Nov 2012 08:30:55 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 Thread-Index: Ac3FGUiqd4MhM7rpT4KqUGEIumhyrwBDUzwQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E536@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> <6F49F841-FD9E-4996-9C17-245F46C6EABE@gmail.com> In-Reply-To: <6F49F841-FD9E-4996-9C17-245F46C6EABE@gmail.com> 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: 2012.11.19.40315 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Nov 2012 07:30:59 -0000 Hi Jouni, The question of overlapping is not important IMHO as the two documents are = targeting distinct objectives. I thought you agreed with this point (below = an excerpt from the minutes): " Lorenzo C - Doc 1 is a shopping list document 2 is a treatis on how you implment ipv6 on 3316. they're not covering the same domain Jouni K - Agree with Lorenzo - different objectives so they need to be treated differently " If now you are claiming yours is also doing what draft-binet-* does, I'm pu= zzled then... Cheers, Med=20 >-----Message d'origine----- >De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >Envoy=E9 : dimanche 18 novembre 2012 00:14 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : v6ops@ietf.org WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 > > >Hi, > >Likewise rfc3316bis assumes IPv6-only or dual-stack. Point=20 >being, rfc3316bis does not do in direction that is not=20 >necessary to run IPv6 (in a possibly multi interfaced host).=20 >IMHO the rest like NAT related recommendations, transition=20 >recommendations, WLAN specifics, tethering recommendations are=20 >then well served in draft-bonet-*. > >- Jouni > >On Nov 16, 2012, at 3:17 PM, =20 > wrote: > >> Re-, >>=20 >> draft-binet-* assumes both DS and IPv6-only deployment=20 >modes. Nothing specific there. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >>> Envoy=E9 : vendredi 16 novembre 2012 14:09 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : v6ops@ietf.org WG >>> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>>=20 >>>=20 >>> Med, >>>=20 >>> I still see no reason to replicate information since what=20 >>> comes to "a pure IPv6 profile for a 3GPP link", it should be=20 >>> exactly the same in both documents. I am just trying to avoid=20 >>> misalignment now and in the future. I would also argue that=20 >>> draft-binet-* is a profile for a specific deployment(s) in=20 >>> mind, not a generic IPv6 profile for cellular. It is a way=20 >>> more (not that it would be a bad thing though..). >>>=20 >>> - Jouni >>>=20 >>>=20 >>> On Nov 16, 2012, at 2:07 PM, =20 >>> wrote: >>>=20 >>>> Hi Jouni, >>>>=20 >>>> What I understood from the v6ops meeting is that wg=20 >>> participants see these two documents have distinct objectives.=20 >>> As such the question of overlapping does not apply as these=20 >>> documents serve two distinct objectives. Furthermore, because=20 >>> draft-binet-*'s objective is to define an IPv6 profile for=20 >>> cellular, we prefer the document be self-contained and use=20 >>> consistent language for all requirements. >>>>=20 >>>> Cheers, >>>> Med=20 >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Jouni [mailto:jouni.nospam@gmail.com]=20 >>>>> Envoy=E9 : jeudi 15 novembre 2012 16:40 >>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>>> Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >>>>> Objet : Re: [v6ops]=20 >draft-binet-v6ops-cellular-host-requirements-01 >>>>>=20 >>>>>=20 >>>>> Med, >>>>>=20 >>>>> I am slightly confused about the overlap of=20 >>>>> draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >>>>> recollection was that overlaps were supposed to be removed and=20 >>>>> then concentrate on the remaining part in draft-binet-v6ops-*,=20 >>>>> no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >>>>> #22, #23, #25, #26, #27. My recommendation would be removing=20 >>>>> those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >>>>> because the base IPv6 compliancy would come from there and I=20 >>>>> see no reason to repeat those here. >>>>>=20 >>>>> Then a question about the relevance of #24. Given the current=20 >>>>> bandwidth in 3G/LTE is there really a need to compress=20 >>>>> headers? And if people really see it as a life critical=20 >>>>> feature to have, I would appreciate listing the ROHC profiles=20 >>>>> that are essential (e.g., align with IR.92 & IR.58 that will=20 >>>>> be implemented on the network side). >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>> On Nov 15, 2012, at 4:59 PM, =20 >>>>> wrote: >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> We submitted a new version of the draft to take into account=20 >>>>> the comments received from M. Abrahamsson and P. Vickers. >>>>>>=20 >>>>>> The main changes are: >>>>>>=20 >>>>>> * Add some clarification text for REQ#3 >>>>>> * Mention stateless dhcpv6 is useful to retrieve other=20 >>>>> information than DNS >>>>>> * Re-word REQ#15 >>>>>> * Cite "Happy Eyeballs" in REQ#16 >>>>>> * Update the text of REQ#17 >>>>>> * Add two sub-requirements to REQ#19: IPv6-only=20 >>> connectivity + SLAAC >>>>>> * Precise the ordering in REQ#21 >>>>>>=20 >>>>>> A more detailed diff is available at: >>>>>>=20 >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>>> t-requirements-01 >>>>>>=20 >>>>>>=20 >>>>>> Chairs, would it be possible to issue a Call For Adoption=20 >>>>> for this document? Thanks. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>> internet-drafts@ietf.org >>>>>> Envoy=E9 : jeudi 15 novembre 2012 15:53 >>>>>> =C0 : i-d-announce@ietf.org >>>>>> Objet : I-D Action:=20 >>>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line=20 >>>>> Internet-Drafts directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : Internet Protocol Version 6 (IPv6)=20 >>>>> Requirements for Cellular Hosts >>>>>> Author(s) : David Binet >>>>>> Mohamed Boucadair >>>>>> Ales Vizdal >>>>>> Cameron Byrne >>>>>> Gang Chen >>>>>> Filename :=20 >>>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>>> Pages : 16 >>>>>> Date : 2012-11-15 >>>>>>=20 >>>>>> Abstract: >>>>>> This document lists a set of IPv6-related requirements to be >>>>>> supported by cellular hosts. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>>=20 >>>>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >>>>> t-requirements >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>>=20 >>>>> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >>>>> irements-01 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>>=20 >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>>> t-requirements-01 >>>>>>=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 >>>>>=20 >>>=20 > >= From lorenzo@google.com Mon Nov 19 00:39:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C6521F8488 for ; Mon, 19 Nov 2012 00:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aOSH4am3Znn for ; Mon, 19 Nov 2012 00:39:50 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5EAC21F847C for ; Mon, 19 Nov 2012 00:39:49 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so4957367obb.31 for ; Mon, 19 Nov 2012 00:39:49 -0800 (PST) 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=xl5VjbWqkzVNhQ0ugtiPjiaM20fg50t1Rv2oPpGxHC4=; b=GBHG8InnwrdXIe400l5dSz6ybI5c2v7WYxPK7oLQhihCkhLJSrjnDcANy6mzVF9J5Y JW+eX/O2FLgh7VHtUR+7JsokbAahXccJUPbDd2EqvHwRZ/MpCw9i4r0gHNtEqH6n3jdK LsxPAcoHxV4APYCBSbvxcT4Jd/KbgZxfUGgk0P9jy93uKXV+H1n0KxbxTJoOj00VToMy rUGAbNjP+teYH9QyOGhTcLsTB58+S18l2zDyA4Uap7E1CpYIHcNAZx3VsmCKTPMaCPjz KTC5ZTsc9g6Dnwxk28Y/I+PpM05Oi3+D7C7uWticjoi/d9zw576wOtZ6y48HOJq6Vk5O +Stw== 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=xl5VjbWqkzVNhQ0ugtiPjiaM20fg50t1Rv2oPpGxHC4=; b=Xzsl5/A3+ZmIWtB1CUj00tB4p3OxmRMp5LhktN79U8aMTGJRluTbSxKeWtMGmr0VYR QxpwuRr6EigxXo95Yh4soCmtsviGgd1WrY5NNCoJHuMm8CWOYgDyjn06VeF5scUwjB3T ATxE1+SsE8n7ojkuWgDXTNXUErn+PhhkLLaWUZ25BhL2z2/7P0pWHE1yLeW3374x0KJ1 z87LKDdDW9I6284i6KXZ98UFy0QXpTgO6X1D8MVL90Teh8Yqv1gB7NIblORVGSn0W8Ng DyTi1W/RMOydCs442kaK6+w2IloFQquK80wGCDrls7O9CM1DXXLeOhL/IMo5ETJ1XGCJ hdCQ== Received: by 10.60.32.135 with SMTP id j7mr9619415oei.132.1353314389062; Mon, 19 Nov 2012 00:39:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 00:39:28 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Mon, 19 Nov 2012 17:39:28 +0900 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=e89a8fb1f8266df2d904ced50fdd X-Gm-Message-State: ALoCoQkgn6LMkHx1UT1neOi2dz4zM+FVvQvEgNdUtZ0ZpTm86Vh8myRnj3G+cIKT5AE7VOGBp/QQ3ODEGhJL96ZI71+raqspMgfCNX2+7pUXkL7U/HoTvqSVIruF/3emgLivlXLugch1FecJQbRMk6eKHrX7uuCanPn8cf1Og1S/rS5w/zgOTTvOmw01xzfnEHiCDcNKGlIq Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 08:39:50 -0000 --e89a8fb1f8266df2d904ced50fdd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not think this document is ready for WG adoption. To start with, I see a few general issues. First, the document is attempting to standardize behaviours that are already standardized by 3GPP. This is leads to many of the requirements being redundant because they are already included in 3GPP specs. If the manufacturer is violating those specs already, I doubt that an RFC that says "don't violate those specs" is going to have any effect at all. This also presents the problem that if the 3GPP standards are updated, the text becomes out of date. Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF. Third, IETF work is supposed to proceed in parallel with running code, not in the absence of running code. I very doubt there are two interoperable implementations that satisfy all these requirements (actually, I doubt that any real implementation satisfies even half of them). Attempting to specify these requirements will not change that. Moving on, at least these requirements are redundant and should be removed or replaced by a reference to the appropriate specs: REQ#3: Redundant with 3GPP specs. REQ#4: Redundant with 3GPP specs. REQ#5: Redundant with 3GPP specs. REQ#6: Redundant with IPv6 node requirements. REQ#7: Redundant with IPv6 node requirements. REQ#7: Redundant with IPv6 node requirements and 3GPP specs. REQ#15: Redundant with RFC 6724. REQ#17: Redundant with 3GPP specs. A few specific comments as well: REQ#1: why do you need to cite RFC 5952? It has nothing to do with connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node Requirements). REQ#10: Not clear what happens if more than one provisioning method provides DNS. Should the phone just information from one of them? Or should it list all of them in priority order? REQ#11: Not clear to me what this means. I understand the "implement the NAT64 discovery heuristic" requirement, but not the part that references RFC 6052. What does the host need to implement from RFC 6052? REQ#18: Meaningless. Saying "MAY" in a requirements document is no better than saying nothing. REQ#25: What is the point of supporting RFC 5175 if it defines no new flags= ? REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a number of years? REQ#28: Duplicate of #12. On Sun, Nov 11, 2012 at 10:47 PM, wrote: > Dear all, > > As discussed in the v6ops meeting, we re-submitted a new version of the > text which does not update RFC3316. > > We hope this new version is ready for the WG adoption. > > Cheers, > Med > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > De la part de internet-drafts@ietf.org > Envoy=E9 : lundi 12 novembre 2012 07:42 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Internet Protocol Version 6 (IPv6) Requirements > for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : > draft-binet-v6ops-cellular-host-requirements-00.txt > Pages : 15 > Date : 2012-11-11 > > Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirem= ents > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-0= 0 > > > 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-Draftdirectories: > 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 > --e89a8fb1f8266df2d904ced50fdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I= do not think this document is ready for WG adoption.

<= div>To start with, I see a few general issues.

First, the document is attempting to standardize behaviours that are alread= y standardized by 3GPP. This is leads to many of the requirements being red= undant because they are already included in 3GPP specs. If the manufacturer= is violating those specs already, I doubt that an RFC that says "don&= #39;t violate those specs" is going to have any effect at all. This al= so presents the problem that if the 3GPP standards are updated, the text be= comes out of date.

Second, most of this document attempts to standard= ize feature sets, not protocols or interoperability. I'm not sure this = is is in scope for the IETF, and even more so for an operations group insid= e the IETF.

Third, IETF work is supposed to proceed in parallel wit= h running code, not in the absence of running code. I very doubt there are = two interoperable implementations that satisfy all these requirements (actu= ally, I doubt that any real implementation satisfies even half of them). At= tempting to specify these requirements will not change that.


Moving on, at least these requirements a= re redundant and should be removed or replaced by a reference to the approp= riate specs:

REQ#3: Redundant with= 3GPP specs.=A0
REQ#4: Redundant with 3GPP specs.=A0
REQ#5: Redundant with 3= GPP specs.=A0
REQ#6: Redundant with IPv6=A0node=A0requirements.
REQ#7: Redundant with IPv6=A0node=A0requirements.
REQ#7:= Redundant with IPv6 node requirements and 3GPP specs.
REQ#15: Redundant with RFC 6724.
REQ#17: Redundan= t with 3GPP specs.


A few spec= ific comments as well:

REQ#1: why do you need to c= ite RFC 5952? It has nothing to do with connecting to cellular networks, an= d it's already in RFC 6434 (IPv6 Node Requirements).

REQ#10: Not clear what happens if more = than one provisioning method provides DNS. Should the phone just informatio= n from one of them? Or should it list all of them in priority order?

REQ#11: Not clear to me what this means. I understand t= he "implement the NAT64 discovery heuristic" requirement, but not= the part that references RFC 6052. What does the host need to implement fr= om RFC 6052?

REQ#18: Meaningless. Saying "MAY" in a = requirements document is no better than saying nothing.

REQ#25: What is the point of supporting RFC 5175 if it defines no new= flags?

REQ#27: Why support DHCPv6 PD if no mobile networks wil= l support it for a number of years?

REQ#28: Duplic= ate of #12.

On Sun, Nov 11, 2012 at 10:47 PM, <= mohamed.boucadair@orange.com> wrote:
Dear all,

As discussed in the v6ops meeting, we re-submitted a new version of the tex= t which does not update RFC3316.

We hope this new version is ready for the WG adoption.

Cheers,
Med

-----Message d'origine-----
De : i-d= -announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la par= t de internet= -drafts@ietf.org
Envoy=E9 : lundi 12 novembre 2012 07:42
=C0 : i-d-announ= ce@ietf.org
Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Internet Protocol Version 6 (IP= v6) Requirements for Cellular Hosts
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : David Binet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mohamed Boucadair
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ales Vizdal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gang Chen
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-binet-v6ops-cellular-host-r= equirements-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 15
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-11-11

Abstract:
=A0 =A0This document lists a set of IPv6-related requirements to be
=A0 =A0supported by cellular hosts.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bin= et-v6ops-cellular-host-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-binet-v6ops-= cellular-host-requirements-00


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8fb1f8266df2d904ced50fdd-- From david.binet@orange.com Mon Nov 19 01:57:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14E21F855F for ; Mon, 19 Nov 2012 01:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EiTZvrISIKX for ; Mon, 19 Nov 2012 01:57:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5682A21F855E for ; Mon, 19 Nov 2012 01:57:08 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 05A432DC14F; Mon, 19 Nov 2012 10:57:07 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D849F238055; Mon, 19 Nov 2012 10:57:06 +0100 (CET) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 19 Nov 2012 10:57:03 +0100 From: To: Lorenzo Colitti , BOUCADAIR Mohamed OLNC/OLN Date: Mon, 19 Nov 2012 10:57:01 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3GMYUvxrpmznGoR7q+NI9HqqPtuQACMCwg Message-ID: <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7BPUEXCB1Anante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.19.91518 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 09:57:10 -0000 --_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7BPUEXCB1Anante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Some answers inline ________________________________ De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de L= orenzo Colitti Envoy=E9 : lundi 19 novembre 2012 09:39 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt I do not think this document is ready for WG adoption. To start with, I see a few general issues. First, the document is attempting to standardize behaviours that are alread= y standardized by 3GPP. This is leads to many of the requirements being red= undant because they are already included in 3GPP specs. If the manufacturer= is violating those specs already, I doubt that an RFC that says "don't vio= late those specs" is going to have any effect at all. This also presents th= e problem that if the 3GPP standards are updated, the text becomes out of d= ate. [[david]] The goal of this document as indicated in several messages is to = get a document where all IPv6 specifications for a mobile terminal are pres= ent. Actually it happens quite often that IETF documents have to be updated= because of standards modifications and it is even the case for RFC3316. And I do not understand the comment about the need to remove some requireme= nts and to provide a link to RFC3316bis document. I do not understand why a= RFCbis draft was proposed if the specifications were already present in dr= aft-binet-* document. Second, most of this document attempts to standardize feature sets, not pro= tocols or interoperability. I'm not sure this is is in scope for the IETF, = and even more so for an operations group inside the IETF. [[david]] It is your opinion but as operator, it is something which is very= important and there is a lack in standardisation documents where some IPv6= profile is defined. We receive a lot of support about such specifications. Third, IETF work is supposed to proceed in parallel with running code, not = in the absence of running code. I very doubt there are two interoperable im= plementations that satisfy all these requirements (actually, I doubt that a= ny real implementation satisfies even half of them). Attempting to specify = these requirements will not change that. [[david]] You are right and we can imagine there is no implementation becau= se there are no clear specifications and it is the gap we are trying to fil= l thanks to this document. If this document becomes a working group documen= t, it amy be a first step in the process to get more and more IPv6 terminal= s and to lead some interoperable implementations. At this stage, the goal i= s to consider this document as a working group document. I think we can dis= cuss about your specific comments below (even if I provided a global commen= t about some of them upper in the mail) when the document will be considere= d as a working group document. Moving on, at least these requirements are redundant and should be removed = or replaced by a reference to the appropriate specs: REQ#3: Redundant with 3GPP specs. REQ#4: Redundant with 3GPP specs. REQ#5: Redundant with 3GPP specs. REQ#6: Redundant with IPv6 node requirements. REQ#7: Redundant with IPv6 node requirements. REQ#7: Redundant with IPv6 node requirements and 3GPP specs. REQ#15: Redundant with RFC 6724. REQ#17: Redundant with 3GPP specs. A few specific comments as well: REQ#1: why do you need to cite RFC 5952? It has nothing to do with connecti= ng to cellular networks, and it's already in RFC 6434 (IPv6 Node Requiremen= ts). REQ#10: Not clear what happens if more than one provisioning method provide= s DNS. Should the phone just information from one of them? Or should it lis= t all of them in priority order? REQ#11: Not clear to me what this means. I understand the "implement the NA= T64 discovery heuristic" requirement, but not the part that references RFC = 6052. What does the host need to implement from RFC 6052? REQ#18: Meaningless. Saying "MAY" in a requirements document is no better t= han saying nothing. REQ#25: What is the point of supporting RFC 5175 if it defines no new flags? REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a n= umber of years? REQ#28: Duplicate of #12. On Sun, Nov 11, 2012 at 10:47 PM, > wrote: Dear all, As discussed in the v6ops meeting, we re-submitted a new version of the tex= t which does not update RFC3316. We hope this new version is ready for the WG adoption. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [m= ailto:i-d-announce-bounces@ietf.org] = De la part de internet-drafts@ietf.org Envoy=E9 : lundi 12 novembre 2012 07:42 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Internet Protocol Version 6 (IPv6) Requirements f= or Cellular Hosts Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-binet-v6ops-cellular-host-requirements-00.t= xt Pages : 15 Date : 2012-11-11 Abstract: This document lists a set of IPv6-related requirements to be supported by cellular hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7BPUEXCB1Anante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Some answers inline

De : v6ops-bounces@ietf.org=20 [mailto:v6ops-bounces@ietf.org] De la part de Lorenzo=20 Colitti
Envoy=E9 : lundi 19 novembre 2012=20 09:39
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc := IPv6=20 Ops WG
Objet : Re: [v6ops]=20 draft-binet-v6ops-cellular-host-requirements-00.txt

I do not think this document is ready for WG adoption.

To start with, I see a few general issues.

First, the document is attempting to standardize behaviours that are= =20 already standardized by 3GPP. This is leads to many of the requirements b= eing=20 redundant because they are already included in 3GPP specs. If the manufac= turer=20 is violating those specs already, I doubt that an RFC that says "don't vi= olate=20 those specs" is going to have any effect at all. This also presents the= =20 problem that if the 3GPP standards are updated, the text becomes out of= =20 date.
[[david]]=  The=20 goal of this document as indicated in several messages is to get a= =20 document where all IPv6 specifications for a mobile terminal ar= e=20 present. Actually it happens quite often that IETF documents have to= be=20 updated because of standards modifications and it is even the case f= or=20 RFC3316.   
And I do not= =20 understand the comment about the need to remove some requirements and to= =20 provide a link to RFC3316bis document. I do not understand why a RFC= bis=20 draft was proposed if the specifications were already present in draft-bi= net-*=20 document.  

Second, most of this document attempts to standardize feature sets, = not=20 protocols or interoperability. I'm not sure this is is in scope for the I= ETF,=20 and even more so for an operations group inside the IETF.
[[david]] It is you= r opinion=20 but as operator, it is something which is very important and there i= s a=20 lack in standardisation documents where some IPv6 profile is defined. We= =20 receive a lot of support about such specifications.=20  

Third, IETF work is supposed to proceed in parallel with running cod= e,=20 not in the absence of running code. I very doubt there are two interopera= ble=20 implementations that satisfy all these requirements (actually, I doubt th= at=20 any real implementation satisfies even half of them). Attempting to speci= fy=20 these requirements will not change that.
[[david]] You are= =20 right and we can imagine there is no implementation because the= re=20 are no clear specifications and it is the gap we are trying to fill thank= s to=20 this document. If this document becomes a working group document, it amy = be a=20 first step in the process to get more and more IPv6 terminals and to lead= some=20 interoperable implementations. At this stage, the goal is to consider thi= s=20 document as a working group document. I think we can discuss about your= =20 specific comments below (even if I provided a global comment about some o= f=20 them upper in the mail) when the document will be considered as a working= =20 group document.


Moving on, at least these requirements are redundant and should be= =20 removed or replaced by a reference to the appropriate specs:

REQ#3: Redundant with 3GPP specs. 
REQ#4: Redundant with 3GPP specs. 
REQ#5: Redundant with 3GPP specs. 
REQ#6: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements and 3GPP specs.
REQ#15: Redundant with RFC 6724.
REQ#17: Redundant with 3GPP specs.


A few specific comments as well:

REQ#1: why do you need to cite RFC 5952? It has nothing to do with= =20 connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node= =20 Requirements).

REQ#10: Not clear what happens if more than one provisioning method= =20 provides DNS. Should the phone just information from one of them? Or shou= ld it=20 list all of them in priority order?

REQ#11: Not clear to me what this means. I understand the "implement= the=20 NAT64 discovery heuristic" requirement, but not the part that references = RFC=20 6052. What does the host need to implement from RFC 6052?

REQ#18: Meaningless. Saying "MAY" in a requirements document is no b= etter=20 than saying nothing.

REQ#25: What is the point of supporting RFC 5175 if it defines no ne= w=20 flags?

REQ#27: Why support DHCPv6 PD if no mobile networks will support it = for a=20 number of years?

REQ#28: Duplicate of #12.

On Sun, Nov 11, 2012 at 10:47 PM, <mohamed.boucadair@orange.com> wrote:
Dear=20 all,

As discussed in the v6ops meeting, we re-submitted a new ve= rsion=20 of the text which does not update RFC3316.

We hope this new vers= ion=20 is ready for the WG adoption.

Cheers,
Med

-----Message= =20 d'origine-----
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org
Envoy=E9 : lundi 12 nov= embre=20 2012 07:42
=C0 : i-d-announce@ietf.org
Objet : I-D Action:=20 draft-binet-v6ops-cellular-host-requirements-00.txt


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


        Title    = =20       : Internet Protocol Version 6 (IPv6) Requirements = for=20 Cellular Hosts
        Author(s)     &= nbsp;=20 : David Binet
               = ;=20           Mohamed Boucadair
    &= nbsp;=20                     A= les=20 Vizdal
                 = ;=20         Cameron Byrne
       = ;=20                   Gang=20 Chen
        Filename        = ;:=20 draft-binet-v6ops-cellular-host-requirements-00.txt
    &n= bsp;=20   Pages           : 15
    &= nbsp;=20   Date            :=20 2012-11-11

Abstract:
   This document lists a set o= f=20 IPv6-related requirements to be
   supported by cellular= =20 hosts.



The IETF datatracker status page for this draft= =20 is:
https://datatracker.ietf.org/doc/draft-binet-v6ops-cell= ular-host-requirements

There's=20 also a htmlized version available at:
http://tools.ietf.org/html/draft-binet-v6ops-cellular-h= ost-requirements-00


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

________= _______________________________________
I-D-Announce=20 mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft=20 directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
______= _________________________________________
v6ops=20 mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

____________________=
___________________________________________________________________________=
__________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7BPUEXCB1Anante_-- From lorenzo@google.com Mon Nov 19 02:03:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB4D21F859D for ; Mon, 19 Nov 2012 02:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuLkKciU4Cf1 for ; Mon, 19 Nov 2012 02:03:39 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1F4321F8551 for ; Mon, 19 Nov 2012 02:03:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5009652oag.31 for ; Mon, 19 Nov 2012 02:03:38 -0800 (PST) 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=SvExfWJQ2XFJlwdbUvwkSz5/5kPsX5EdtN3kE9gYF+o=; b=fu7TrXC6efvoQg+tbaPCFEWdrQcQjTnlFhP+u4nt2y96ua0+gmTvIQrIym347F/4CT PKmO6rWprL08bND4rvyTbncWYdSfA0HJpmA9AUuwSOlPtv2yNKtUKddrByjsqrgwbpP6 BYL9zqC3XSCRAxXrrovpXVJnmdcvW/lAosH0kbzb8K58MeMM1pLf64VHf9h/Nj6/D9E4 F4Hbk/XnUCTWCvevDUDXNu3YQIohLihpSCkJIjGx2J+uIP6HaoRNWZxQiEFSXbwbp4pf Dgvs0o13wnBj4Mquid+xmNcFsP7Kn6adVv4iZPrVjPsYku+LX6D3RzNUj8pPuU5DdUJO tM0g== 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=SvExfWJQ2XFJlwdbUvwkSz5/5kPsX5EdtN3kE9gYF+o=; b=FgCrZSZNzNjPao0EGmNP1PibuixvQKP6jYXaLNjs4NColZGcayBWYzNJMlt+6dN158 8IrVmIEfpMvSugw72GbwI/lTiaRr7IXmyYlVdLmib5Bx1xEL2OruMr9JVHcIOfgLJbfP nAORYZIkvJZRpX4ZjaSe14cSthfHDkKAQZeja3QR4nlc4PAnsrHyh6K3qv/F67FLAl76 pmph2kTZHM/oiF5M5A0m4PwC3JbjEJfD/49taeirGzvOm/uhfXMvMKttRogcqZwMFUgL HTCbje/z/j9EUfamthlPkNKUuCcedIj4ZeuArA9qIFXLQv9IACpVql5ZzgJWu7feqqjf 5lsQ== Received: by 10.60.9.166 with SMTP id a6mr723584oeb.89.1353319418408; Mon, 19 Nov 2012 02:03:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 02:03:18 -0800 (PST) In-Reply-To: <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Mon, 19 Nov 2012 19:03:18 +0900 Message-ID: To: david.binet@orange.com Content-Type: multipart/alternative; boundary=e89a8fb1edfc33adfd04ced63be0 X-Gm-Message-State: ALoCoQldRx35yLaHcJTRUqCPjEmWaiTzXtWAAS/YBDJU2ZZTm5xBbzTeol466Aw86ZeBTvgTpS3KzRlAWFHoSVRBt9TfreyiiQgiT79JXJ00R3vfGLd+6RLjxnpmm8tMBqSaVbjDvYGtGPkhzqBAyZMyNoi8YOtbxMYX+PJOBEta26U4Kro3VQ2W/QoC7Kr2+EdujLNMlSjT Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 10:03:40 -0000 --e89a8fb1edfc33adfd04ced63be0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 19, 2012 at 6:57 PM, wrote: > ** > > And I do not understand the comment about the need to remove some > requirements and to provide a link to RFC3316bis document. I do not > understand why a RFCbis draft was proposed if the specifications were > already present in draft-binet-* document. > > Because that draft properly updates RFC3316. This document does not update RFC3316, it's something completely different. > Second, most of this document attempts to standardize feature sets, not > protocols or interoperability. I'm not sure this is is in scope for the > IETF, and even more so for an operations group inside the IETF. > [[david]] It is your opinion but as operator, it is something which is > very important and there is a lack in standardisation documents where some > IPv6 profile is defined. We receive a lot of support about > such specifications. > > Does the IETF define an IPv4 profile? If not, why not? --e89a8fb1edfc33adfd04ced63be0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon= , Nov 19, 2012 at 6:57 PM, <david.binet@orange.com> wr= ote:
And I d= o not=20 understand the comment about the need to remove some requirements and to= =20 provide a link to RFC3316bis document.=A0I do not understand why a RFCbis= =20 draft was proposed if the specifications were already present in draft-bi= net-*=20 document. =A0
Because that draft properly updates RFC3316. This document does not upda= te RFC3316, it's something completely different.
Second, most of this document attempt= s to standardize feature sets, not=20 protocols or interoperability. I'm not sure this is is in scope for t= he IETF,=20 and even more so for an operations group inside the IETF.
[[david]]=A0It is your opinion=20 but as operator, it is something which is very important and there=A0is a= =20 lack in standardisation documents where some IPv6 profile is defined. We= =20 receive a lot of support about such=A0specifications. =A0 =A0=A0
Does the IETF d= efine an IPv4 profile? If not, why not?
--e89a8fb1edfc33adfd04ced63be0-- From david.binet@orange.com Mon Nov 19 02:30:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5621F8564 for ; Mon, 19 Nov 2012 02:30:51 -0800 (PST) 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.425, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8rVh6OeWKM5 for ; Mon, 19 Nov 2012 02:30:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6757821F849E for ; Mon, 19 Nov 2012 02:30:49 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1F9C018C3F4; Mon, 19 Nov 2012 11:30:49 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D9BDD35C058; Mon, 19 Nov 2012 11:30:48 +0100 (CET) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 19 Nov 2012 11:30:46 +0100 From: To: Lorenzo Colitti Date: Mon, 19 Nov 2012 11:30:45 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3GPSYjHiUrcAQjTxuv+kW78tjtGgAArGOA Message-ID: <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4PUEXCB1Anante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.19.100316 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 10:30:51 -0000 --_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4PUEXCB1Anante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : lundi 19 novembre 2012 11:03 =C0 : BINET David OLNC/OLN Cc : BOUCADAIR Mohamed OLNC/OLN; IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt On Mon, Nov 19, 2012 at 6:57 PM, > wrote: And I do not understand the comment about the need to remove some requireme= nts and to provide a link to RFC3316bis document. I do not understand why a= RFCbis draft was proposed if the specifications were already present in dr= aft-binet-* document. Because that draft properly updates RFC3316. This document does not update = RFC3316, it's something completely different. [[david]] You are right. It is different and the goal is to get a document = where we can have all IPv6 specifications. Besides, I do not have the feeling that there was some demand for a RFC3316= update whereas there was some support for a document providing an IPv6 pro= file, as proposed in draft-binet-. Second, most of this document attempts to standardize feature sets, not pro= tocols or interoperability. I'm not sure this is is in scope for the IETF, = and even more so for an operations group inside the IETF. [[david]] It is your opinion but as operator, it is something which is very= important and there is a lack in standardisation documents where some IPv6= profile is defined. We receive a lot of support about such specifications. Does the IETF define an IPv4 profile? If not, why not? [[david]] As an operator, I would say such document would not be required i= f we had IPv6 terminals. But it is not the case and we need to get such ref= erence even if it is not our only action to get such devices. Does the IETF define an IPv6 profile for CPE ? Yes. Now, there is RFC6204. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4PUEXCB1Anante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

De : Lorenzo Colitti=20 [mailto:lorenzo@google.com]
Envoy=E9 : lundi 19 novembre = 2012=20 11:03
=C0 : BINET David OLNC/OLN
Cc : BOUCA= DAIR=20 Mohamed OLNC/OLN; IPv6 Ops WG
Objet : Re: [v6ops]=20 draft-binet-v6ops-cellular-host-requirements-00.txt

O= n Mon,=20 Nov 19, 2012 at 6:57 PM, <david.binet@orange.com> wrote:
And I do not understand the comment = about=20 the need to remove some requirements and to provide a link to RFC3316= bis=20 document. I do not understand why a RFCbis draft was proposed if= the=20 specifications were already present in draft-binet-* document.=20  
Because that draft properly updates RFC3316. This document does not= =20 update RFC3316, it's something completely different.
[[david]] You are r= ight. It=20 is different and the goal is to get a document where we can have all= IPv6=20 specifications. 
Besides, I do= not have=20 the feeling that there was some demand for a RFC3316 update whereas there= was=20 some support for a document providing an IPv6 profile, as proposed in=20 draft-binet-. 
Second, most of this document at= tempts=20 to standardize feature sets, not protocols or interoperability. I'm n= ot=20 sure this is is in scope for the IETF, and even more so for an operat= ions=20 group inside the IETF.
[[david]] It is your opinion bu= t as=20 operator, it is something which is very important and there is a= lack=20 in standardisation documents where some IPv6 profile is defined. We= =20 receive a lot of support about such specifications.  =20   
Does the IETF define an IPv4 profile? If not, why not?
[[david]] As an ope= rator, I=20 would say such document would not be required if we had IPv6=20 terminals. But it is not the case and we need to get such reference even = if it=20 is not our only action to get such devices. 
Does the IETF= define=20 an IPv6 profile for CPE ? Yes. Now, there is=20 RFC6204.    
__________________________________________________________________=
_______________________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4PUEXCB1Anante_-- From lorenzo@google.com Mon Nov 19 02:40:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38A21F8559 for ; Mon, 19 Nov 2012 02:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmBOzpSydiw0 for ; Mon, 19 Nov 2012 02:40:37 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFF6021F841C for ; Mon, 19 Nov 2012 02:40:37 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so5053160obb.31 for ; Mon, 19 Nov 2012 02:40:37 -0800 (PST) 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=uHhDblDpN8V2RXf80+oLOP2h5GgT9hfvXZEiM0w2jn8=; b=VCnX/6tQzusHv38G2zJgpzYNMWunSO4Olgz/UDIzyA5N58oKe+5jjPAG/c2tcqU+au VZxqjwObHzitoZVFWaqMllSd0SOYGy5WZ3QY6AGixgUEWAxD5+WVh9TckQdB9rSr+nQ7 Rk15XD4E2dLTsDhAmO5ws1q/s+g9S6ULbGrOfn1UgUjxhyqE//Xy0F7rLlG15HHLB4YH f6AaZ01VDZ9mwTg7lmFqiKX9Yr3mZ/PVkOQ49O/ewYvtDP6BV1R3okGuShW+tqM2pHUw NDEQdiz9lM5/BRlX2tQjFfVolaBc6lUzHBFug/F0+CyfAgqeGnajenDOyWKyTviRU8rE NOZw== 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=uHhDblDpN8V2RXf80+oLOP2h5GgT9hfvXZEiM0w2jn8=; b=XN63sMCD0AB6VUzdMEh+kTvX8dThpkrWi9XA+mnZAvT2ARf2lFj2neSO29lV+8aqD+ 8XNQ1F6oHTBrSJty2iGZa59PgpggtxrXlwvsNFz9USYkRcPz0J4dHyP7xuVZGoLlSQkx 4IdPiuzZENtgAzE8OLJ2mE3iC11CWsLdmVBk4JGlHzqRQJgmdP0DlXcgZq7ISmkUIS/N YQMOL/tuX8P7eIpoQDMO7vSQrptiZTATUJioEhRY565Sl4S38hBCSqmPfxsl4+jcE032 WG+ekIbwbbdn9WiLX6OkFvzpMACVuWg83k5dKTgy8gPReKLL/zBa4+aUQ7tSylczJvi9 kwFA== Received: by 10.60.6.227 with SMTP id e3mr10242319oea.22.1353321637304; Mon, 19 Nov 2012 02:40:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.111.99 with HTTP; Mon, 19 Nov 2012 02:40:17 -0800 (PST) In-Reply-To: <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Mon, 19 Nov 2012 19:40:17 +0900 Message-ID: To: david.binet@orange.com Content-Type: multipart/alternative; boundary=e89a8fb1f7ee75582d04ced6bf87 X-Gm-Message-State: ALoCoQnZ4AZBWUd/tPQ0IilGUYq/+qCwGEIagG1fU91nuHOZEjolw5BCewMl0P44W++tVs4pMq42d2QZRJMgnONMPyTwhBqDoLhTxkh1Ks8ZnXiautglwqAqGnisHqM+rAoym9ovsVsCsy12ytqN9ILQZjqvF+0C/9Ca7lp6mBk9c34ktke4K17J2dHyiweF/s9kb9u3kZc8 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 10:40:38 -0000 --e89a8fb1f7ee75582d04ced6bf87 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 19, 2012 at 7:30 PM, wrote: > ** > > Besides, I do not have the feeling that there was some demand for a > RFC3316 update whereas there was some support for a document providing an > IPv6 profile, as proposed in draft-binet-. > > Strange. I had the opposite feeling. > Does the IETF define an IPv4 profile? If not, why not? >> >> [[david]] As an operator, I would say such document would not be required > if we had IPv6 terminals. But it is not the case and we need to get such > reference even if it is not our only action to get such devices. > > Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of millions of them. --e89a8fb1f7ee75582d04ced6bf87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon= , Nov 19, 2012 at 7:30 PM, <david.binet@orange.com> wr= ote:
Besides, I do= not have=20 the feeling that there was some demand for a RFC3316 update whereas there= was=20 some support for a document providing an IPv6 profile, as proposed in=20 draft-binet-.=A0
Strange. I had the opposite feeling.=A0
Does the IETF define an IPv4 prof= ile? If not, why not?
[[david]]=A0As an operator, I=20 would say such document would not be required if=A0we had=A0IPv6=20 terminals. But it is not the case and we need to get such reference even = if it=20 is not=A0our only action to get such devices.=A0
Actually, we do have IPv6 termi= nals. Verizon Wireless has shipped tens of millions of them.
--e89a8fb1f7ee75582d04ced6bf87-- From mohamed.boucadair@orange.com Mon Nov 19 04:11:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBC921F85EB for ; Mon, 19 Nov 2012 04:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnasbHu88AbI for ; Mon, 19 Nov 2012 04:11:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D8CDF21F85E1 for ; Mon, 19 Nov 2012 04:11:56 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E28E7264133; Mon, 19 Nov 2012 13:11:55 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A6E744C071; Mon, 19 Nov 2012 13:11:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 19 Nov 2012 13:11:52 +0100 From: To: Lorenzo Colitti , BINET David OLNC/OLN Date: Mon, 19 Nov 2012 13:11:51 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3GQlI7i8bRReCcSKiZJkJFKZQ5cwAAF/fQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E703@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9751E703PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 12:11:58 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9751E703PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Lorenzo, Since we first submitted draft-binet-*, which says explicitly it is intende= d to update rfc3316, no one complained in the mailing list about the struc= ture of the draft to follow rfc3316 structure but instead there were constr= uctive technical discussions to clarify several of the requirements, to pro= pose new ones, etc. There were several voices to support this effort. We are happy to see draft-binet-* revived the discussion about rfc3316 upda= te and helped authors of draft-jouni-* to publish their document... We didn't adopted rfc3316 structure because we wanted a comprehensive list = of IPv6 features required to have acceptable IPv6 implementations which can= be connected to a cellular network. There are several IPv6 implementations but some of these implementations ar= e broken (e.g., see the issue raised by Tore in this thread). We hope draft= -binet-* will help in this area. The rationale adopted in draft-binet-* is not new to v6ops...similar effort= was carried out to define the CPE profile. Cheers, Med ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : lundi 19 novembre 2012 11:40 =C0 : BINET David OLNC/OLN Cc : BOUCADAIR Mohamed OLNC/OLN; IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt On Mon, Nov 19, 2012 at 7:30 PM, > wrote: Besides, I do not have the feeling that there was some demand for a RFC3316= update whereas there was some support for a document providing an IPv6 pro= file, as proposed in draft-binet-. Strange. I had the opposite feeling. Does the IETF define an IPv4 profile? If not, why not? [[david]] As an operator, I would say such document would not be required i= f we had IPv6 terminals. But it is not the case and we need to get such ref= erence even if it is not our only action to get such devices. Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of m= illions of them. --_000_94C682931C08B048B7A8645303FDC9F36E9751E703PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Lorenzo,
 
Since we first submitted draft= -binet-*,=20 which says explicitly it is intended to update rfc3316,  no one compla= ined=20 in the mailing list about the structure of the draft to follow rfc3316= =20 structure but instead there were constructive technical discussions to clar= ify=20 several of the requirements, to propose new ones, etc. There were several=20 voices to support this effort.
 
We are happy to see draft-binet-* revived the= =20 discussion about rfc3316 update and helped authors of draft-jouni-*=20 to publish their document... 
 
We didn't=20 adopted rfc3316 structure because we wanted a comprehensive list= =20 of IPv6 features required to have acceptable IPv6 implementations whic= h can=20 be connected to a cellular network.
 
<= SPAN=20 class=3D223224310-19112012><= SPAN=20 class=3D223224310-19112012>There are=20 several IPv6 implementations but some of these implementations are broken (= e.g.,=20 see the issue raised by Tore in this thread). We hope draft-binet-* wi= ll=20 help in this area.
 
The rationale adopted in draft-binet-* is not= new to=20 v6ops...similar effort was carried out to define the CPE profile.=20
 
Cheers,
Med

De : Lorenzo Colitti=20 [mailto:lorenzo@google.com]
Envoy=E9 : lundi 19 novembre = 2012=20 11:40
=C0 : BINET David OLNC/OLN
Cc : BOUCA= DAIR=20 Mohamed OLNC/OLN; IPv6 Ops WG
Objet : Re: [v6ops]=20 draft-binet-v6ops-cellular-host-requirements-00.txt

O= n Mon,=20 Nov 19, 2012 at 7:30 PM, <david.binet@orange.com> wrote:
<= /DIV>
Besides, I do not have the feeling t= hat=20 there was some demand for a RFC3316 update whereas there was some sup= port=20 for a document providing an IPv6 profile, as proposed in=20 draft-binet-. 
Strange. I had the opposite feeling. 
Does the IETF define an IPv4= =20 profile? If not, why=20 not?
[[david]] As an operator, I wou= ld say=20 such document would not be required if we had IPv6 terminal= s.=20 But it is not the case and we need to get such reference even if it i= s=20 not our only action to get such=20 devices. 
Actually, we do have IPv6 terminals. Verizon Wireless has shipped te= ns of=20 millions of them.
--_000_94C682931C08B048B7A8645303FDC9F36E9751E703PUEXCB1Bnante_-- From hesham@elevatemobile.com Mon Nov 19 05:37:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3E21F8616 for ; Mon, 19 Nov 2012 05:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+Fy-nxIj7Q5 for ; Mon, 19 Nov 2012 05:37:33 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15021F8608 for ; Mon, 19 Nov 2012 05:37:32 -0800 (PST) Received: from [118.209.240.249] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TaRXS-0005ZS-MQ; Tue, 20 Nov 2012 00:37:27 +1100 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 20 Nov 2012 00:37:13 +1100 From: Hesham Soliman To: Lorenzo Colitti , Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 13:37:34 -0000 I made several comments on this document and are all included in Lorenzo's comments below. Therefore I'm of the same opinion regarding WG adoption. Hesham -----Original Message----- From: Lorenzo Colitti Date: Monday, 19 November 2012 7:39 PM To: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt >I do not think this document is ready for WG adoption. > >To start with, I see a few general issues. > >First, the document is attempting to standardize behaviours that are >already standardized by 3GPP. This is leads to many of the requirements >being redundant because they are already included in 3GPP specs. If the >manufacturer is violating those specs already, I doubt that an RFC that >says "don't violate those specs" is going to have any effect at all. This >also presents the problem that if the 3GPP standards are updated, the >text becomes out of date. > >Second, most of this document attempts to standardize feature sets, not >protocols or interoperability. I'm not sure this is is in scope for the >IETF, and even more so for an operations group inside the IETF. > >Third, IETF work is supposed to proceed in parallel with running code, >not in the absence of running code. I very doubt there are two >interoperable implementations that satisfy all these requirements >(actually, I doubt that any real implementation satisfies even half of >them). Attempting to specify these requirements will not change that. > > >Moving on, at least these requirements are redundant and should be >removed or replaced by a reference to the appropriate specs: > > >REQ#3: Redundant with 3GPP specs. >REQ#4: Redundant with 3GPP specs. >REQ#5: Redundant with 3GPP specs. >REQ#6: Redundant with IPv6 node requirements. >REQ#7: Redundant with IPv6 node requirements. >REQ#7: Redundant with IPv6 node requirements and 3GPP specs. > >REQ#15: Redundant with RFC 6724. >REQ#17: Redundant with 3GPP specs. > > > >A few specific comments as well: > >REQ#1: why do you need to cite RFC 5952? It has nothing to do with >connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node >Requirements). > > >REQ#10: Not clear what happens if more than one provisioning method >provides DNS. Should the phone just information from one of them? Or >should it list all of them in priority order? > >REQ#11: Not clear to me what this means. I understand the "implement the >NAT64 discovery heuristic" requirement, but not the part that references >RFC 6052. What does the host need to implement from RFC 6052? > > >REQ#18: Meaningless. Saying "MAY" in a requirements document is no better >than saying nothing. > >REQ#25: What is the point of supporting RFC 5175 if it defines no new >flags? > >REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a >number of years? > >REQ#28: Duplicate of #12. > >On Sun, Nov 11, 2012 at 10:47 PM, wrote: > > > > >Dear all, > >As discussed in the v6ops meeting, we re-submitted a new version of the >text which does not update RFC3316. > >We hope this new version is ready for the WG adoption. > >Cheers, >Med > >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >De la part de internet-drafts@ietf.org > > > > >Envoy=E9 : lundi 12 novembre 2012 07:42 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Internet Protocol Version 6 (IPv6) Requirements >for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : >draft-binet-v6ops-cellular-host-requirements-00.txt > Pages : 15 > Date : 2012-11-11 > >Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requireme >nts > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-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=20 > >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 > > > > > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Nov 19 06:30:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47421F855E for ; Mon, 19 Nov 2012 06:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqwh5E7rXb0o for ; Mon, 19 Nov 2012 06:30:47 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD12521F8496 for ; Mon, 19 Nov 2012 06:30:46 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4060493lbk.31 for ; Mon, 19 Nov 2012 06:30:45 -0800 (PST) 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=urf3RsYi+NJ4cvklLQcM43X8iczHq37UFYNDPB6MDcM=; b=Lzg/w32ofyxAthiOegSowYCxJ4y9g5KCizbaA2vobw1vhUc9xpsZ2cSUIWqdlFBY8K tLK16pimSJhnBnyOuZDK9COHGeE4u17/qZzUc8hlzrsEhtO0hExjjlvb4aynfEWk4gjb GffcVpQt0qLjcJzp+iUwZOFGcz4CDqNzBCwnjByxPMxNeSB4lstw+isb+YFF1RFc+AqL SNVbGbtgcZkXRTYzr7HJvThfdxSpekey6h2+rFOkTE9ZrCwTQcCxiLHB1g6b0xeUWWi/ c9pBK1hTLMo0mKH63nu3M/c5bqM1VTrWjQpz7xI8LbPodEL1hJs+eemkE2aO70WUTQMJ F1Vg== MIME-Version: 1.0 Received: by 10.112.86.104 with SMTP id o8mr5101733lbz.109.1353335445588; Mon, 19 Nov 2012 06:30:45 -0800 (PST) Received: by 10.112.81.167 with HTTP; Mon, 19 Nov 2012 06:30:45 -0800 (PST) Received: by 10.112.81.167 with HTTP; Mon, 19 Nov 2012 06:30:45 -0800 (PST) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> Date: Mon, 19 Nov 2012 06:30:45 -0800 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=bcaec554d4e87f0a9204ced9f64d Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 14:30:47 -0000 --bcaec554d4e87f0a9204ced9f64d Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Nov 19, 2012 2:40 AM, "Lorenzo Colitti" wrote: > > On Mon, Nov 19, 2012 at 7:30 PM, wrote: >>> >>> Besides, I do not have the feeling that there was some demand for a RFC3316 update whereas there was some support for a document providing an IPv6 profile, as proposed in draft-binet-. > > Strange. I had the opposite feeling. >>>>> >>>>> Does the IETF define an IPv4 profile? If not, why not? >>> >>> [[david]] As an operator, I would say such document would not be required if we had IPv6 terminals. But it is not the case and we need to get such reference even if it is not our only action to get such devices. > > Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of millions of them. > > Are those terminals capable of being used on any other network effectively? I believe the answer is no. Given vzw unique 3gpp and 3gpp2 network, their terminals are quite unique. CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec554d4e87f0a9204ced9f64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Nov 19, 2012 2:40 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Mon, Nov 19, 2012 at 7:30 PM, <david.binet@orange.com> wrote:
>>>
>>> Besides, I do not have the feeling that there was some demand = for a RFC3316 update whereas there was some support for a document providin= g an IPv6 profile, as proposed in draft-binet-.=A0
>
> Strange. I had the opposite feeling.=A0
>>>>>
>>>>> Does the IETF define an IPv4 profile? If not, why not?=
>>>
>>> [[david]]=A0As an operator, I would say such document would no= t be required if=A0we had=A0IPv6 terminals. But it is not the case and we n= eed to get such reference even if it is not=A0our only action to get such d= evices.=A0
>
> Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens= of millions of them.
>
>

Are those terminals capable of being used on any other netwo= rk effectively?=A0 I believe the answer is no. Given vzw unique 3gpp and 3g= pp2 network, their terminals are quite unique.

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

--bcaec554d4e87f0a9204ced9f64d-- From cb.list6@gmail.com Mon Nov 19 06:36:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224421F8616 for ; Mon, 19 Nov 2012 06:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf5qX5IAYzqf for ; Mon, 19 Nov 2012 06:36:48 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36121F84E6 for ; Mon, 19 Nov 2012 06:36:47 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3985115lah.31 for ; Mon, 19 Nov 2012 06:36:46 -0800 (PST) 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=Ul2edwAmMTlyJwHljwkPtTTdTkfqLFHXA5i8HEN3VW0=; b=nAEoepuJkcIk0da5Q6wU3cDId1m313w6AmCXWD5HOi47BTjPWeOl5ZEFIMBdWkb04A Tngmzo5wucmHzo567PFLu/Dg5YMlTqiFxPWnm0YbykAy6nMCwYbWrNPkkFt9aWiObeoF YvkmQZ184Vovvh27sfN5QPpKlJGt25/qPwUxTtmafpwscKmC6QNYQNyGgR3gxq5Cj7Ow vI9SBFNM/ziYVGmmnx6NhOM7B9qf09FFS6b2aoyYShxkwKwqxKhRQXBy2pCe6lgB74Zy rJDqXcLJaT4+mAYoWZGK/DSlljasM9bk2o6rYBz/KILFYIxy4a2KF4sSYn3A0H+Mz8JP YSAw== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr11603622lab.25.1353335806345; Mon, 19 Nov 2012 06:36:46 -0800 (PST) Received: by 10.112.81.167 with HTTP; Mon, 19 Nov 2012 06:36:46 -0800 (PST) Received: by 10.112.81.167 with HTTP; Mon, 19 Nov 2012 06:36:46 -0800 (PST) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> Date: Mon, 19 Nov 2012 06:36:46 -0800 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d04088d11ffc0d704ceda0b52 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 14:36:49 -0000 --f46d04088d11ffc0d704ceda0b52 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Nov 19, 2012 2:03 AM, "Lorenzo Colitti" wrote: > > On Mon, Nov 19, 2012 at 6:57 PM, wrote: >>> >>> And I do not understand the comment about the need to remove some requirements and to provide a link to RFC3316bis document. I do not understand why a RFCbis draft was proposed if the specifications were already present in draft-binet-* document. > > Because that draft properly updates RFC3316. This document does not update RFC3316, it's something completely different. >>> >>> Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF. >>> [[david]] It is your opinion but as operator, it is something which is very important and there is a lack in standardisation documents where some IPv6 profile is defined. We receive a lot of support about such specifications. > > Does the IETF define an IPv4 profile? If not, why not? > Why no ipv4 profile? Because ipv4 network behavior is emergent behavior not an engineered behavior. The definition of "working" on ipv4 is that it does not break something that already works.... so working is defined by baggage. Given that the only fully deployed ipv6 3gpp network is very unique and only one data point, it is not sufficient to create a repeatable model. The goal of this doc, like 6204, is to do some more consensus based engineering to better bootstrap our ipv6 deployments. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04088d11ffc0d704ceda0b52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Nov 19, 2012 2:03 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Mon, Nov 19, 2012 at 6:57 PM, <david.binet@orange.com> wrote:
>>>
>>> And I do not understand the comment about the need to remove s= ome requirements and to provide a link to RFC3316bis document.=A0I do not u= nderstand why a RFCbis draft was proposed if the specifications were alread= y present in draft-binet-* document. =A0
>
> Because that draft properly updates RFC3316. This document does not up= date RFC3316, it's something completely different.
>>>
>>> Second, most of this document attempts to standardize feature = sets, not protocols or interoperability. I'm not sure this is is in sco= pe for the IETF, and even more so for an operations group inside the IETF.<= br> >>> [[david]]=A0It is your opinion but as operator, it is somethin= g which is very important and there=A0is a lack in standardisation document= s where some IPv6 profile is defined. We receive a lot of support about suc= h=A0specifications. =A0 =A0=A0
>
> Does the IETF define an IPv4 profile? If not, why not?
>

Why no ipv4 profile?=A0=A0 Because ipv4 network behavior is = emergent behavior not an engineered behavior.

The definition of "working" on ipv4 is that it doe= s not break something that already works.... so working is defined by bagga= ge. Given that the only fully deployed ipv6 3gpp network is very unique and= only one data point,=A0 it is not sufficient to create a repeatable model.=

The goal of this doc, like 6204, is to do some more consensu= s based engineering to better bootstrap our ipv6 deployments.

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

--f46d04088d11ffc0d704ceda0b52-- From bs7652@att.com Mon Nov 19 07:35:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB40E21F847D for ; Mon, 19 Nov 2012 07:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.642 X-Spam-Level: X-Spam-Status: No, score=-106.642 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaWYrz2vkfHr for ; Mon, 19 Nov 2012 07:35:09 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 40D6321F8469 for ; Mon, 19 Nov 2012 07:35:09 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id da15aa05.6590e940.266507.00-585.726898.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 19 Nov 2012 15:35:09 +0000 (UTC) X-MXL-Hash: 50aa51ad33cdf3f5-e025568de9e0ad72ca641eedfcbbf864370d155f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 5a15aa05.0.266452.00-308.726744.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 19 Nov 2012 15:35:02 +0000 (UTC) X-MXL-Hash: 50aa51a61b208cdd-ded616bf480e0349f4a6c7ea9dcb8a218a557941 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAJFYtCx002800; Mon, 19 Nov 2012 10:34:58 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qAJFYI4q001745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 10:34:45 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 19 Nov 2012 10:34:06 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0318.001; Mon, 19 Nov 2012 10:34:06 -0500 From: "STARK, BARBARA H" To: "david.binet@orange.com" , Lorenzo Colitti Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3AoO7OcUkwg0OpTYK+OOMQp/alYAAAHbFQAW55kAAAArVZgAAAOC4AAAD1bIAAAr7TUA== Date: Mon, 19 Nov 2012 15:34:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6112F5DCF28@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.93.19] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6112F5DCF28GAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=VcpAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=GD_NjPN4rjcA:10 a=THjfo8TEUvAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Ri5rfPnKy] X-AnalysisOut: [qoA:10 a=uO1LomaR_b2s4cga2dcA:9 a=CjuIK1q_8ugA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=amikSfmOx09uIeGE] X-AnalysisOut: [:21] Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 15:35:11 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6112F5DCF28GAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does the IETF define an IPv4 profile? If not, why not? [[david]] As an operator, I would say such document would not be required i= f we had IPv6 terminals. But it is not the case and we need to get such ref= erence even if it is not our only action to get such devices. Does the IETF define an IPv6 profile for CPE ? Yes. Now, there is RFC6204. Just to explain a bit of RFC 6204 history -- CableLabs and Broadband= Forum had no difficulty (internal to their respective orgs) in defining re= quirements / device profiles for CE routers that are expected to attach to = their respective access architectures. The reason these organizations came = to IETF was so there could be requirements available for retail devices (th= at had no expectation of required compliance to any BBF or CableLabs spec) = that wanted to understand what was needed to attach successfully to either = access architecture. There are many additional requirements in the CableLab= s eRouter specs and BBF TR-124i3 that describe requirements for CE routers = that are intended only for those environments. Note that RFC 6204 (and 6204= bis) do not reference any BBF or CableLabs spec. Rather, it is expected tha= t those organization's specs will reference or be consistent with RFC 6204 = (6204bis), and build upon that as the base for their architecture-specific = requirements. In cases where BBF has total control over specifying an inter= face, BBF has been known to ask IETF for help with needed Layer 3 protocol = definition and extensions and recommendations for appropriate requirements,= but not for actual creation or publication of device or network element fu= nctional profiles or requirements. Barbara --_000_2D09D61DDFA73D4C884805CC7865E6112F5DCF28GAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does the IETF define an IPv4 profile? If = not, why not?
[[david]] As an operator, I would say such = document would not be required if we had IPv6 terminals. But it i= s not the case and we need to get such reference even if it is not our= only action to get such devices. 

Does the IETF define an IPv6 p= rofile for CPE ? Yes. Now, there is RFC6204.   <= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:#1F497D">

 

<bhs&g= t; Just to explain a bit of RFC 6204 history --  CableLabs and Broadba= nd Forum had no difficulty (internal to their respective orgs) in defining requirements / device profiles for CE routers that are expected to attach = to their respective access architectures. The reason these organizations ca= me to IETF was so there could be requirements available for retail devices = (that had no expectation of required compliance to any BBF or CableLabs spec) that wanted to understand what wa= s needed to attach successfully to either access architecture. There are ma= ny additional requirements in the CableLabs eRouter specs and BBF TR-124i3 = that describe requirements for CE routers that are intended only for those environments. Note that RFC 6204 = (and 6204bis) do not reference any BBF or CableLabs spec. Rather, it is exp= ected that those organization’s specs will reference or be consistent= with RFC 6204 (6204bis), and build upon that as the base for their architecture-specific requirements. In cases wh= ere BBF has total control over specifying an interface, BBF has been known = to ask IETF for help with needed Layer 3 protocol definition and extensions= and recommendations for appropriate requirements, but not for actual creation or publication of device or netw= ork element functional profiles or requirements.

Barbara

--_000_2D09D61DDFA73D4C884805CC7865E6112F5DCF28GAALPA1MSGUSR9L_-- From ales.vizdal@t-mobile.cz Mon Nov 19 13:51:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195A621F8552 for ; Mon, 19 Nov 2012 13:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxHEPM0Ir0ay for ; Mon, 19 Nov 2012 13:51:35 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1674821F8885 for ; Mon, 19 Nov 2012 13:51:35 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id CE9232857EE; Mon, 19 Nov 2012 22:51:33 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 19 Nov 2012 22:51:33 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Lorenzo Colitti , "david.binet@orange.com" Date: Mon, 19 Nov 2012 22:51:08 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3GQmMYFQau+nDgTs+A9T0ghVcR3wAXNL+Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF6EA652@SRVHKE02.rdm.cz> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> <17547_1353319026_50AA0272_17547_9460_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56F7B@PUEXCB1A.nanterre.francetelecom.fr> <32082_1353321049_50AA0A58_32082_2067_1_1B2E7539FECD9048B261B791B1B24A7C3EF5B56FF4@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA652SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 21:51:36 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA652SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: Monday, November 19, 2012 11:40 AM To: david.binet@orange.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt On Mon, Nov 19, 2012 at 7:30 PM, > wrote: Besides, I do not have the feeling that there was some demand for a RFC3316= update whereas there was some support for a document providing an IPv6 pro= file, as proposed in draft-binet-. Strange. I had the opposite feeling. Does the IETF define an IPv4 profile? If not, why not? [[david]] As an operator, I would say such document would not be required i= f we had IPv6 terminals. But it is not the case and we need to get such ref= erence even if it is not our only action to get such devices. [ales] As an operator I *need* IPv6 profile document I can refer vendors to= , you see other operators on the list requesting the same, so it is clearly= an issue operators are trying to address here. Honestly, I am still not getting what's wrong with this do= cument intended to be a requirements list such as 6204(bis). Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of m= illions of them. [ales] No, we don't and that's why we see the need to spend our efforts wri= ting this requirements document. If we had them, we wouldn't be here. --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA652SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

=

From: v6o= ps-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lor= enzo Colitti
Sent: Monday, November 19, 2012 11:40 AM
To: david.binet@orange.com
Cc: IPv6 Ops WG
Subject: Re: = [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

 

On Mon, Nov 19, 2012 at 7:30 PM, <david.binet@orange.com> wrote:<= /span>

Besides, I do not have the f= eeling that there was some demand for a RFC3316 update whereas there was so= me support for a document providing an IPv6 profile, as proposed in draft-b= inet-. 

Strange. I had the opposite feeling. 

Does the IETF define an IPv4 pr= ofile? If not, why not?

[[david]] As an operat= or, I would say such document would not be required if we had IPv= 6 terminals. But it is not the case and we need to get such reference even = if it is not our only action to get such devices. 

 

[ales] As an operator I *need* IPv6 profile document I= can refer vendors to, you see other operators on the list requesting the s= ame, so it is clearly an issue operators are trying

to address here. Honestly, I am still not getting= what's wrong with this document intended to be a requirements list such as= 6204(bis).

 

Actually, we do have IPv6 terminals. Verizon Wireless has shipped ten= s of millions of them.

 

[ales] No, we don't and that's why we see the need to spend = our efforts writing this requirements document. If we had them, we wouldn't= be here.

 

 

<= /div>
= --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA652SRVHKE02rdmcz_-- From ales.vizdal@t-mobile.cz Mon Nov 19 14:09:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555421F8667 for ; Mon, 19 Nov 2012 14:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpiDCGsjQllM for ; Mon, 19 Nov 2012 14:09:36 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 596D521F84FC for ; Mon, 19 Nov 2012 14:09:36 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id E2E6828580E; Mon, 19 Nov 2012 23:09:34 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Mon, 19 Nov 2012 23:09:34 +0100 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Lorenzo Colitti , "mohamed.boucadair@orange.com" Date: Mon, 19 Nov 2012 23:06:05 +0100 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt Thread-Index: Ac3GMYcG5QbjvUfKRYGciVvK2UxAgQAbqfmg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF6EA655@SRVHKE02.rdm.cz> References: <94C682931C08B048B7A8645303FDC9F36E947B1328@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA655SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-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: Mon, 19 Nov 2012 22:09:37 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA655SRVHKE02rdmcz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAxOSwgMjAxMiA5OjM5IEFNDQpUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KQ2M6 IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1iaW5ldC12Nm9wcy1jZWxs dWxhci1ob3N0LXJlcXVpcmVtZW50cy0wMC50eHQNCg0KSSBkbyBub3QgdGhpbmsgdGhpcyBkb2N1 bWVudCBpcyByZWFkeSBmb3IgV0cgYWRvcHRpb24uDQoNCkNhbiB3ZSBhZ3JlZSBvbiB0aGF0IHN1 Y2ggYSBkb2N1bWVudCBpcyByZXF1aXJlZD8NCg0KDQpSRVEjMjc6IFdoeSBzdXBwb3J0IERIQ1B2 NiBQRCBpZiBubyBtb2JpbGUgbmV0d29ya3Mgd2lsbCBzdXBwb3J0IGl0IGZvciBhIG51bWJlciBv ZiB5ZWFycz8NCg0KW2FsZXNdIEkgYW0gZXhwZWN0aW5nIFBEIGJlaW5nIHN1cHBvcnRlZCBpbiB+ MiB5ZWFycyB0aW1lZnJhbWUsIHNvIGl0IGlzIGRlZmluaXRlbHkgd29ydGggY29uc2lkZXJpbmcu DQo= --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA655SRVHKE02rdmcz_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1HQiBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gdjZvcHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+TG9yZW56byBDb2xpdHRpPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE5LCAy MDEyIDk6MzkgQU08YnI+PGI+VG86PC9iPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPGJy PjxiPkNjOjwvYj4gSVB2NiBPcHMgV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRy YWZ0LWJpbmV0LXY2b3BzLWNlbGx1bGFyLWhvc3QtcmVxdWlyZW1lbnRzLTAwLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SSBkbyBub3QgdGhp bmsgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgV0cgYWRvcHRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5DYW4gd2UgYWdyZWUgb24gdGhhdCBzdWNoIGEgZG9jdW1lbnQgaXMgcmVx dWlyZWQ/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+UkVRIzI3OiBXaHkgc3VwcG9y dCBESENQdjYgUEQgaWYgbm8gbW9iaWxlIG5ldHdvcmtzIHdpbGwgc3VwcG9ydCBpdCBmb3IgYSBu dW1iZXIgb2YgeWVhcnM/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bYWxlc10gSSBhbSBl eHBlY3RpbmcgUEQgYmVpbmcgc3VwcG9ydGVkIGluIH4yIHllYXJzIHRpbWVmcmFtZSwgc28gaXQg aXMgZGVmaW5pdGVseSB3b3J0aCBjb25zaWRlcmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_1808340F7EC362469DDFFB112B37E2FCC6CF6EA655SRVHKE02rdmcz_-- From iesg-secretary@ietf.org Mon Nov 19 14:45:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C0421F8557; Mon, 19 Nov 2012 14:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvOC8+b8T1EI; Mon, 19 Nov 2012 14:45:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30B21F8472; Mon, 19 Nov 2012 14:45:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121119224515.7712.22544.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 14:45:15 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' to Informational RFC (draft-ietf-v6ops-ra-guard-implementation-07.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, 19 Nov 2012 22:45:16 -0000 The IESG has approved the following document: - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' (draft-ietf-v6ops-ra-guard-implementation-07.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ Technical Summary The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard [RFC6105] as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. Working Group Summary Initial version of this draft was announced on the v6ops list 1/5/12,a previous related draft draft-gont-v6ops-ra-guard-evasion first discussed 6/1/11 was supplanted by it Some initial discussion on the list and between the authors WG chairs and IESG members asked for guidance on the work being done in V6ops versus the security or internet areas. Probably as a consequence of the original RFC 6105 RA-Guard work was done under the v6ops charter it was concluded that v6ops was an appropriate venue to provide advice to implementers. The document was accepted as working group document on 2/13/12. Working-group last call commenced 04/22/12 and Completed on 5/6/12. 26 messages in favor from 11 participants were recorded with none opposed. The outcome of the WGLC is consistent with the v6ops discussion during IETF 82. Document Quality The document has received significant review both within v6ops and elsewhere in the community such as SAAG and 6man. Personnel The document shepherd is Joel Jaeggli co-chair of the v6ops working group. The responsible AD is Ron Bonica. RFC Editor Note OLD> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies that the first-fragment (i.e., the fragment with the Fragment Offset set to 0) MUST contain the entire IPv6 header chain, and allows intermmediate systems such as routers to drop those packets that fail to comply with this requirement. RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies that the first-fragment (i.e., the fragment with the Fragment Offset set to 0) must contain the entire IPv6 header chain, and allows intermmediate systems such as routers to drop those packets that fail to comply with this requirement. RATIONALE: By definition, Router Advertisement messages MUST originate on-link, MUST have a link-local IPv6 Source Address, and MUST have a Hop Limit value of 255. [RFC4861]. RATIONALE: By definition, Router Advertisement messages MUST originate on-link, must have a link-local IPv6 Source Address, and MUST have a Hop Limit value of 255. [RFC4861]. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6AA21F84D2 for ; Mon, 19 Nov 2012 15:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5192DxSmnpE for ; Mon, 19 Nov 2012 15:41:21 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F16B21F84BB for ; Mon, 19 Nov 2012 15:41:21 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3538046vcb.31 for ; Mon, 19 Nov 2012 15:41:20 -0800 (PST) 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=9ElMLrWyQgXtBeVCzhYVp3CGj09Z8USmYZCipp/F00E=; b=FziszjD8wIbbBlyFUykbLrrinnesDLpM7ipAEy7A/xbWA8hpuYcnu/0xb3UhWg40t1 pOW+SktbAPBZ5VKsgD1zHkeeTlVirsJc1bdjRltxfPFpM3nkdNTPodDeK4lU3F7lcFA6 dvGXBZl0qpVuc2SjxRsnJhT4mevKe8uLiONgQOq2ajuUs9fu4jk/qoMc1ohkHe0ITRHM RzLgTKf4lZGWiG+MHAy7vY/tqab1oM62MHJ7KdWjbMQJIF9iUjYUVUtN/ShIsnc2r85t 5nXRcRAaH3kBcxBzCV02mq/Y3hgSR4N2X5nLQY+zpNdEzJXEN1Yn+inECR5eyuF+uQxr GM/w== MIME-Version: 1.0 Received: by 10.58.145.161 with SMTP id sv1mr19488955veb.52.1353368480374; Mon, 19 Nov 2012 15:41:20 -0800 (PST) Sender: nygren@gmail.com Received: by 10.220.224.197 with HTTP; Mon, 19 Nov 2012 15:41:19 -0800 (PST) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F810E5@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239F810E5@szxeml545-mbx.china.huawei.com> Date: Mon, 19 Nov 2012 18:41:19 -0500 X-Google-Sender-Auth: BqURNie6I8br5_Lkqo-WG-Wdi80 Message-ID: From: Erik Nygren To: Sheng Jiang Content-Type: multipart/alternative; boundary=047d7b67613c85e03504cee1a7cc Cc: "v6ops@ietf.org" , sunqiong , ietf@cheesy.sackheads.org Subject: Re: [v6ops] Semantic IPv6 Prefix drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:41:22 -0000 --047d7b67613c85e03504cee1a7cc Content-Type: text/plain; charset=ISO-8859-1 The concept of semantic addressing is certainly useful in some contexts, and it does feel like an area where having some standards and shared best practices could be useful. Some particular feedback: * I think it is critical to be clear that any semantic addressing is only meaningful within administrative/operational domains (such as within an address prefix controlled by an organization). * Semantic addressing has applications outside of just semantic prefixes. There are certainly cases where having address semantics outside of the prefix (ie, in the bottom 64 bits) would also be valuable, although this has different considerations as to security and interaction with address assignment. * A big missing piece of semantic addressing is a standard way of communicating the semantic match or bits. This feels like one area where it may be valuable to do IETF standardization work to define a language for specifying semantic address matches or patterns. This way semantic addresses could be usefully communicated between parties and devices within an organization, as well as between organizations. Ideally this would be implemented in routers and other network devices (such as to allow the application of packet filtering based on these semantic address matches). Expanding on that last point about allowing semantic matches to be specified, an initial proposal is that this consists of three parts: an address prefix or set of prefixes (the context within the semantic match applies), a mask (specifying which bits have semantics), and a value (the value of the bits after masking the address). Once there is a language to talk about these matches, it becomes possible to apply policies based on these matches. For example, if an organization has the network 2001:db8::/32 and decides that bits 48-51 specify the subscriber type (eg, http://tools.ietf.org/html/draft-sun-semantic-usecase-01 section 2), it would be possible to specify wifi subscribers with: { prefix: "2001:db8::/32", mask: "0:0:0:f000::", values: [ "0:0:0:a000::", "0:0:0:b000::" ] } For another example, some other organization might want to apply a policy to all devices with a particular EUI-64 value ("AC:DE:48") within their network (eg, to do some extra logging for debugging). They might then specify that with: { prefix: "2001:db8:abcd::/48", mask: "::ffff:ffff:ff00:0", value: "::acde:48ff:fe00:0" } Another example might be for an organization that always runs a particular virtual server host on addresses ending with "::1234" to communicate that as: { prefixes: [ "2001:db8:abcd::/48", "2001:db8:abce::/48" ], mask: "::ffff", value: "::1234" } The JSON notation above is just one example --- there may be some other syntax more friendly to more router configuration languages. Having some standard notation like this that specifies a mask, masked value(s), and the applicable prefix(es) would make semantic prefixing (and semantic addressing in general) much more viable for those networks or operators for whom it makes sense within their environment as there would then be some way to communicate and use it. Erik On Tue, Oct 23, 2012 at 5:54 AM, Sheng Jiang wrote: > Hi, all, > > Two semantic IPv6 prefix have been submitted to IETF. Could you please > review them? Any comments/suggestions/advices are appreciated. > > A Framework for Semantic IPv6 Prefix and Gap Analysis, > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-01 > > Use case of IPv6 prefix semantics for operators, > http://tools.ietf.org/html/draft-sun-semantic-usecase-01 > > Best regards, > > Sheng + Qiong > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b67613c85e03504cee1a7cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The concept of semantic addressing is certainly useful in some contexts, an= d it does feel like an area where having some standards and shared best pra= ctices could be useful.

Some particular feedback:

* I think i= t is critical to be clear that any semantic addressing is only meaningful w= ithin administrative/operational domains (such as within an address prefix = controlled by an organization).

* Semantic addressing has applications outside of just semantic prefixe= s.=A0 There are certainly cases where having address semantics outside of t= he prefix (ie, in the bottom 64 bits) would also be valuable, although this= has different considerations as to security and interaction with address a= ssignment.

* A big missing piece of semantic addressing is a standard way of commu= nicating the semantic match or bits.=A0 This feels like one area where it m= ay be valuable to do IETF standardization work to define a language for spe= cifying semantic address matches or patterns.=A0 This way semantic addresse= s could be usefully communicated between parties and devices within an orga= nization, as well as between organizations.=A0 Ideally this would be implem= ented in routers and other network devices (such as to allow the applicatio= n of packet filtering based on these semantic address matches).

Expanding on that last point about allowing semantic matches to be spec= ified, an initial proposal is that this consists of three parts:=A0=A0 an a= ddress prefix or set of prefixes (the context within the semantic match app= lies), a mask (specifying which bits have semantics), and a value (the valu= e of the bits after masking the address).=A0 Once there is a language to ta= lk about these matches, it becomes possible to apply policies based on thes= e matches.

For example, if an organization has the network 2001:db8::/32 and decid= es that bits 48-51 specify the subscriber type (eg, http://tools.ietf.org/html/dr= aft-sun-semantic-usecase-01 section 2), it would be possible to specify= wifi subscribers with:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 { prefix: "2001:db8::/32", = mask: "0:0:0:f000::", values: [ "0:0:0:a000::", "0= :0:0:b000::" ] }

For another example, some other organization m= ight want to apply a policy to all devices with a particular EUI-64 value (= "AC:DE:48") within their network (eg, to do some extra logging fo= r debugging).
They might then specify that with:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= { prefix: "2001:db8:abcd::/48", mask: "::ffff:ffff:ff00:0&q= uot;, value: "::acde:48ff:fe00:0" }

Another example might = be for an organization that always runs a particular virtual server host on= addresses ending with "::1234" to communicate that as:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 { prefixes: [ "2001:db8:abcd::/48&q= uot;, "2001:db8:abce::/48" ], mask: "::ffff", value: &q= uot;::1234" }

The JSON notation above is just one example --- t= here may be some other syntax more friendly to more router configuration la= nguages.
Having some standard notation like this that specifies a mask, masked value= (s), and the applicable prefix(es) would make semantic prefixing
(and s= emantic addressing in general) much more viable for those networks or opera= tors for whom it makes sense within their environment
as there would then be some way to communicate and use it.

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



On Tue, Oct 23, 20= 12 at 5:54 AM, Sheng Jiang <jiangsheng@huawei.com> wrote= :
Hi, all,

Two semantic IPv6 prefix have been submitted to IETF. Could you please revi= ew them? Any comments/suggestions/advices are appreciated.

A Framework for Semantic IPv6 Prefix and Gap Analysis, h= ttp://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-01

Use case of IPv6 prefix semantics for operators, http://tools.i= etf.org/html/draft-sun-semantic-usecase-01

Best regards,

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

--047d7b67613c85e03504cee1a7cc-- From jiangsheng@huawei.com Mon Nov 19 18:35:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9809221F8800 for ; Mon, 19 Nov 2012 18:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhN2O+RwTJiO for ; Mon, 19 Nov 2012 18:35:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8421F87FB for ; Mon, 19 Nov 2012 18:35:03 -0800 (PST) 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 AMY50468; Tue, 20 Nov 2012 02:35:03 +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.3; Tue, 20 Nov 2012 02:34:33 +0000 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 02:35:00 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 10:34:52 +0800 From: Sheng Jiang To: Erik Nygren Thread-Topic: [v6ops] Semantic IPv6 Prefix drafts Thread-Index: Ac2xBF57/hJL46osTme58HeDf3NSSgVZ/MKAABYiTkA= Date: Tue, 20 Nov 2012 02:34:50 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8F56C@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239F810E5@szxeml545-mbx.china.huawei.com> In-Reply-To: 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.140] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F8F56Cszxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , sunqiong , "ietf@cheesy.sackheads.org" Subject: Re: [v6ops] Semantic IPv6 Prefix drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 02:35:07 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8F56Cszxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEVyaWssDQoNClRoYW5rcyBmb3IgeW91ciBlbWFpbCBhbmQgc3VwcG9ydC4gU29tZSBkZXRh aWxlZCByZXBsaWVzIGluIGxpbmVzLg0KDQpTaGVuZw0KDQpGcm9tOiBueWdyZW5AZ21haWwuY29t IFttYWlsdG86bnlncmVuQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEVyaWsgTnlncmVuDQpTZW50 OiBUdWVzZGF5LCBOb3ZlbWJlciAyMCwgMjAxMiA3OjQxIEFNDQpUbzogU2hlbmcgSmlhbmcNCkNj OiB2Nm9wc0BpZXRmLm9yZzsgc3VucWlvbmc7IGlldGZAY2hlZXN5LnNhY2toZWFkcy5vcmcNClN1 YmplY3Q6IFJlOiBbdjZvcHNdIFNlbWFudGljIElQdjYgUHJlZml4IGRyYWZ0cw0KDQpUaGUgY29u Y2VwdCBvZiBzZW1hbnRpYyBhZGRyZXNzaW5nIGlzIGNlcnRhaW5seSB1c2VmdWwgaW4gc29tZSBj b250ZXh0cywgYW5kIGl0IGRvZXMgZmVlbCBsaWtlIGFuIGFyZWEgd2hlcmUgaGF2aW5nIHNvbWUg c3RhbmRhcmRzIGFuZCBzaGFyZWQgYmVzdCBwcmFjdGljZXMgY291bGQgYmUgdXNlZnVsLg0KDQpT b21lIHBhcnRpY3VsYXIgZmVlZGJhY2s6DQoNCiogSSB0aGluayBpdCBpcyBjcml0aWNhbCB0byBi ZSBjbGVhciB0aGF0IGFueSBzZW1hbnRpYyBhZGRyZXNzaW5nIGlzIG9ubHkgbWVhbmluZ2Z1bCB3 aXRoaW4gYWRtaW5pc3RyYXRpdmUvb3BlcmF0aW9uYWwgZG9tYWlucyAoc3VjaCBhcyB3aXRoaW4g YW4gYWRkcmVzcyBwcmVmaXggY29udHJvbGxlZCBieSBhbiBvcmdhbml6YXRpb24pLg0KDQo8c2hl bmc+IGZ1bGx5IGFncmVlLiBUaGF04oCZcyB3aHkgd2UgZGVmaW5lcyB0aGUgU2VtYW50aWMgUHJl Zml4IERvbWFpbiB0byBjbGVhcmx5IGRyYXcgdGhlIGJvcmRlcnMuDQoNCiogU2VtYW50aWMgYWRk cmVzc2luZyBoYXMgYXBwbGljYXRpb25zIG91dHNpZGUgb2YganVzdCBzZW1hbnRpYyBwcmVmaXhl cy4gIFRoZXJlIGFyZSBjZXJ0YWlubHkgY2FzZXMgd2hlcmUgaGF2aW5nIGFkZHJlc3Mgc2VtYW50 aWNzIG91dHNpZGUgb2YgdGhlIHByZWZpeCAoaWUsIGluIHRoZSBib3R0b20gNjQgYml0cykgd291 bGQgYWxzbyBiZSB2YWx1YWJsZSwgYWx0aG91Z2ggdGhpcyBoYXMgZGlmZmVyZW50IGNvbnNpZGVy YXRpb25zIGFzIHRvIHNlY3VyaXR5IGFuZCBpbnRlcmFjdGlvbiB3aXRoIGFkZHJlc3MgYXNzaWdu bWVudC4NCg0KPHNoZW5nPlRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgdXNlIGNhc2UuIFdlIGRpZCBj b25zaWRlciBpdCBiZWZvcmUuIEJ1dCB3ZSB3ZXJlIG5vdCBzdXJlIGhvdyB0aGVzZSBhZGRyZXNz IGNhbiBiZSB0cnVzdGVkLiBJZiB5b3Ugb25seSBjb25zaWRlciBESENQdjYgYXNzaWduaW5nIGFk ZHJlc3MgbW9kZWwsIHRoaXMgaXMgYSB2YWx1YWJsZSB1c2UgY2FzZSAod2UgbWF5IHdyaXRlIG90 aGVyIGRyYWZ0IGZvciB0aGlzLCBJIGd1ZXNzKS4gQnV0IGlmIHlvdSBjb25zaWRlciBTTEFBQywg dGhlIGhvc3QgZ2VuZXJhdGVkIGludGVyZmFjZSBJRCBhcmUgbm90IHRydXN0ZWQgZm9yIHNlbWFu dGljcy4NCg0KKiBBIGJpZyBtaXNzaW5nIHBpZWNlIG9mIHNlbWFudGljIGFkZHJlc3NpbmcgaXMg YSBzdGFuZGFyZCB3YXkgb2YgY29tbXVuaWNhdGluZyB0aGUgc2VtYW50aWMgbWF0Y2ggb3IgYml0 cy4gIFRoaXMgZmVlbHMgbGlrZSBvbmUgYXJlYSB3aGVyZSBpdCBtYXkgYmUgdmFsdWFibGUgdG8g ZG8gSUVURiBzdGFuZGFyZGl6YXRpb24gd29yayB0byBkZWZpbmUgYSBsYW5ndWFnZSBmb3Igc3Bl Y2lmeWluZyBzZW1hbnRpYyBhZGRyZXNzIG1hdGNoZXMgb3IgcGF0dGVybnMuICBUaGlzIHdheSBz ZW1hbnRpYyBhZGRyZXNzZXMgY291bGQgYmUgdXNlZnVsbHkgY29tbXVuaWNhdGVkIGJldHdlZW4g cGFydGllcyBhbmQgZGV2aWNlcyB3aXRoaW4gYW4gb3JnYW5pemF0aW9uLCBhcyB3ZWxsIGFzIGJl dHdlZW4gb3JnYW5pemF0aW9ucy4gIElkZWFsbHkgdGhpcyB3b3VsZCBiZSBpbXBsZW1lbnRlZCBp biByb3V0ZXJzIGFuZCBvdGhlciBuZXR3b3JrIGRldmljZXMgKHN1Y2ggYXMgdG8gYWxsb3cgdGhl IGFwcGxpY2F0aW9uIG9mIHBhY2tldCBmaWx0ZXJpbmcgYmFzZWQgb24gdGhlc2Ugc2VtYW50aWMg YWRkcmVzcyBtYXRjaGVzKS4NCg0KPHNoZW5nPiBUaGlzIGlzIG9uZSBvZiB0aGUgZ2FwcyB3ZSBo YXZlIGlkZW50aWZpZWQgaW4gdGhlIGZyYW1ld29yayBkb2N1bWVudC4gU28gZnVsbHkgYWdyZWUs IGFsc28gdGhlIGJlbG93IGV4YW1wbGUgbG9va3MgZ29vZC4gSG93ZXZlciwgSSBhbSBub3Qgc3Vy ZSB3aGV0aGVyIGl0IGlzIHRvbyBlYXJseSB0byBkZXNpZ24gdGhpcy4gV2Ugc2hvdWxkIGdldCB0 aGUgYmFzaWMgaWRlYSAoZnJhbWV3b3JrIGRvY3VtZW50KSBhY2NlcHRlZCBmaXJzdC4NCkJlc3Qg cmVnYXJkcywNClNoZW5nDQoNCkV4cGFuZGluZyBvbiB0aGF0IGxhc3QgcG9pbnQgYWJvdXQgYWxs b3dpbmcgc2VtYW50aWMgbWF0Y2hlcyB0byBiZSBzcGVjaWZpZWQsIGFuIGluaXRpYWwgcHJvcG9z YWwgaXMgdGhhdCB0aGlzIGNvbnNpc3RzIG9mIHRocmVlIHBhcnRzOiAgIGFuIGFkZHJlc3MgcHJl Zml4IG9yIHNldCBvZiBwcmVmaXhlcyAodGhlIGNvbnRleHQgd2l0aGluIHRoZSBzZW1hbnRpYyBt YXRjaCBhcHBsaWVzKSwgYSBtYXNrIChzcGVjaWZ5aW5nIHdoaWNoIGJpdHMgaGF2ZSBzZW1hbnRp Y3MpLCBhbmQgYSB2YWx1ZSAodGhlIHZhbHVlIG9mIHRoZSBiaXRzIGFmdGVyIG1hc2tpbmcgdGhl IGFkZHJlc3MpLiAgT25jZSB0aGVyZSBpcyBhIGxhbmd1YWdlIHRvIHRhbGsgYWJvdXQgdGhlc2Ug bWF0Y2hlcywgaXQgYmVjb21lcyBwb3NzaWJsZSB0byBhcHBseSBwb2xpY2llcyBiYXNlZCBvbiB0 aGVzZSBtYXRjaGVzLg0KDQpGb3IgZXhhbXBsZSwgaWYgYW4gb3JnYW5pemF0aW9uIGhhcyB0aGUg bmV0d29yayAyMDAxOmRiODo6LzMyIGFuZCBkZWNpZGVzIHRoYXQgYml0cyA0OC01MSBzcGVjaWZ5 IHRoZSBzdWJzY3JpYmVyIHR5cGUgKGVnLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zdW4tc2VtYW50aWMtdXNlY2FzZS0wMSBzZWN0aW9uIDIpLCBpdCB3b3VsZCBiZSBwb3NzaWJs ZSB0byBzcGVjaWZ5IHdpZmkgc3Vic2NyaWJlcnMgd2l0aDoNCg0KICAgICAgICAgICAgeyBwcmVm aXg6ICIyMDAxOmRiODo6LzMyIiwgbWFzazogIjA6MDowOmYwMDA6OiIsIHZhbHVlczogWyAiMDow OjA6YTAwMDo6IiwgIjA6MDowOmIwMDA6OiIgXSB9DQoNCkZvciBhbm90aGVyIGV4YW1wbGUsIHNv bWUgb3RoZXIgb3JnYW5pemF0aW9uIG1pZ2h0IHdhbnQgdG8gYXBwbHkgYSBwb2xpY3kgdG8gYWxs IGRldmljZXMgd2l0aCBhIHBhcnRpY3VsYXIgRVVJLTY0IHZhbHVlICgiQUM6REU6NDgiKSB3aXRo aW4gdGhlaXIgbmV0d29yayAoZWcsIHRvIGRvIHNvbWUgZXh0cmEgbG9nZ2luZyBmb3IgZGVidWdn aW5nKS4NClRoZXkgbWlnaHQgdGhlbiBzcGVjaWZ5IHRoYXQgd2l0aDoNCg0KICAgICAgICAgICAg eyBwcmVmaXg6ICIyMDAxOmRiODphYmNkOjovNDgiLCBtYXNrOiAiOjpmZmZmOmZmZmY6ZmYwMDow IiwgdmFsdWU6ICI6OmFjZGU6NDhmZjpmZTAwOjAiIH0NCg0KQW5vdGhlciBleGFtcGxlIG1pZ2h0 IGJlIGZvciBhbiBvcmdhbml6YXRpb24gdGhhdCBhbHdheXMgcnVucyBhIHBhcnRpY3VsYXIgdmly dHVhbCBzZXJ2ZXIgaG9zdCBvbiBhZGRyZXNzZXMgZW5kaW5nIHdpdGggIjo6MTIzNCIgdG8gY29t bXVuaWNhdGUgdGhhdCBhczoNCg0KICAgICAgICAgICB7IHByZWZpeGVzOiBbICIyMDAxOmRiODph YmNkOjovNDgiLCAiMjAwMTpkYjg6YWJjZTo6LzQ4IiBdLCBtYXNrOiAiOjpmZmZmIiwgdmFsdWU6 ICI6OjEyMzQiIH0NCg0KVGhlIEpTT04gbm90YXRpb24gYWJvdmUgaXMganVzdCBvbmUgZXhhbXBs ZSAtLS0gdGhlcmUgbWF5IGJlIHNvbWUgb3RoZXIgc3ludGF4IG1vcmUgZnJpZW5kbHkgdG8gbW9y ZSByb3V0ZXIgY29uZmlndXJhdGlvbiBsYW5ndWFnZXMuDQpIYXZpbmcgc29tZSBzdGFuZGFyZCBu b3RhdGlvbiBsaWtlIHRoaXMgdGhhdCBzcGVjaWZpZXMgYSBtYXNrLCBtYXNrZWQgdmFsdWUocyks IGFuZCB0aGUgYXBwbGljYWJsZSBwcmVmaXgoZXMpIHdvdWxkIG1ha2Ugc2VtYW50aWMgcHJlZml4 aW5nDQooYW5kIHNlbWFudGljIGFkZHJlc3NpbmcgaW4gZ2VuZXJhbCkgbXVjaCBtb3JlIHZpYWJs ZSBmb3IgdGhvc2UgbmV0d29ya3Mgb3Igb3BlcmF0b3JzIGZvciB3aG9tIGl0IG1ha2VzIHNlbnNl IHdpdGhpbiB0aGVpciBlbnZpcm9ubWVudA0KYXMgdGhlcmUgd291bGQgdGhlbiBiZSBzb21lIHdh eSB0byBjb21tdW5pY2F0ZSBhbmQgdXNlIGl0Lg0KDQogICAgICAgRXJpaw0KDQoNCk9uIFR1ZSwg T2N0IDIzLCAyMDEyIGF0IDU6NTQgQU0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5j b208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksIGFsbCwNCg0KVHdv IHNlbWFudGljIElQdjYgcHJlZml4IGhhdmUgYmVlbiBzdWJtaXR0ZWQgdG8gSUVURi4gQ291bGQg eW91IHBsZWFzZSByZXZpZXcgdGhlbT8gQW55IGNvbW1lbnRzL3N1Z2dlc3Rpb25zL2FkdmljZXMg YXJlIGFwcHJlY2lhdGVkLg0KDQpBIEZyYW1ld29yayBmb3IgU2VtYW50aWMgSVB2NiBQcmVmaXgg YW5kIEdhcCBBbmFseXNpcywgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmct djZvcHMtc2VtYW50aWMtcHJlZml4LTAxDQoNClVzZSBjYXNlIG9mIElQdjYgcHJlZml4IHNlbWFu dGljcyBmb3Igb3BlcmF0b3JzLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdW4t c2VtYW50aWMtdXNlY2FzZS0wMQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nICsgUWlvbmcNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWls aW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8F56Cszxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksIEVyaWssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyBmb3IgeW91ciBlbWFpbCBhbmQgc3VwcG9ydC4gU29tZSBkZXRhaWxlZCByZXBsaWVz IGluIGxpbmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGVuZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBueWdyZW5AZ21haWwuY29tIFttYWlsdG86bnlncmVuQGdt YWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpayBOeWdyZW48YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgTm92ZW1iZXIgMjAsIDIwMTIgNzo0MSBBTTxicj4NCjxiPlRvOjwvYj4gU2hl bmcgSmlhbmc8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnOyBzdW5xaW9uZzsgaWV0ZkBj aGVlc3kuc2Fja2hlYWRzLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBTZW1h bnRpYyBJUHY2IFByZWZpeCBkcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBjb25jZXB0IG9mIHNlbWFudGljIGFk ZHJlc3NpbmcgaXMgY2VydGFpbmx5IHVzZWZ1bCBpbiBzb21lIGNvbnRleHRzLCBhbmQgaXQgZG9l cyBmZWVsIGxpa2UgYW4gYXJlYSB3aGVyZSBoYXZpbmcgc29tZSBzdGFuZGFyZHMgYW5kIHNoYXJl ZCBiZXN0IHByYWN0aWNlcyBjb3VsZCBiZSB1c2VmdWwuPGJyPg0KPGJyPg0KU29tZSBwYXJ0aWN1 bGFyIGZlZWRiYWNrOjxicj4NCjxicj4NCiogSSB0aGluayBpdCBpcyBjcml0aWNhbCB0byBiZSBj bGVhciB0aGF0IGFueSBzZW1hbnRpYyBhZGRyZXNzaW5nIGlzIG9ubHkgbWVhbmluZ2Z1bCB3aXRo aW4gYWRtaW5pc3RyYXRpdmUvb3BlcmF0aW9uYWwgZG9tYWlucyAoc3VjaCBhcyB3aXRoaW4gYW4g YWRkcmVzcyBwcmVmaXggY29udHJvbGxlZCBieSBhbiBvcmdhbml6YXRpb24pLjxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtz aGVuZyZndDsgZnVsbHkgYWdyZWUuIFRoYXTigJlzIHdoeSB3ZSBkZWZpbmVzIHRoZSBTZW1hbnRp YyBQcmVmaXggRG9tYWluIHRvIGNsZWFybHkgZHJhdyB0aGUgYm9yZGVycy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQoqIFNlbWFudGljIGFkZHJlc3NpbmcgaGFzIGFw cGxpY2F0aW9ucyBvdXRzaWRlIG9mIGp1c3Qgc2VtYW50aWMgcHJlZml4ZXMuJm5ic3A7IFRoZXJl IGFyZSBjZXJ0YWlubHkgY2FzZXMgd2hlcmUgaGF2aW5nIGFkZHJlc3Mgc2VtYW50aWNzIG91dHNp ZGUgb2YgdGhlIHByZWZpeCAoaWUsIGluIHRoZSBib3R0b20gNjQgYml0cykgd291bGQgYWxzbyBi ZSB2YWx1YWJsZSwgYWx0aG91Z2ggdGhpcyBoYXMgZGlmZmVyZW50IGNvbnNpZGVyYXRpb25zIGFz IHRvIHNlY3VyaXR5DQogYW5kIGludGVyYWN0aW9uIHdpdGggYWRkcmVzcyBhc3NpZ25tZW50Ljxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZsdDtzaGVuZyZndDtUaGlzIGlzIGFuIGludGVyZXN0aW5nIHVzZSBjYXNlLiBXZSBkaWQg Y29uc2lkZXIgaXQgYmVmb3JlLiBCdXQgd2Ugd2VyZSBub3Qgc3VyZSBob3cgdGhlc2UgYWRkcmVz cyBjYW4gYmUgdHJ1c3RlZC4NCiBJZiB5b3Ugb25seSBjb25zaWRlciBESENQdjYgYXNzaWduaW5n IGFkZHJlc3MgbW9kZWwsIHRoaXMgaXMgYSB2YWx1YWJsZSB1c2UgY2FzZSAod2UgbWF5IHdyaXRl IG90aGVyIGRyYWZ0IGZvciB0aGlzLCBJIGd1ZXNzKS4gQnV0IGlmIHlvdSBjb25zaWRlciBTTEFB QywgdGhlIGhvc3QgZ2VuZXJhdGVkIGludGVyZmFjZSBJRCBhcmUgbm90IHRydXN0ZWQgZm9yIHNl bWFudGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQoqIEEgYmln IG1pc3NpbmcgcGllY2Ugb2Ygc2VtYW50aWMgYWRkcmVzc2luZyBpcyBhIHN0YW5kYXJkIHdheSBv ZiBjb21tdW5pY2F0aW5nIHRoZSBzZW1hbnRpYyBtYXRjaCBvciBiaXRzLiZuYnNwOyBUaGlzIGZl ZWxzIGxpa2Ugb25lIGFyZWEgd2hlcmUgaXQgbWF5IGJlIHZhbHVhYmxlIHRvIGRvIElFVEYgc3Rh bmRhcmRpemF0aW9uIHdvcmsgdG8gZGVmaW5lIGEgbGFuZ3VhZ2UgZm9yIHNwZWNpZnlpbmcgc2Vt YW50aWMgYWRkcmVzcyBtYXRjaGVzIG9yIHBhdHRlcm5zLiZuYnNwOw0KIFRoaXMgd2F5IHNlbWFu dGljIGFkZHJlc3NlcyBjb3VsZCBiZSB1c2VmdWxseSBjb21tdW5pY2F0ZWQgYmV0d2VlbiBwYXJ0 aWVzIGFuZCBkZXZpY2VzIHdpdGhpbiBhbiBvcmdhbml6YXRpb24sIGFzIHdlbGwgYXMgYmV0d2Vl biBvcmdhbml6YXRpb25zLiZuYnNwOyBJZGVhbGx5IHRoaXMgd291bGQgYmUgaW1wbGVtZW50ZWQg aW4gcm91dGVycyBhbmQgb3RoZXIgbmV0d29yayBkZXZpY2VzIChzdWNoIGFzIHRvIGFsbG93IHRo ZSBhcHBsaWNhdGlvbiBvZiBwYWNrZXQNCiBmaWx0ZXJpbmcgYmFzZWQgb24gdGhlc2Ugc2VtYW50 aWMgYWRkcmVzcyBtYXRjaGVzKS48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7c2hlbmcmZ3Q7IFRoaXMgaXMgb25lIG9mIHRo ZSBnYXBzIHdlIGhhdmUgaWRlbnRpZmllZCBpbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50LiBTbyBm dWxseSBhZ3JlZSwgYWxzbyB0aGUgYmVsb3cgZXhhbXBsZQ0KIGxvb2tzIGdvb2QuIEhvd2V2ZXIs IEkgYW0gbm90IHN1cmUgd2hldGhlciBpdCBpcyB0b28gZWFybHkgdG8gZGVzaWduIHRoaXMuIFdl IHNob3VsZCBnZXQgdGhlIGJhc2ljIGlkZWEgKGZyYW1ld29yayBkb2N1bWVudCkgYWNjZXB0ZWQg Zmlyc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hlbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpFeHBhbmRpbmcgb24gdGhh dCBsYXN0IHBvaW50IGFib3V0IGFsbG93aW5nIHNlbWFudGljIG1hdGNoZXMgdG8gYmUgc3BlY2lm aWVkLCBhbiBpbml0aWFsIHByb3Bvc2FsIGlzIHRoYXQgdGhpcyBjb25zaXN0cyBvZiB0aHJlZSBw YXJ0czombmJzcDsmbmJzcDsgYW4gYWRkcmVzcyBwcmVmaXggb3Igc2V0IG9mIHByZWZpeGVzICh0 aGUgY29udGV4dCB3aXRoaW4gdGhlIHNlbWFudGljIG1hdGNoIGFwcGxpZXMpLCBhIG1hc2sgKHNw ZWNpZnlpbmcgd2hpY2ggYml0cyBoYXZlDQogc2VtYW50aWNzKSwgYW5kIGEgdmFsdWUgKHRoZSB2 YWx1ZSBvZiB0aGUgYml0cyBhZnRlciBtYXNraW5nIHRoZSBhZGRyZXNzKS4mbmJzcDsgT25jZSB0 aGVyZSBpcyBhIGxhbmd1YWdlIHRvIHRhbGsgYWJvdXQgdGhlc2UgbWF0Y2hlcywgaXQgYmVjb21l cyBwb3NzaWJsZSB0byBhcHBseSBwb2xpY2llcyBiYXNlZCBvbiB0aGVzZSBtYXRjaGVzLjxicj4N Cjxicj4NCkZvciBleGFtcGxlLCBpZiBhbiBvcmdhbml6YXRpb24gaGFzIHRoZSBuZXR3b3JrIDIw MDE6ZGI4OjovMzIgYW5kIGRlY2lkZXMgdGhhdCBiaXRzIDQ4LTUxIHNwZWNpZnkgdGhlIHN1YnNj cmliZXIgdHlwZSAoZWcsDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zdW4tc2VtYW50aWMtdXNlY2FzZS0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc3VuLXNlbWFudGljLXVzZWNhc2UtMDE8L2E+IHNlY3Rpb24gMiksIGl0IHdvdWxkIGJlIHBv c3NpYmxlIHRvIHNwZWNpZnkgd2lmaSBzdWJzY3JpYmVycyB3aXRoOjxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB7IHByZWZpeDogJnF1b3Q7MjAwMTpkYjg6Oi8zMiZxdW90OywgbWFzazogJnF1b3Q7MDow OjA6ZjAwMDo6JnF1b3Q7LCB2YWx1ZXM6IFsgJnF1b3Q7MDowOjA6YTAwMDo6JnF1b3Q7LCAmcXVv dDswOjA6MDpiMDAwOjomcXVvdDsgXSB9PGJyPg0KPGJyPg0KRm9yIGFub3RoZXIgZXhhbXBsZSwg c29tZSBvdGhlciBvcmdhbml6YXRpb24gbWlnaHQgd2FudCB0byBhcHBseSBhIHBvbGljeSB0byBh bGwgZGV2aWNlcyB3aXRoIGEgcGFydGljdWxhciBFVUktNjQgdmFsdWUgKCZxdW90O0FDOkRFOjQ4 JnF1b3Q7KSB3aXRoaW4gdGhlaXIgbmV0d29yayAoZWcsIHRvIGRvIHNvbWUgZXh0cmEgbG9nZ2lu ZyBmb3IgZGVidWdnaW5nKS48YnI+DQpUaGV5IG1pZ2h0IHRoZW4gc3BlY2lmeSB0aGF0IHdpdGg6 PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgcHJlZml4OiAmcXVvdDsyMDAxOmRiODphYmNkOjovNDgm cXVvdDssIG1hc2s6ICZxdW90Ozo6ZmZmZjpmZmZmOmZmMDA6MCZxdW90OywgdmFsdWU6ICZxdW90 Ozo6YWNkZTo0OGZmOmZlMDA6MCZxdW90OyB9PGJyPg0KPGJyPg0KQW5vdGhlciBleGFtcGxlIG1p Z2h0IGJlIGZvciBhbiBvcmdhbml6YXRpb24gdGhhdCBhbHdheXMgcnVucyBhIHBhcnRpY3VsYXIg dmlydHVhbCBzZXJ2ZXIgaG9zdCBvbiBhZGRyZXNzZXMgZW5kaW5nIHdpdGggJnF1b3Q7OjoxMjM0 JnF1b3Q7IHRvIGNvbW11bmljYXRlIHRoYXQgYXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsgcHJlZml4ZXM6 IFsgJnF1b3Q7MjAwMTpkYjg6YWJjZDo6LzQ4JnF1b3Q7LCAmcXVvdDsyMDAxOmRiODphYmNlOjov NDgmcXVvdDsgXSwgbWFzazogJnF1b3Q7OjpmZmZmJnF1b3Q7LCB2YWx1ZTogJnF1b3Q7OjoxMjM0 JnF1b3Q7IH08YnI+DQo8YnI+DQpUaGUgSlNPTiBub3RhdGlvbiBhYm92ZSBpcyBqdXN0IG9uZSBl eGFtcGxlIC0tLSB0aGVyZSBtYXkgYmUgc29tZSBvdGhlciBzeW50YXggbW9yZSBmcmllbmRseSB0 byBtb3JlIHJvdXRlciBjb25maWd1cmF0aW9uIGxhbmd1YWdlcy48YnI+DQpIYXZpbmcgc29tZSBz dGFuZGFyZCBub3RhdGlvbiBsaWtlIHRoaXMgdGhhdCBzcGVjaWZpZXMgYSBtYXNrLCBtYXNrZWQg dmFsdWUocyksIGFuZCB0aGUgYXBwbGljYWJsZSBwcmVmaXgoZXMpIHdvdWxkIG1ha2Ugc2VtYW50 aWMgcHJlZml4aW5nDQo8YnI+DQooYW5kIHNlbWFudGljIGFkZHJlc3NpbmcgaW4gZ2VuZXJhbCkg bXVjaCBtb3JlIHZpYWJsZSBmb3IgdGhvc2UgbmV0d29ya3Mgb3Igb3BlcmF0b3JzIGZvciB3aG9t IGl0IG1ha2VzIHNlbnNlIHdpdGhpbiB0aGVpciBlbnZpcm9ubWVudDxicj4NCmFzIHRoZXJlIHdv dWxkIHRoZW4gYmUgc29tZSB3YXkgdG8gY29tbXVuaWNhdGUgYW5kIHVzZSBpdC48YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpazxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBPY3QgMjMsIDIwMTIgYXQgNTo1NCBBTSwgU2hlbmcg SmlhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20iIHRhcmdldD0i X2JsYW5rIj5qaWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksIGFs bCw8YnI+DQo8YnI+DQpUd28gc2VtYW50aWMgSVB2NiBwcmVmaXggaGF2ZSBiZWVuIHN1Ym1pdHRl ZCB0byBJRVRGLiBDb3VsZCB5b3UgcGxlYXNlIHJldmlldyB0aGVtPyBBbnkgY29tbWVudHMvc3Vn Z2VzdGlvbnMvYWR2aWNlcyBhcmUgYXBwcmVjaWF0ZWQuPGJyPg0KPGJyPg0KQSBGcmFtZXdvcmsg Zm9yIFNlbWFudGljIElQdjYgUHJlZml4IGFuZCBHYXAgQW5hbHlzaXMsIDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0w MSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAxPC9hPjxicj4NCjxicj4NClVzZSBjYXNlIG9mIElQ djYgcHJlZml4IHNlbWFudGljcyBmb3Igb3BlcmF0b3JzLCA8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zdW4tc2VtYW50aWMtdXNlY2FzZS0wMSIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3VuLXNlbWFudGljLXVzZWNh c2UtMDE8L2E+PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCjxicj4NClNoZW5nICYjNDM7 IFFpb25nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0 Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8F56Cszxeml545mbxchi_-- From jouni.nospam@gmail.com Tue Nov 20 00:35:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A321F85EF for ; Tue, 20 Nov 2012 00:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u96HBbUQCwLV for ; Tue, 20 Nov 2012 00:35:57 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD34521F85EA for ; Tue, 20 Nov 2012 00:35:56 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4723967lbk.31 for ; Tue, 20 Nov 2012 00:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KDVGeNgkEbsAffBhVOimnWPyqz6oFuFOJfSPXJoDyWk=; b=aBZEUoy7ExtvbtCpDLBKZg8rm5h3SoqjTaQOWfI/vXUzr5lT5gcmx5A9LxpMavoXNn ZVOhuTXfXgA9zXcRzscEN8d0nH/49x+TqG57iCu3aG8onEA0PddfcYNYAUZpiWpWBptd ZM72acnnWT6GT8UTQ1VmkBsoYTs8WEZj+NtmNVzKeoyNGX8s3YoyIVD7kT6tqQ2fzAiP bGgxYtOMJBFZbkcN06Nwv5ef04QLCNOfvV2bnxhQ3UD2GiLDDc0fNzlW+opPgpQbAcez x5NQd8Mws5P6rRa3IK+QWz+W9UUa8kIrkJeUqkDxMXv2pME48yFzv35zAcYzp7D0ioh8 wG+Q== Received: by 10.152.128.9 with SMTP id nk9mr6950314lab.17.1353400555546; Tue, 20 Nov 2012 00:35:55 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id lv1sm4438313lab.14.2012.11.20.00.35.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 00:35:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751E536@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 20 Nov 2012 10:35:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> <6F49F841-FD9E-4996-9C17-245F46C6EABE@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E536@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1085) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Nov 2012 08:35:58 -0000 On Nov 19, 2012, at 9:30 AM, = wrote: > Hi Jouni, >=20 > The question of overlapping is not important IMHO as the two documents = are targeting distinct objectives. I thought you agreed with this point = (below an excerpt from the minutes): I agree these document have different objectives. That is clear. Still = it does not make sense to repeat IPv6 related requirements in normative = language that are part of the generic cellular host IPv6 requirement. = Even after the change I proposed, there still are many deployment & = profile issues that are not covered anywhere except in draft-binet-*. - Jouni >=20 > " > Lorenzo C - Doc 1 is a shopping list document 2 is a treatis on how > you implment ipv6 on 3316. they're not covering the same domain >=20 > Jouni K - Agree with Lorenzo - different objectives so they need to be > treated differently > " >=20 > If now you are claiming yours is also doing what draft-binet-* does, = I'm puzzled then... >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >> Envoy=E9 : dimanche 18 novembre 2012 00:14 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : v6ops@ietf.org WG >> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>=20 >>=20 >> Hi, >>=20 >> Likewise rfc3316bis assumes IPv6-only or dual-stack. Point=20 >> being, rfc3316bis does not do in direction that is not=20 >> necessary to run IPv6 (in a possibly multi interfaced host).=20 >> IMHO the rest like NAT related recommendations, transition=20 >> recommendations, WLAN specifics, tethering recommendations are=20 >> then well served in draft-bonet-*. >>=20 >> - Jouni >>=20 >> On Nov 16, 2012, at 3:17 PM, =20 >> wrote: >>=20 >>> Re-, >>>=20 >>> draft-binet-* assumes both DS and IPv6-only deployment=20 >> modes. Nothing specific there. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >>>> Envoy=E9 : vendredi 16 novembre 2012 14:09 >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>> Cc : v6ops@ietf.org WG >>>> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 >>>>=20 >>>>=20 >>>> Med, >>>>=20 >>>> I still see no reason to replicate information since what=20 >>>> comes to "a pure IPv6 profile for a 3GPP link", it should be=20 >>>> exactly the same in both documents. I am just trying to avoid=20 >>>> misalignment now and in the future. I would also argue that=20 >>>> draft-binet-* is a profile for a specific deployment(s) in=20 >>>> mind, not a generic IPv6 profile for cellular. It is a way=20 >>>> more (not that it would be a bad thing though..). >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>> On Nov 16, 2012, at 2:07 PM, =20 >>>> wrote: >>>>=20 >>>>> Hi Jouni, >>>>>=20 >>>>> What I understood from the v6ops meeting is that wg=20 >>>> participants see these two documents have distinct objectives.=20 >>>> As such the question of overlapping does not apply as these=20 >>>> documents serve two distinct objectives. Furthermore, because=20 >>>> draft-binet-*'s objective is to define an IPv6 profile for=20 >>>> cellular, we prefer the document be self-contained and use=20 >>>> consistent language for all requirements. >>>>>=20 >>>>> Cheers, >>>>> Med=20 >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Jouni [mailto:jouni.nospam@gmail.com]=20 >>>>>> Envoy=E9 : jeudi 15 novembre 2012 16:40 >>>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>>>> Cc : v6ops@ietf.org; Mikael Abrahamsson; Pete Vickers >>>>>> Objet : Re: [v6ops]=20 >> draft-binet-v6ops-cellular-host-requirements-01 >>>>>>=20 >>>>>>=20 >>>>>> Med, >>>>>>=20 >>>>>> I am slightly confused about the overlap of=20 >>>>>> draft-binet-v6ops-* and draft-ietf-v6ops-rfc3316bis. My=20 >>>>>> recollection was that overlaps were supposed to be removed and=20 >>>>>> then concentrate on the remaining part in draft-binet-v6ops-*,=20 >>>>>> no? This would concern requirements #1, #6, #7, #8, #9, #17,=20 >>>>>> #22, #23, #25, #26, #27. My recommendation would be removing=20 >>>>>> those and just reference to [draft-ietf-v6ops-rfc3316bis]=20 >>>>>> because the base IPv6 compliancy would come from there and I=20 >>>>>> see no reason to repeat those here. >>>>>>=20 >>>>>> Then a question about the relevance of #24. Given the current=20 >>>>>> bandwidth in 3G/LTE is there really a need to compress=20 >>>>>> headers? And if people really see it as a life critical=20 >>>>>> feature to have, I would appreciate listing the ROHC profiles=20 >>>>>> that are essential (e.g., align with IR.92 & IR.58 that will=20 >>>>>> be implemented on the network side). >>>>>>=20 >>>>>> - Jouni >>>>>>=20 >>>>>>=20 >>>>>> On Nov 15, 2012, at 4:59 PM, =20 >>>>>> wrote: >>>>>>=20 >>>>>>> Dear all, >>>>>>>=20 >>>>>>> We submitted a new version of the draft to take into account=20 >>>>>> the comments received from M. Abrahamsson and P. Vickers. >>>>>>>=20 >>>>>>> The main changes are: >>>>>>>=20 >>>>>>> * Add some clarification text for REQ#3 >>>>>>> * Mention stateless dhcpv6 is useful to retrieve other=20 >>>>>> information than DNS >>>>>>> * Re-word REQ#15 >>>>>>> * Cite "Happy Eyeballs" in REQ#16 >>>>>>> * Update the text of REQ#17 >>>>>>> * Add two sub-requirements to REQ#19: IPv6-only=20 >>>> connectivity + SLAAC >>>>>>> * Precise the ordering in REQ#21 >>>>>>>=20 >>>>>>> A more detailed diff is available at: >>>>>>>=20 >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>>>> t-requirements-01 >>>>>>>=20 >>>>>>>=20 >>>>>>> Chairs, would it be possible to issue a Call For Adoption=20 >>>>>> for this document? Thanks. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Med >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>> internet-drafts@ietf.org >>>>>>> Envoy=E9 : jeudi 15 novembre 2012 15:53 >>>>>>> =C0 : i-d-announce@ietf.org >>>>>>> Objet : I-D Action:=20 >>>>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>> Internet-Drafts directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : Internet Protocol Version 6 (IPv6)=20 >>>>>> Requirements for Cellular Hosts >>>>>>> Author(s) : David Binet >>>>>>> Mohamed Boucadair >>>>>>> Ales Vizdal >>>>>>> Cameron Byrne >>>>>>> Gang Chen >>>>>>> Filename :=20 >>>>>> draft-binet-v6ops-cellular-host-requirements-01.txt >>>>>>> Pages : 16 >>>>>>> Date : 2012-11-15 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document lists a set of IPv6-related requirements to be >>>>>>> supported by cellular hosts. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>>=20 >>>>>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >>>>>> t-requirements >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requ >>>>>> irements-01 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>>=20 >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >>>>>> t-requirements-01 >>>>>>>=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 >>>>>>=20 >>>>=20 >>=20 From diego@tid.es Tue Nov 20 14:22:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A399121F8821 for ; Tue, 20 Nov 2012 14:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF8QDtCOchRK for ; Tue, 20 Nov 2012 14:22:10 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id B676A21F8808 for ; Tue, 20 Nov 2012 14:22:09 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDT004IV4SW34@tid.hi.inet> for v6ops@ietf.org; Tue, 20 Nov 2012 23:22:08 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F3.B0.05494.0920CA05; Tue, 20 Nov 2012 23:22:08 +0100 (CET) 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 ESMTPS id <0MDT004IQ4SW34@tid.hi.inet> for v6ops@ietf.org; Tue, 20 Nov 2012 23:22:08 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Tue, 20 Nov 2012 23:21:30 +0100 Date: Tue, 20 Nov 2012 22:22:07 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: jouni korhonen Message-id: Content-id: <639492DA88F896439696809DF4881DB5@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 Thread-index: AQHNxvovV2CxcISmG0O3AhO5u/MphZfzFJQA X-AuditID: 0a5f4e69-b7fc06d000001576-e7-50ac02905c29 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe9nqDuBaU2Awa0Lihanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsHHJgXPuStW3HrL3sB4lrOLkZNDQsBE4uWLx0wQtpjEhXvr 2boYuTiEBLYxSkzv+cYM4fxglDjy8RmUMw0os+YBK0gLi4CqxNJjZ9lAbDYg+1Hzb3YQW1jA ReLlznZGEJtTwFbiwLO7UCsUJP6ce8wCYosIaEvMfjYHqJ6Dg1kgW+L9DHOQMK+At8TZ710s EGEzibfNDhBhQYkfk++BdTIL6Ej0fge5DcQWl2huvQkV15Z48u4C2GWMQM98P7WGCWKTq8Sp nuesELaRxOlpv1ggrhGQWLLnPDOELSrx8vE/VogX57NILH4/lXkCo8QshDNmITljFpIzZiE5 YxaSMxYwsq5iFCtOKspMzyjJTczMSTcw0svI1MvMSy3ZxAiJucwdjMt3qhxiFOBgVOLhdZi2 OkCINbGsuDL3EKMkB5OSKO9UhjUBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4/28EKudNSays Si3Kh0nJcHAoSfBeBWkTLEpNT61Iy8wBJhaYNBMHJ0g7D1A7DyNQDW9xQWJucWY6RP4Uo6SU OG8cSEIAJJFRmgfX+4pRHOhIYV51kCwPMAXCdb0CGsgENDDeBeSe4pJEhJRUA2PrayVnL/ug 9TfYGC53XOL/0mOx9sTX5wfvmu1ZY+Yk9tl4uruXPOt9/XMrdmY1sir8CrO8tVw3aHWp2eyD ck8d9+2ZM+VTfeJ/hlupb1Kfsn3f8+3ha7uIW3eablftWWZ3VDf+zXLVB1fdD01OOfvE+ITy n+PO3XzSvE8jDkZuud+ceGDGCZUjSizFGYmGWsxFxYkA1yRMQj4DAAA= References: <94C682931C08B048B7A8645303FDC9F36E95C9F86C@PUEXCB1B.nanterre.francetelecom.fr> <2A43389B-7D02-4B9B-B2CD-A3CDC4E6E26E@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E273@PUEXCB1B.nanterre.francetelecom.fr> <8344869F-B4D0-440B-8455-024046F76AD9@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E2D4@PUEXCB1B.nanterre.francetelecom.fr> <6F49F841-FD9E-4996-9C17-245F46C6EABE@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751E536@PUEXCB1B.nanterre.francetelecom.fr> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Nov 2012 22:22:10 -0000 Just let me support what I think is the common agreement expressed so far, that both documents are relevant for the WG. Be goode, On 20 Nov 2012, at 09:35 , jouni korhonen wrote: > > On Nov 19, 2012, at 9:30 AM, wrote: > >> Hi Jouni, >> >> The question of overlapping is not important IMHO as the two documents a= re targeting distinct objectives. I thought you agreed with this point (bel= ow an excerpt from the minutes): > > I agree these document have different objectives. That is clear. Still it= does not make sense to repeat IPv6 related requirements in normative langu= age that are part of the generic cellular host IPv6 requirement. Even after= the change I proposed, there still are many deployment & profile issues th= at are not covered anywhere except in draft-binet-*. -- "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 nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From lee@asgard.org Wed Nov 21 07:03:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4A321F8674 for ; Wed, 21 Nov 2012 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqd6X0INq8sO for ; Wed, 21 Nov 2012 07:03:01 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50E5221F862D for ; Wed, 21 Nov 2012 07:03:01 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qALF30if008951 for ; Wed, 21 Nov 2012 10:03:00 -0500 Received: (qmail 4815 invoked by uid 0); 21 Nov 2012 15:02:59 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.167) by 0 with ESMTPA; 21 Nov 2012 15:02:59 -0000 From: "Lee Howard" To: "'IPv6 Operations'" Date: Wed, 21 Nov 2012 10:02:58 -0500 Message-ID: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+w== Content-Language: en-us Subject: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Nov 2012 15:03:02 -0000 You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing solutions, since prepopulating PTRs like we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was interest, but not necessarily as a working group document. Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or dnsop wants it). Filename: draft-howard-isp-ip6rdns Revision: 05 Title: Reverse DNS in IPv6 for Internet Service Providers Creation date: 2012-11-20 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt Status: http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05 Abstract: In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. Thanks, Lee From julien.ietf@gmail.com Wed Nov 21 17:14:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF19A21E804A for ; Wed, 21 Nov 2012 17:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpS8b2H2H407 for ; Wed, 21 Nov 2012 17:14:41 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0060E21E8048 for ; Wed, 21 Nov 2012 17:14:40 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so507834dae.31 for ; Wed, 21 Nov 2012 17:14:40 -0800 (PST) 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=guscLPLD4dNrYeE2NlVocqNtz7Sg5KC6iKwWoYtKpH0=; b=HJ9EaD891f36teDK4xdqzcm6c371cE9dezUO1IO315ZfLn3lateC1pCERnRAoDTyEN Rvi/llwbtbZWyar+oQbd5+skbNby75H/wkMbgDstpxdc98khkDX5JhYdLp2bkuL5ihxX pzs0FZ+tFXbIcq2RGMar3nU+gNZtkJAcBWYL51O2UWAOnI7uBh1LcNAma0mV4xv9G2bO Im+9lRtgqSneuvGQx22Rc6f8SMSezUAcJ5C2NyURTwOYFG7JuYDjbHLap+jDqkVTb7eR 6QW7GOLf2o/Pit7SvlEco6ZSFg2tSdx9/mNYJ50kQtgNWJqkzrIZz5hg+HIhgDzOZsdI VUJg== MIME-Version: 1.0 Received: by 10.66.74.40 with SMTP id q8mr22310527pav.29.1353546880760; Wed, 21 Nov 2012 17:14:40 -0800 (PST) Received: by 10.68.127.163 with HTTP; Wed, 21 Nov 2012 17:14:40 -0800 (PST) Date: Wed, 21 Nov 2012 17:14:40 -0800 Message-ID: From: Julien Laganier To: v6ops@ietf.org, draft-byrne-v6ops-64share@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d042f937c03b9c904cf0b3171 Subject: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 01:14:41 -0000 --f46d042f937c03b9c904cf0b3171 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have a question regarding the interaction between NUD and the method described in this draft. The GGSN/PGW acting as a default router advertises via IPv6 RAs a /64 prefix over the point-to-point link to the User Equipment. Assuming the User Equipment employs the method described in this draft and uses "the 3GPP network assigned /64 to assign itself a /128 subnet address to the 3GPP radio interface for consistent network reachability and the same address with a /64 subnet to the tethered LAN interface.The tethered LAN interface may then advertise the /64 subnet to the LAN with RA." Now a host on the tethered LAN will configure an IPv6 address with SLAAC based on the advertized /64, and starts to use it. When a downlink packets sent towards a host on the tethered LAN arrives at the GGSN/PGW, who believes the /64 is onlink, if the GGSN/PGW attempts NUD towards that destination address, in the current description of the method the UE will not reply (it has configured only one /128 on its interface facing the 3GPP network). Thus it seems GGSN/PGW initiated NUD will fail. So it seems to me that the current method would work only if a) the GGSN/PGW doesn't perform NUD for downlink packets sent over the point-to-point link, or b) the UE answers NUD probes for all addresses in the /64. Is this correct? Thanks, --julien --f46d042f937c03b9c904cf0b3171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have a question regarding the interaction betwe= en NUD and the method described in this draft.

The GGSN/= PGW acting as a default router=A0advertises=A0via IPv6 RAs a /64 prefix ove= r the point-to-point link to the User Equipment.=A0

Assuming the User Equipment employs the method describe= d in this draft=A0=A0and=A0uses "the 3GPP network assigned /64 to assign=A0itself a /128 su= bnet address to the 3GPP radio interface for=A0consistent network reachabil= ity and the same address with a /64=A0subnet to the tethered LAN interface.= The tethered LAN interface may=A0then advertise the /64 subnet to the LAN w= ith RA."

Now a host on the tethered LAN will configure an IPv6 a= ddress with SLAAC based on the advertized /64, and starts to use it.=A0

When a downlink packets sent towards a host on the te= thered LAN arrives at the GGSN/PGW, who believes the /64 is onlink, if the = GGSN/PGW attempts NUD towards that destination address, in the current desc= ription of the method the UE will not reply (it has configured only one /12= 8 on its interface facing the 3GPP network). Thus it seems GGSN/PGW initiat= ed NUD will fail.

So it seems to me that the current method would work on= ly if a) the GGSN/PGW doesn't perform NUD for downlink packets sent ove= r the point-to-point link, or b) the UE answers NUD probes for all addresse= s in the /64.

Is this correct?

Thanks,
=

--julien


--f46d042f937c03b9c904cf0b3171-- From cb.list6@gmail.com Wed Nov 21 19:47:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB9F21E805A for ; Wed, 21 Nov 2012 19:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltKelvB4FAbf for ; Wed, 21 Nov 2012 19:47:26 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0510B21E8053 for ; Wed, 21 Nov 2012 19:47:25 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so6462216lbk.31 for ; Wed, 21 Nov 2012 19:47:25 -0800 (PST) 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=s7LEu+3qpLHvx1SvWis03bxgto/W6NVQRFpxr6K6ps0=; b=PYAKAgx5XirCb7bJG2TdqpewgokZX9szQiG2VC+SqcvXMMMBJiridcEjbo3PcPjo8T qI5qMxwGqXcl5glEp/9wHMDZCQ2WCAKmyS2bnGMZl2GB3UEfbtw7eCU+HP/55+6Z++vI nw5cNG5ahMvuCO4XvpklqdMIi7jeCm9J2cFBiEXpEiCyxdBTGeHBdSxc8tOh+9jP5drV IF0TlJxSuWq2hX0pnsk6iD6l1SO/ENn2sw1Z9cQc7qG+5lII28rmLEE3zgYM3S6nEc+a oHHnhIw5U7IWQm3/iLlyJHkGf9U62Tw0GUicBhkg0kTe478fkh7BVGpvFJflCIWM9d5y zIDw== MIME-Version: 1.0 Received: by 10.112.49.133 with SMTP id u5mr36660lbn.105.1353556044943; Wed, 21 Nov 2012 19:47:24 -0800 (PST) Received: by 10.112.81.167 with HTTP; Wed, 21 Nov 2012 19:47:24 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Nov 2012 19:47:24 -0800 Message-ID: From: Cameron Byrne To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-byrne-v6ops-64share@tools.ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 03:47:27 -0000 On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier wrote: > Hello, > > I have a question regarding the interaction between NUD and the method > described in this draft. > > The GGSN/PGW acting as a default router advertises via IPv6 RAs a /64 prefix > over the point-to-point link to the User Equipment. > > Assuming the User Equipment employs the method described in this draft and > uses "the 3GPP network assigned /64 to assign itself a /128 subnet address > to the 3GPP radio interface for consistent network reachability and the same > address with a /64 subnet to the tethered LAN interface.The tethered LAN > interface may then advertise the /64 subnet to the LAN with RA." > > Now a host on the tethered LAN will configure an IPv6 address with SLAAC > based on the advertized /64, and starts to use it. > > When a downlink packets sent towards a host on the tethered LAN arrives at > the GGSN/PGW, who believes the /64 is onlink, if the GGSN/PGW attempts NUD > towards that destination address, in the current description of the method > the UE will not reply (it has configured only one /128 on its interface > facing the 3GPP network). Thus it seems GGSN/PGW initiated NUD will fail. > > So it seems to me that the current method would work only if a) the GGSN/PGW > doesn't perform NUD for downlink packets sent over the point-to-point link, > or b) the UE answers NUD probes for all addresses in the /64. > > Is this correct? > AFAIK, the GGSN/PGW does not do NUD. The /64 is considered off-link [1] and therefore no host resolution is done [1] http://tools.ietf.org/html/rfc6459#section-5.2 CB > Thanks, > > --julien > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From denghui02@gmail.com Wed Nov 21 23:18:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B069121F8894 for ; Wed, 21 Nov 2012 23:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 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_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8wNXG-AI87u for ; Wed, 21 Nov 2012 23:18:07 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9B21F888E for ; Wed, 21 Nov 2012 23:18:06 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so6034572qca.31 for ; Wed, 21 Nov 2012 23:18:06 -0800 (PST) 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=X2ZiZJKaVz4VaHdB9pwOSbVJJITeXhk+fcm//fnqRBc=; b=rKZxis2caZveYY/ZiagLjlwWDCJEb7ltFoW4xgk8mj2uwyD7cg4t4lJKBhJNDhgb46 UBNoixKndhgA2e94q8BxhNtIoXf3w8uaIlQtTRFhJtrARVtYpYRAyVIQvcpdXqq9AVck EwKkHGSy7iDH03NxTM+pFT7BMyq49gEqKdoAubM764lSbwhHcOIwhcOkAPE6EETmEyZE mydgXOSSm2GUkrRxrgidiGUVcJM4rYuB51aqXJT6lPKYPFbWsX26dup48vlH5JkBUM31 9pFvZYjqdsgyxZcq7dsYUml4yUn9QyylvLByjC8d6utcI6DNSVigAgMdXmvDrO7EiYkF hfIA== MIME-Version: 1.0 Received: by 10.49.83.129 with SMTP id q1mr24309093qey.11.1353568686266; Wed, 21 Nov 2012 23:18:06 -0800 (PST) Received: by 10.49.86.232 with HTTP; Wed, 21 Nov 2012 23:18:05 -0800 (PST) In-Reply-To: <45B89E2C-1BB2-4212-9126-B1F377784474@gmail.com> References: <45B89E2C-1BB2-4212-9126-B1F377784474@gmail.com> Date: Thu, 22 Nov 2012 15:18:05 +0800 Message-ID: From: Hui Deng To: jouni korhonen Content-Type: multipart/alternative; boundary=047d7b676164b95add04cf104491 Cc: v6ops@ietf.org Subject: Re: [v6ops] Clarifications on draft-ietf-v6ops-rfc3316bis-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, 22 Nov 2012 07:18:07 -0000 --047d7b676164b95add04cf104491 Content-Type: text/plain; charset=ISO-8859-1 Excuse me quite late reply, inline please. 2012/11/18 jouni korhonen > Hi, > > On Nov 17, 2012, at 6:56 PM, Hui Deng wrote: > > > Hello, authors, > > > > in section 2.11, it says > > "learning the DNS server addresses from the link layer signaling can be > cumbersome when the MT > > and the TE are separated using other techniques than PPP interface" > > Can you be more specific about what else could be used? and what can be > cumbersome? > > Like proprietary APIs or USB cdc etc between the MT and the TE. There > might not be "easy" or standard way to let the TE stack to learn DNS > information that the network sent in NAS signaling. PPP had one. Learning > the DNS information using IP protocols between the TE stack and the gateway > just makes the MT implementation easier and avoids OS specific hacks there. > I thought propriatary way also works, but if you think so, please add some text in the current draft. > > > for privacy consideration, > > can you help to write some analysis text about the relationship with > "always on capability in 3GPP" > > Do you mean analysis of a cellular host having the same prefix in use for > a long periods of time? > What I mean is in the case of LTE, it will keep one IP address or IPv6 prefix to allow its always on which keep PDP context. > > > Does SIPTO/LIPA has some influence on this document? > > I am not sure yet. Maybe a recommendation to use DNA might be useful here? > In the case of SIPTO/LIPA, UE will has two PDP connections and two IP addresses assigned. does it make some level difference? thanks for your discussion -Hui > > - Jouni > > > > > > > thanks > > > > -Hui > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b676164b95add04cf104491 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excuse me quite late reply, inline please.

2012/11/18 jouni korhonen <jouni.nospam@gmail.com>
Hi,

On Nov 17, 2012, at 6:56 PM, Hui Deng wrote:

> Hello, authors,
>
> in section 2.11, it says
> "learning the DNS server =A0addresses from the link layer signali= ng can be cumbersome when the MT
> =A0 =A0and the TE are separated using other techniques than PPP interf= ace"
> Can you be more specific about what else could be used? and what can b= e cumbersome?

Like proprietary APIs or USB cdc etc between the MT and the TE. There= might not be "easy" or standard way to let the TE stack to learn= DNS information that the network sent in NAS signaling. PPP had one. Learn= ing the DNS information using IP protocols between the TE stack and the gat= eway just makes the MT implementation easier and avoids OS specific hacks t= here.
I thought propriatary way also works, but if you think so= , please add some text in the current draft.
=A0

> for privacy consideration,
> can you help to write some analysis text about the relationship with &= quot;always on capability in 3GPP"

Do you mean analysis of a cellular host having the same prefix in use= for a long periods of time?
=A0
What=A0I me= an=A0is in the case of LTE, it will keep one IP address or IPv6 prefix to a= llow its always on which keep PDP context.
=A0

> Does SIPTO/LIPA has some influence on this document?

I am not sure yet. Maybe a recommendation to use DNA might be useful = here?
=A0
In the case of SIPTO/LIPA, UE=A0wi= ll has two PDP connections and two IP addresses assigned. does it make=A0so= me level difference?
=A0
thanks for your discussion
=A0
-Hui= =A0
=A0
=A0

- Jouni



>
> thanks
>
> -Hui
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops


--047d7b676164b95add04cf104491-- From sm@resistor.net Thu Nov 22 02:56:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF18F21F87F2 for ; Thu, 22 Nov 2012 02:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTDbSDQASRCZ for ; Thu, 22 Nov 2012 02:56:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46ECA21F87F1 for ; Thu, 22 Nov 2012 02:56:40 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMAt5Ls029709; Thu, 22 Nov 2012 02:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353581711; bh=Jnb0iLNMjQzLIaZQtabp1IEx2+D9+VpSXDTUg8hZ30E=; h=Date:To:From:Subject:Cc; b=Jirinz+LMiyu4knKZqz1A1h34wcwgDpY6r5m57zOLBPUZDdgW9huiAW/RhYKPacAU sBRdGj81uLgxY6KC/OH1+ToOUUpt9Y6XPfX390TzE6TCLUj7rn++j4QePI0jHu765S fQSF9q5YFxg+XnAMNu5qOrcd+jZVP+lCOujoogGg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353581711; i=@resistor.net; bh=Jnb0iLNMjQzLIaZQtabp1IEx2+D9+VpSXDTUg8hZ30E=; h=Date:To:From:Subject:Cc; b=DmwWickenGFmmx5Dcrtay9m6S93/LLt/rFVBODa0eTaehZK+sBeJ0xCmmWajIP5O+ /KdFpjEIjgiuebHNWpv9GCovG15Cl1u67QBNulYOs+QpqJL020hNkcgpLPRthxwV3O p/85HPPXea5S8iPkNoSI5HhUJgcq0/PbRebE7AOA= Message-Id: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 02:44:57 -0800 To: Brian Carpenter , Sheng Jiang From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 10:56:41 -0000 Hi Brian, Sheng, I read draft-ietf-v6ops-icp-guidance-04. Here's a few comments. Please consider them as editorial or nits. In Section 2: "In determining the urgency of this strategy, it should be noted that the central IPv4 registry (IANA) ran out of spare blocks of IPv4 addresses in February 2011 and the various regional registries are expected to exhaust their reserves over the next one to two years." APNIC and RIPE are in run-out mode. It's unlikely that two of the regional registries will run out in a year or two. I like the "just in time" advice (Section 3). Training is ineffective if people do not have the means to put what they learned immediately into practice. In Section 8.2: "One important recommendation here is that all applications should use domain names, which are IP-version-independent, rather than IP addresses." This recommendation could be about content instead of applications. Web pages with content such as "http\x3a\x2f\x2f131.253.14.66\x2fbvsandbox.aspx" can be avoided. It looks like you have this covered under "possible complexities". "A specific issue for HTTP-based services is that IP address-based cookie authentication schemes will need to deal with dual-stack clients." I don't see the following being covered in the recommendations. Set-Cookie: domain=131.253.14.66; [edited header] In Section 9: 'At the time of this writing, this solution seems to be passing out of use, being replaced by "DNS blacklisting" of customer sites known to have problems with IPv6 connectivity.' Given the past discussions about "whitelisting" (see RFC 5782) I'll highlight this and avoid the rehash. Regards, -sm From brian.e.carpenter@gmail.com Thu Nov 22 05:49:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512B121F89B8 for ; Thu, 22 Nov 2012 05:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.578 X-Spam-Level: X-Spam-Status: No, score=-101.578 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzQVEzBRQtyj for ; Thu, 22 Nov 2012 05:49:42 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7595021F89B9 for ; Thu, 22 Nov 2012 05:49:42 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm6so644195wib.13 for ; Thu, 22 Nov 2012 05:49:41 -0800 (PST) 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=q68zxyMIE7yWh5j/46SsY2AO14eEs1ZQpzg6CSRb/ys=; b=lL71rVpq83t4Tsb2dhsCvdgSBD4oNZmRLupuFItlBpLiogz0k5LAmGoJ6ZqOw9zvET 7UTn0JigaBI0kXwvaBPg+f+CqbfB0cfONfIoEjk9bNE/nvCPw4sJLJ2OVJSiptyyB3pH M73MHBHpSHxtMq3vtfhdBjEjghQbYRxrdqyjMNMTDHKcPaIPy1z17U0SN/6RhvHCrbHD hLEtGw/f0c9O8ROnU+ORvzuqAayINk0C2pYoCryfMhv6xEYRb+hj05Ty21DsK5p5iRG1 ed7+HztdMpHQ8trVvPK6UdzpmcyLaun9rxKoEibAlomWzU8c77eEG+mRtzpd2oqpcund Oc4g== Received: by 10.180.105.134 with SMTP id gm6mr1220219wib.21.1353592181429; Thu, 22 Nov 2012 05:49:41 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-157.as13285.net. [2.102.218.157]) by mx.google.com with ESMTPS id az2sm4128633wib.7.2012.11.22.05.49.39 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 05:49:40 -0800 (PST) Message-ID: <50AE2D7F.2060401@gmail.com> Date: Thu, 22 Nov 2012 13:49:51 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 13:49:43 -0000 On 22/11/2012 10:44, SM wrote: > Hi Brian, Sheng, > > I read draft-ietf-v6ops-icp-guidance-04. Here's a few comments. Please > consider them as editorial or nits. > > In Section 2: > > "In determining the urgency of this strategy, it should be noted that > the central IPv4 registry (IANA) ran out of spare blocks of IPv4 > addresses in February 2011 and the various regional registries are > expected to exhaust their reserves over the next one to two years." > > APNIC and RIPE are in run-out mode. It's unlikely that two of the > regional registries will run out in a year or two. Fair comment, but what a wasted opportunity if the LA and African regions continue to install legacy-only IP. > > I like the "just in time" advice (Section 3). Training is ineffective > if people do not have the means to put what they learned immediately > into practice. > > In Section 8.2: > > "One important recommendation here is that all applications should use > domain names, which are IP-version-independent, rather than IP > addresses." > > This recommendation could be about content instead of applications. Web > pages with content such as > "http\x3a\x2f\x2f131.253.14.66\x2fbvsandbox.aspx" can be avoided. It > looks like you have this covered under "possible complexities". > > "A specific issue for HTTP-based services is that IP address-based > cookie authentication schemes will need to deal with dual-stack > clients." > > I don't see the following being covered in the recommendations. > > Set-Cookie: domain=131.253.14.66; [edited header] Aren't content and cookies special cases of applications? It's all layer 7 fluff as far as layer 3 is concerned :-). Brian > > In Section 9: > > 'At the time of this writing, this solution seems to be passing out > of use, being replaced by "DNS blacklisting" of customer sites known > to have problems with IPv6 connectivity.' > > Given the past discussions about "whitelisting" (see RFC 5782) I'll > highlight this and avoid the rehash. > > Regards, > -sm > > From joelja@bogus.com Thu Nov 22 08:23:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5D821F8905 for ; Thu, 22 Nov 2012 08:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R1GD5D1lJxv for ; Thu, 22 Nov 2012 08:23:48 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 407F021F87F2 for ; Thu, 22 Nov 2012 08:23:48 -0800 (PST) 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 qAMGNhjg067054 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 22 Nov 2012 16:23:43 GMT (envelope-from joelja@bogus.com) Message-ID: <50AE518A.6080004@bogus.com> Date: Thu, 22 Nov 2012 08:23:38 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian E Carpenter References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> <50AE2D7F.2060401@gmail.com> In-Reply-To: <50AE2D7F.2060401@gmail.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, 22 Nov 2012 16:23:43 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 16:23:49 -0000 On 11/22/12 5:49 AM, Brian E Carpenter wrote: > On 22/11/2012 10:44, SM wrote: >> Hi Brian, Sheng, >> >> I read draft-ietf-v6ops-icp-guidance-04. Here's a few comments. Please >> consider them as editorial or nits. >> >> In Section 2: >> >> "In determining the urgency of this strategy, it should be noted that >> the central IPv4 registry (IANA) ran out of spare blocks of IPv4 >> addresses in February 2011 and the various regional registries are >> expected to exhaust their reserves over the next one to two years." >> >> APNIC and RIPE are in run-out mode. It's unlikely that two of the >> regional registries will run out in a year or two. > Fair comment, but what a wasted opportunity if the LA and African regions > continue to install legacy-only IP. I don't think it's fair to characterize the afrinic or lacnic ipv6 practices as lacking in zeal, they aren't. The fact that there's a disequalibrium in run rate means some applications are slightly less screwed than others and nothing more. >> I like the "just in time" advice (Section 3). Training is ineffective >> if people do not have the means to put what they learned immediately >> into practice. >> >> In Section 8.2: >> >> "One important recommendation here is that all applications should use >> domain names, which are IP-version-independent, rather than IP >> addresses." >> >> This recommendation could be about content instead of applications. Web >> pages with content such as >> "http\x3a\x2f\x2f131.253.14.66\x2fbvsandbox.aspx" can be avoided. It >> looks like you have this covered under "possible complexities". >> >> "A specific issue for HTTP-based services is that IP address-based >> cookie authentication schemes will need to deal with dual-stack >> clients." >> >> I don't see the following being covered in the recommendations. >> >> Set-Cookie: domain=131.253.14.66; [edited header] > Aren't content and cookies special cases of applications? It's all > layer 7 fluff as far as layer 3 is concerned :-). > > Brian > >> In Section 9: >> >> 'At the time of this writing, this solution seems to be passing out >> of use, being replaced by "DNS blacklisting" of customer sites known >> to have problems with IPv6 connectivity.' >> >> Given the past discussions about "whitelisting" (see RFC 5782) I'll >> highlight this and avoid the rehash. >> >> Regards, >> -sm >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sm@resistor.net Thu Nov 22 08:47:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5F521F8468 for ; Thu, 22 Nov 2012 08:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbhX6fwygVnd for ; Thu, 22 Nov 2012 08:47:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7121F8B40 for ; Thu, 22 Nov 2012 08:47:51 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMGlY31020505; Thu, 22 Nov 2012 08:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353602863; bh=tOnguiMHPqhTTAXgh/feTUaKX8YVzR924m/Y1Q8PYQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1bGnQwyiQbYFBppsLKNCTViLfMUe8xCS+3wTMKKJkSMRs8e3coeFG2+TDPtQZhalm pu8koLYK3ohed6hKdf2CKJlyjVf6voAsA8ZZ8KATPo7xgxOQFsbHfQaAFyOBcxULc7 u1AsYqRfjLAkK2AhV3VHEj+saBS2TwaDa32ZFzzA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353602863; i=@resistor.net; bh=tOnguiMHPqhTTAXgh/feTUaKX8YVzR924m/Y1Q8PYQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dpYZdNnjXm68bgbjnGo646G6LjhtCvBVslgNW8zn8eDYs+ChTuwsD2k98oqQm7han qkEnhye2xlVH6Qhu/oZEjP68MvXZN6JLa6jgKD7xr7pSLTvoKnDeGn6cLF20Ujmfu6 cM4ZcOUoxLjN8yoBm8qbe4l402Sq21yycc9uylCY= Message-Id: <6.2.5.6.2.20121122081017.0a5d5528@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 08:44:13 -0800 To: Brian E Carpenter From: SM In-Reply-To: <50AE2D7F.2060401@gmail.com> References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> <50AE2D7F.2060401@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 16:47:52 -0000 Hi Brian, At 05:49 22-11-2012, Brian E Carpenter wrote: >Fair comment, but what a wasted opportunity if the LA and African regions >continue to install legacy-only IP. Yes, and it would put these regions further back. >Aren't content and cookies special cases of applications? It's all >layer 7 fluff as far as layer 3 is concerned :-). Well, the fluff has to be somewhere. :-) The short answer to your question is yes. Regards, -sm From sm@resistor.net Thu Nov 22 09:07:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C1B21F8504 for ; Thu, 22 Nov 2012 09:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WFcplrrbl8c for ; Thu, 22 Nov 2012 09:07:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD3D21F845D for ; Thu, 22 Nov 2012 09:07:01 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMH6lXE020988; Thu, 22 Nov 2012 09:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353604013; bh=tOnguiMHPqhTTAXgh/feTUaKX8YVzR924m/Y1Q8PYQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NbPF/ux7RcBWL9uOpDtz1jTp9VkdTxzMuUhh40AL7/CTrDgzSF1zPZVgVjVOjRQ3T Se2Z3yRa5H5ujfWfTItYLrqAM1QXhN5LoF7CiJwReXAK+oSfPhK9zSFQ7Crg9X7GOO /kb+lUyEXQPg7loE2CngrgBGyVDTRM5yjWYWys4o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353604013; i=@resistor.net; bh=tOnguiMHPqhTTAXgh/feTUaKX8YVzR924m/Y1Q8PYQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s7hQLC2YgoysUGzAMQWPQYHz+B2J8rMAYKWpaXCMvlsMy299vYM2ZzsYlqivfJhmG 06Ov9ieKKQ2Q8KFhd04b92V5IEbLs7aFClSjbQg8Lqlen5a9j2calQ9rU340HVfet0 4i0RBO1UUbVY6gnEXP9cdZ0DAXckiEjnUN4KTcv4= Message-Id: <6.2.5.6.2.20121122081017.0a5d5528@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 08:44:13 -0800 To: Brian E Carpenter From: SM In-Reply-To: <50AE2D7F.2060401@gmail.com> References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> <50AE2D7F.2060401@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 17:07:02 -0000 Hi Brian, At 05:49 22-11-2012, Brian E Carpenter wrote: >Fair comment, but what a wasted opportunity if the LA and African regions >continue to install legacy-only IP. Yes, and it would put these regions further back. >Aren't content and cookies special cases of applications? It's all >layer 7 fluff as far as layer 3 is concerned :-). Well, the fluff has to be somewhere. :-) The short answer to your question is yes. Regards, -sm From sm@resistor.net Thu Nov 22 09:52:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1121F88D5 for ; Thu, 22 Nov 2012 09:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQZJXV63BdeJ for ; Thu, 22 Nov 2012 09:52:39 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F6D21F867C for ; Thu, 22 Nov 2012 09:52:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMHqTmo004411; Thu, 22 Nov 2012 09:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353606755; bh=ocoirG1OOd6etwlOQXITBUCnZBnPXda45Np0ThdBjZU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ClJitr1OmnyJBYPRp+ZZ8uVBEzD00BPV6lpVPNbtc+1lkvbuAtqeeG/YmQKyQcsUo 2bjoZIENtamJkG/Q7SKGQxILUacszNij+r8vthkj7KCqTaNht2XESQ/XyIz5POX9jj 8AdG11gUHFUwkEc1AaYcYGj7g41R8m5NH0MO2eJ0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353606755; i=@resistor.net; bh=ocoirG1OOd6etwlOQXITBUCnZBnPXda45Np0ThdBjZU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ko4k0It9dYGS/9zDK4O8fzGEclEDeoc+oOlhtkzzFFAsLzzaHTd5PgVXFJo4z80XG t0Hxhozh7slAlgJkjsJxpYDSqtLNxelBohdTs5okX1+pfarTDkuvPs+ly9aOreS3pn rG0c2EKQn3XZmK977ynwERxv6sSXcVlePjt/2eqY= Message-Id: <6.2.5.6.2.20121122090618.09887470@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 09:41:49 -0800 To: joel jaeggli From: SM In-Reply-To: <50AE518A.6080004@bogus.com> References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> <50AE2D7F.2060401@gmail.com> <50AE518A.6080004@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Nov 2012 17:52:43 -0000 Hi Joel, At 08:23 22-11-2012, joel jaeggli wrote: >I don't think it's fair to characterize the afrinic or lacnic ipv6 >practices as lacking in zeal, they aren't. The fact that there's a >disequalibrium in run rate means some applications are slightly less >screwed than others and nothing more. I didn't read Brian's comment as being about registry IPv6 practices. I would describe it as the urgency of the strategy being influenced by content or application service providers still being able to get IPv4 address space from their registry. The wasted opportunity would be about continuing with a IPv4-only strategy while other parts of the world gain IPv6 experience. Regards, -sm From jiangsheng@huawei.com Thu Nov 22 16:49:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D9521F87B6 for ; Thu, 22 Nov 2012 16:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-MqdIKsLUne for ; Thu, 22 Nov 2012 16:49:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F69821F87B5 for ; Thu, 22 Nov 2012 16:49:14 -0800 (PST) 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 ANB25390; Fri, 23 Nov 2012 00:49:12 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Nov 2012 00:48:39 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Nov 2012 08:49:11 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.003; Fri, 23 Nov 2012 08:49:07 +0800 From: Sheng Jiang To: SM , Brian E Carpenter Thread-Topic: Comments on draft-ietf-v6ops-icp-guidance-04 Thread-Index: AQHNyKCIaP1IdWOBKEyqX2dLpkjJ1Jf1WR+AgAAwuICAAQxQkA== Date: Fri, 23 Nov 2012 00:49:06 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F91ABB@szxeml545-mbx.china.huawei.com> References: <6.2.5.6.2.20121122003329.0b7cb9a8@elandnews.com> <50AE2D7F.2060401@gmail.com> <6.2.5.6.2.20121122081017.0a5d5528@resistor.net> In-Reply-To: <6.2.5.6.2.20121122081017.0a5d5528@resistor.net> 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.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-ietf-v6ops-icp-guidance-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Nov 2012 00:49:21 -0000 Pj5BcmVuJ3QgY29udGVudCBhbmQgY29va2llcyBzcGVjaWFsIGNhc2VzIG9mIGFwcGxpY2F0aW9u cz8gSXQncyBhbGwNCj4+bGF5ZXIgNyBmbHVmZiBhcyBmYXIgYXMgbGF5ZXIgMyBpcyBjb25jZXJu ZWQgOi0pLg0KPg0KPldlbGwsIHRoZSBmbHVmZiBoYXMgdG8gYmUgc29tZXdoZXJlLiA6LSkgIFRo ZSBzaG9ydCBhbnN3ZXIgdG8geW91cg0KPnF1ZXN0aW9uIGlzIHllcy4NCg0KRm9yIG15IHVuZGVy c3RhbmRpbmcsIGFwcGxpY2F0aW9ucyBhcmUgY29udGFpbmVyLCB3aGljaCBpbmNsdWRlcyBjb250 ZW50IGFuZCBtYW55IG9wZXJhdGlvbmFsIGJhY2tncm91bmQgY29tcG9uZW50cy4gVGhpcyByZWNv bW1lbmRhdGlvbiBtdXN0IGNvdmVyIGFsbCB0aGVzZSBjb21wb25lbnRzIHRvby4NCg0KUmVnYXJk cywNCg0KU2hlbmcNCg0KPlJlZ2FyZHMsDQo+LXNtDQo+DQo+DQo+DQo+DQo+DQoNCg== From pkern@spike.0x539.de Sat Nov 24 03:34:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94821F8635 for ; Sat, 24 Nov 2012 03:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHKsx7GvUx4z for ; Sat, 24 Nov 2012 03:34:07 -0800 (PST) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id E914421F862A for ; Sat, 24 Nov 2012 03:34:06 -0800 (PST) Received: from e180089168.adsl.alicedsl.de ([85.180.89.168] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1TcDzn-0003Zz-Ku; Sat, 24 Nov 2012 12:34:03 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1TcDzm-0002Et-Io; Sat, 24 Nov 2012 12:34:02 +0100 Date: Sat, 24 Nov 2012 12:34:02 +0100 From: Philipp Kern To: Lee Howard Message-ID: <20121124113402.GA8432@spike.0x539.de> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'IPv6 Operations' Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Nov 2012 11:34:11 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Wed, Nov 21, 2012 at 10:02:58AM -0500, Lee Howard wrote: > The intent is to document existing solutions, since prepopulating PTRs like > we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was > interest, but not necessarily as a working group document. Since it's been > a while, and the operator community is still asking for guidance, I've > updated it, and would like a renewed review of it as an individual > submission (unless this WG or dnsop wants it). couldn't we deprecate "Every Internet-reachable host should have a name" if the benefits are questionable in the IPv6 realm? Kind regards Phliipp Kern --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQsLCqAAoJEERuJUU10Fbsf6IIAIDXwKpZcz7FP9+r+LWfTOp1 tn3NfOGLlaS2pel3Q/rckxQMStDgBc6A0oKlqS1+SyTnnqQObCINRfutxx+sxa8F HLu530/jVGO4tv4j0gphlLjmjMOwDzUOs/t0Kd9tEZ6qIO732jjdBimnOhoOnRdj Es29ZPKDPqbtqJrYeaDBYwDRWubuCWvtKXeCea5nPL1B52pNFcKA+VGUEnXvC9aE 2O+uMl3968UWeik2Jng7Q2zipyoq57S5CyluFjwZpZwxbpxiRjE+Kq2RCIFMwIAT 4JjyyQMEnbdFP4X9rxrHeW+WdXFeQoxR4mWmcXVjBKpIrULZoEZNQOJM1wgCfxg= =1wSR -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From gert@space.net Sat Nov 24 11:12:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE40121F854D for ; Sat, 24 Nov 2012 11:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6mzTAnWvDz8 for ; Sat, 24 Nov 2012 11:12:30 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3C21F8534 for ; Sat, 24 Nov 2012 11:12:29 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id CAFAE602A4 for ; Sat, 24 Nov 2012 20:12:27 +0100 (CET) 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 A6BE56028F for ; Sat, 24 Nov 2012 20:12:27 +0100 (CET) Received: (qmail 9475 invoked by uid 1007); 24 Nov 2012 20:12:27 +0100 Date: Sat, 24 Nov 2012 20:12:27 +0100 From: Gert Doering To: Philipp Kern Message-ID: <20121124191227.GR19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vVpwErOmq4St3IV6" Content-Disposition: inline In-Reply-To: <20121124113402.GA8432@spike.0x539.de> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'IPv6 Operations' Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Nov 2012 19:12:30 -0000 --vVpwErOmq4St3IV6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 24, 2012 at 12:34:02PM +0100, Philipp Kern wrote: > couldn't we deprecate "Every Internet-reachable host should have a name" = if the > benefits are questionable in the IPv6 realm? I'm not necessarily married to reverse DNS, but I *like* that paradigm, "every Internet-reachable host should have a name, and a FQDN at that". 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 --vVpwErOmq4St3IV6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULEcG6kuBuNlUUl1AQIJ7QP/SB/vPgGwEDQCGmHs0Edaqt3vkyoPXK5A ZBZIsduWKYtZCDWqBdavMc7+ENfj0aX5XxtLte869DXBZ5LWjAS//uJWQYlBugkG 3Daf72mjRDmUIP7xV+oefBe/V3S9/jEFAQA47zBu1/nXpDM6rXHD9W6foBGSwXdo X7ZZGCkgfGc= =Xg83 -----END PGP SIGNATURE----- --vVpwErOmq4St3IV6-- From Ted.Lemon@nominum.com Sat Nov 24 15:39:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E421F854A for ; Sat, 24 Nov 2012 15:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VS3QfjK1Ygu for ; Sat, 24 Nov 2012 15:39:16 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2C65621F8538 for ; Sat, 24 Nov 2012 15:39:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKULFaoziEs3NKKpA/uC4GQj2AKNxff9Dq@postini.com; Sat, 24 Nov 2012 15:39:16 PST 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 F25811B80B3 for ; Sat, 24 Nov 2012 15:39:14 -0800 (PST) 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 D679F190043; Sat, 24 Nov 2012 15:39:14 -0800 (PST) (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; Sat, 24 Nov 2012 15:39:15 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+wCgXH8AABACkIAACVEVgA== Date: Sat, 24 Nov 2012 23:39:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> In-Reply-To: <20121124191227.GR19111@Space.Net> 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: <6A7C47E39E6A5C448C970B72E49194CD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Nov 2012 23:39:17 -0000 On Nov 24, 2012, at 2:12 PM, Gert Doering wrote: > I'm not necessarily married to reverse DNS, but I *like* that paradigm, > "every Internet-reachable host should have a name, and a FQDN at that". Why? From joelja@bogus.com Sat Nov 24 18:37:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B421F8469 for ; Sat, 24 Nov 2012 18:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Ua1bLYrMy9 for ; Sat, 24 Nov 2012 18:37:53 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 870FA21F8463 for ; Sat, 24 Nov 2012 18:37:53 -0800 (PST) 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 qAP2bpgc097469 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 25 Nov 2012 02:37:52 GMT (envelope-from joelja@bogus.com) Message-ID: <50B18479.304@bogus.com> Date: Sat, 24 Nov 2012 18:37:45 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.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]); Sun, 25 Nov 2012 02:37:52 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 02:37:54 -0000 On 11/24/12 3:39 PM, Ted Lemon wrote: > On Nov 24, 2012, at 2:12 PM, Gert Doering wrote: >> I'm not necessarily married to reverse DNS, but I *like* that paradigm, >> "every Internet-reachable host should have a name, and a FQDN at that". > Why? what fqdn should a privacy address have? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sat Nov 24 23:50:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7FF21F84C0 for ; Sat, 24 Nov 2012 23:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ncckr0rTFcn for ; Sat, 24 Nov 2012 23:50:17 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4181C21F8480 for ; Sat, 24 Nov 2012 23:50:17 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm6so2093455wib.13 for ; Sat, 24 Nov 2012 23:50:16 -0800 (PST) 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=PLcQvGbrS0e+cIeZ1/GLxb6h6Jwj6M7B0nVoe50l2w8=; b=OR5m/Ejy/w39oirVUC5MQY8QAtk1gid4g/x5guJ08xotT9UlfcyYYXOUGXq4svW9RD Sp+KwSfqJLuHk7lAvqN+5kSsqLmo+WRNKBAC2Ry940CZwZ6IB4JR2nBwjVPRw9DBxIiw 5wjsyT3ymhiLnfZhyk+i76086z+XRJsglhMUH/zwitbKVmYTqGkOvRUdyyvOckNJOcZa R5uuDOMyQLJ7RL85mskemz5EHrrfvvJ2gytVYRZdEsgzwjvhl28qd5ogleEk4HsqrgGi Rf/HoGtP+5K++/+QtYOYdOT6rUSRX8dNVT18jCjn4xq5ItgUrP4Nf0zBHmdVGl0g/lZf cU1Q== Received: by 10.180.108.38 with SMTP id hh6mr16354102wib.0.1353829816282; Sat, 24 Nov 2012 23:50:16 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-251.as13285.net. [2.102.219.251]) by mx.google.com with ESMTPS id bd7sm3282529wib.8.2012.11.24.23.50.14 (version=SSLv3 cipher=OTHER); Sat, 24 Nov 2012 23:50:15 -0800 (PST) Message-ID: <50B1CDB1.5080507@gmail.com> Date: Sun, 25 Nov 2012 07:50:09 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <50B18479.304@bogus.com> In-Reply-To: <50B18479.304@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 07:50:18 -0000 On 25/11/2012 02:37, joel jaeggli wrote: > On 11/24/12 3:39 PM, Ted Lemon wrote: >> On Nov 24, 2012, at 2:12 PM, Gert Doering wrote: >>> I'm not necessarily married to reverse DNS, but I *like* that paradigm, >>> "every Internet-reachable host should have a name, and a FQDN at that". >> Why? > > what fqdn should a privacy address have? Let's ask that question about any form of temporary address. There are numerous strong arguments for using FQDNs whenever possible for any purpose whatever; my hobby horse of renumbering is only one of them. But if an address is truly temporary, those arguments tend to fall away. Brian From rajiva@cisco.com Sun Nov 25 02:07:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3221F84E8 for ; Sun, 25 Nov 2012 02:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ocnxHWTT5gX for ; Sun, 25 Nov 2012 02:07:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 53D2121F84E6 for ; Sun, 25 Nov 2012 02:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3316; q=dns/txt; s=iport; t=1353838066; x=1355047666; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=urS+gAgc7mak1STAykILKf/C5h6wb9YF0Z2ErG3Rb0A=; b=S5IIl6avHsoYJWygR8Hi9XtsD3Jnu1eqo8uNWVS6JHFjTQ1KtndCvXad Img80sb0Ru42fxbUsM+xfFadP6u7rnQZVMt8lvdDGFHRT3SJyhsSrv5YL w3u+np9oqDW+OaQjcp/kUBDXAPabtq5ybwojfp6peT9s6PD7poqdT8las M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMfssVCtJXG8/2dsb2JhbABEwD8Wc4IeAQEBBAEBATc0CwwGAQgOAwMBAgsUMQYLHQgCBAENBQiHcwMPDLMnDYlUi05pg2BhA5QsgnGKGIUQgm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6906"; a="145881644" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 25 Nov 2012 10:07:38 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAPA7cfN012000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Nov 2012 10:07:38 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.44]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sun, 25 Nov 2012 04:07:38 -0600 From: "Rajiv Asati (rajiva)" To: Cameron Byrne , Julien Laganier Thread-Topic: [v6ops] NUD and draft-byrne-v6ops-64share-03 Thread-Index: AQHNyE7JdfZgN8oHY02vek4D15enpZf1nCEAgAL3eYA= Date: Sun, 25 Nov 2012 10:07:37 +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.2.4.120824 x-originating-ip: [10.82.217.123] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 10:07:47 -0000 Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. BTW, the below text in the security consideration section reads as if GGSN/PGW and UE are on-link (wrt IPv6), if read together with the next line. // 9. Security Considerations .. ..=20 and the fact that the UE and the first-hop router (PDN-GW/GGSN or SGW) are the only nodes on the link. For off-link IPv6 attacks, the 3GPP EPS is as vulnerable as any IPv6 system. Cheers, Rajiv // 5.2. IPv6 Address Configuration .. ..=20 In the 3GPP link model, the /64 prefix assigned to the UE cannot be used for on-link determination (because the L-bit in the Prefix Information Option (PIO) in the RA must always be set to zero). If the advertised prefix is used for SLAAC, then the A-bit in the PIO must be set to one. Details of the 3GPP link-model and address -----Original Message----- From: Cameron Byrne Date: Wednesday, November 21, 2012 10:47 PM To: Julien Laganier Cc: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 >On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier >wrote: >> Hello, >> >> I have a question regarding the interaction between NUD and the method >> described in this draft. >> >> The GGSN/PGW acting as a default router advertises via IPv6 RAs a /64 >>prefix >> over the point-to-point link to the User Equipment. >> >> Assuming the User Equipment employs the method described in this draft >>and >> uses "the 3GPP network assigned /64 to assign itself a /128 subnet >>address >> to the 3GPP radio interface for consistent network reachability and the >>same >> address with a /64 subnet to the tethered LAN interface.The tethered LAN >> interface may then advertise the /64 subnet to the LAN with RA." >> >> Now a host on the tethered LAN will configure an IPv6 address with SLAAC >> based on the advertized /64, and starts to use it. >> >> When a downlink packets sent towards a host on the tethered LAN arrives >>at >> the GGSN/PGW, who believes the /64 is onlink, if the GGSN/PGW attempts >>NUD >> towards that destination address, in the current description of the >>method >> the UE will not reply (it has configured only one /128 on its interface >> facing the 3GPP network). Thus it seems GGSN/PGW initiated NUD will >>fail. >> >> So it seems to me that the current method would work only if a) the >>GGSN/PGW >> doesn't perform NUD for downlink packets sent over the point-to-point >>link, >> or b) the UE answers NUD probes for all addresses in the /64. >> >> Is this correct? >> > >AFAIK, the GGSN/PGW does not do NUD. The /64 is considered off-link >[1] and therefore no host resolution is done > >[1] http://tools.ietf.org/html/rfc6459#section-5.2 > > > > > >CB > >> Thanks, >> >> --julien >> >> >> >> _______________________________________________ >> 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 gert@space.net Sun Nov 25 02:47:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD8821F84E0 for ; Sun, 25 Nov 2012 02:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1hEUltaI03G for ; Sun, 25 Nov 2012 02:47:42 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06121F84D8 for ; Sun, 25 Nov 2012 02:47:41 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1ED8B60194 for ; Sun, 25 Nov 2012 11:47:40 +0100 (CET) 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 E8A7860250 for ; Sun, 25 Nov 2012 11:47:39 +0100 (CET) Received: (qmail 65166 invoked by uid 1007); 25 Nov 2012 11:47:39 +0100 Date: Sun, 25 Nov 2012 11:47:39 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20121125104739.GV19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+ZTxCmGfbpJRLXvL" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 10:47:50 -0000 --+ZTxCmGfbpJRLXvL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Nov 24, 2012 at 11:39:14PM +0000, Ted Lemon wrote: > On Nov 24, 2012, at 2:12 PM, Gert Doering wrote: > > I'm not necessarily married to reverse DNS, but I *like* that paradigm, > > "every Internet-reachable host should have a name, and a FQDN at that". >=20 > Why? I find it convenient to know who I'm talking to, or at least, where he's coming from (like "chinatelecom.net" or "t-online.de"). The argument about privacy addresses has merits, of course, but then, I=20 do not like privacy addresses very much either (I'm not saying that they do not solve a valid issue, but I'm personally fine with a static IPv6 address for my client systems - trackability of mac-based EUI-64 could have been solved differently, like "hashing in something unique per attached-to network", but that's a wholly separate discussion). Note that I didn't say "MUST have" or such. I said I *like* it. 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 --+ZTxCmGfbpJRLXvL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULH3S6kuBuNlUUl1AQL5pAP/b1ZPp5rL0hg+Od2XBnIP3z7GgujRi7N0 E8SVu04KVMpWtD0xpHhqOJlb76FlvaJcgTMotmjBX9+hyjVkuP7hiNTJ23iEwyi9 OfJHJEmxrXPXAgwqxCV2LoN1T63K/UE9slfJSSDwIJUi1uUYff17YFj+3+GA9IYA +aDqLLDUNH0= =G/zu -----END PGP SIGNATURE----- --+ZTxCmGfbpJRLXvL-- From pkern@hub.kern.lc Sun Nov 25 02:59:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8AE21F84DA for ; Sun, 25 Nov 2012 02:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxWk5kYh+Lqs for ; Sun, 25 Nov 2012 02:58:54 -0800 (PST) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9821F84D7 for ; Sun, 25 Nov 2012 02:58:54 -0800 (PST) Received: from [2001:470:720c:0:714b:4e1:9ef5:acfe] (helo=simplex.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1TcZvI-0005pj-2Z for v6ops@ietf.org; Sun, 25 Nov 2012 11:58:52 +0100 Date: Sun, 25 Nov 2012 11:58:40 +0100 From: Philipp Kern To: IPv6 Operations Message-ID: <20121125115840.1c47fdae@simplex.0x539.de> In-Reply-To: <20121125104739.GV19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/oRtXqRI1/B0tPJOIFi96S+m"; protocol="application/pgp-signature" Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 10:59:02 -0000 --Sig_/oRtXqRI1/B0tPJOIFi96S+m Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gert, On Sun, 25 Nov 2012 11:47:39 +0100 Gert Doering wrote: > I find it convenient to know who I'm talking to, or at least, where > he's coming from (like "chinatelecom.net" or "t-online.de"). well, as a provider you know the source AS. As a server provider we could solve that with CIDR lists? For after the fact matching like access log processing that should be doable. Currently we also have few enough /32 and PI /48 so that matching could be done on the fly. But that's obviously not guaranteed to remain that way=E2=80=A6 Kind regards Philipp Kern --Sig_/oRtXqRI1/B0tPJOIFi96S+m Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQsfngAAoJEERuJUU10FbsFjAIAKzjNCajDmczu3raFavfZJDU zi9b0/Y8hYNsfcWug0bvDpJqTNeXl7ddjnzedNvDKWwxL1jy+E5JtidU5Pf1pqvx tSWSM4qm0tafe72HqUcez/7zk9+wmqmy2s0yGpJDoZCC9lcFnEsukQlE5iLuIIo9 qVtVRNNLXmRvNBK0LMybrFC/C8CvhJnvM5JuxgnUibKBPvevcJfPdpg/pxj5DV1q EYYfL3rxOC0zFJuDqdCQrhIYUKIYsOCCI1VA1oe2l5G+/e13XaFCxpdjXphSdgSo wmTZA4nMjc4J0l8pBUNLWRP9f3qXVU96l1VCZ1TvezfLCt4LWSiBhpUjE7cgbk4= =eXEG -----END PGP SIGNATURE----- --Sig_/oRtXqRI1/B0tPJOIFi96S+m-- From gert@space.net Sun Nov 25 03:06:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5542E21F84F3 for ; Sun, 25 Nov 2012 03:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5YUDM5KJiNt for ; Sun, 25 Nov 2012 03:06:31 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 3969921F84F0 for ; Sun, 25 Nov 2012 03:06:31 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3D45D60298 for ; Sun, 25 Nov 2012 12:06:30 +0100 (CET) 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 18FD660209 for ; Sun, 25 Nov 2012 12:06:30 +0100 (CET) Received: (qmail 70060 invoked by uid 1007); 25 Nov 2012 12:06:30 +0100 Date: Sun, 25 Nov 2012 12:06:30 +0100 From: Gert Doering To: Philipp Kern Message-ID: <20121125110630.GW19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <20121125115840.1c47fdae@simplex.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x96pM+uot4Qe+FAK" Content-Disposition: inline In-Reply-To: <20121125115840.1c47fdae@simplex.0x539.de> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 11:06:39 -0000 --x96pM+uot4Qe+FAK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Nov 25, 2012 at 11:58:40AM +0100, Philipp Kern wrote: > On Sun, 25 Nov 2012 11:47:39 +0100 > Gert Doering wrote: > > I find it convenient to know who I'm talking to, or at least, where > > he's coming from (like "chinatelecom.net" or "t-online.de"). >=20 > well, as a provider you know the source AS. As a server provider > we could solve that with CIDR lists? For after the fact matching like > access log processing that should be doable. Currently we also > have few enough /32 and PI /48 so that matching could be done on > the fly. But that's obviously not guaranteed to remain that way??? Of course I can get the info with "whois" (or other tools) today, but none= =20 of my machines knows how to do that. Reverse DNS is simple, and they know how to query it - if someone's machine has its own name, it will give it to me, and if the ISP only does generic rDNS, this is a statement of its own... 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 --x96pM+uot4Qe+FAK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULH7takuBuNlUUl1AQJ+qAQAhWIPnyB2KE60SrRjNdiffa/qkH4sEXeB e1NiR1NxRjiZz2wmZUZ+8eq24/83Y/hnuusBulCc1vCnXdPc2cWM6XkfP6t+AJro kqUCU5TTSZQ9+fDUZY2Z97xR5By/lm9lYScdbmGwGcdgyQaGbFfWlYS4wfK3Brqe rftsnUUynnQ= =EwkB -----END PGP SIGNATURE----- --x96pM+uot4Qe+FAK-- From pkern@hub.kern.lc Sun Nov 25 03:10:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0321F8518 for ; Sun, 25 Nov 2012 03:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATBeYL-ky0AA for ; Sun, 25 Nov 2012 03:10:29 -0800 (PST) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id 053D521F84F0 for ; Sun, 25 Nov 2012 03:10:29 -0800 (PST) Received: from [2001:470:720c:0:714b:4e1:9ef5:acfe] (helo=simplex.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Tca6W-0005ub-11 for v6ops@ietf.org; Sun, 25 Nov 2012 12:10:28 +0100 Date: Sun, 25 Nov 2012 12:10:26 +0100 From: Philipp Kern To: IPv6 Operations Message-ID: <20121125121026.210b9d4d@simplex.0x539.de> In-Reply-To: <20121125110630.GW19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <20121125115840.1c47fdae@simplex.0x539.de> <20121125110630.GW19111@Space.Net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/v9xe7vn7UyOOD/QzZbUQhu/"; protocol="application/pgp-signature" Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 11:10:29 -0000 --Sig_/v9xe7vn7UyOOD/QzZbUQhu/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 25 Nov 2012 12:06:30 +0100 Gert Doering wrote: > Of course I can get the info with "whois" (or other tools) today, but > none of my machines knows how to do that. Reverse DNS is simple, and > they know how to query it - if someone's machine has its own name, it > will give it to me, and if the ISP only does generic rDNS, this is a > statement of its own... So what I was aiming at? Do we need a library for that? (Which would certainly depend on the use cases where such a lookup would help.) Kind regards Philipp Kern --Sig_/v9xe7vn7UyOOD/QzZbUQhu/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQsfyiAAoJEERuJUU10FbsAl4H/jVFJk+z296tVQ8hzww61f1l 1dPHOU8B5fMvHj8CED8fm76y0rBp0plPpOg+S7eUeaIooy9T1z8faTpTETVJsL3m aXuUKMv7CwTxGHOi6NpbjrtCeJ9uqekUKAfrTaOOoMeSLZZFJ9hPPZEJC8NJKTXd v+MOBA3B/Chvt/TePPR61SXw1QLvhzwEKZhuxdH69ClS9PWJ/hXyE4BmEPkQ4fGq F1y4d4sWckRBMKWSRpas7BRfbO6SUYNGrPmR3OAvAJz3XV7A4Otm7qB3bcTCs/qj /xxL6/oFBeSxUAf6sQuiH5WR2BoXC83Vo83Y8+Z8C6yJhJ6YlOUW427F7QKPnyg= =7i+S -----END PGP SIGNATURE----- --Sig_/v9xe7vn7UyOOD/QzZbUQhu/-- From gert@space.net Sun Nov 25 03:11:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800F821F856E for ; Sun, 25 Nov 2012 03:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FncleXhwfs4 for ; Sun, 25 Nov 2012 03:11:58 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1721F856D for ; Sun, 25 Nov 2012 03:11:57 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id F306D60296 for ; Sun, 25 Nov 2012 12:11:56 +0100 (CET) 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 BF34D60194 for ; Sun, 25 Nov 2012 12:11:56 +0100 (CET) Received: (qmail 71454 invoked by uid 1007); 25 Nov 2012 12:11:56 +0100 Date: Sun, 25 Nov 2012 12:11:56 +0100 From: Gert Doering To: Philipp Kern Message-ID: <20121125111156.GX19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <20121125115840.1c47fdae@simplex.0x539.de> <20121125110630.GW19111@Space.Net> <20121125121026.210b9d4d@simplex.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oewGmZAZkT4pTohN" Content-Disposition: inline In-Reply-To: <20121125121026.210b9d4d@simplex.0x539.de> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 11:11:58 -0000 --oewGmZAZkT4pTohN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Nov 25, 2012 at 12:10:26PM +0100, Philipp Kern wrote: > Gert Doering wrote: > > Of course I can get the info with "whois" (or other tools) today, but > > none of my machines knows how to do that. Reverse DNS is simple, and > > they know how to query it - if someone's machine has its own name, it > > will give it to me, and if the ISP only does generic rDNS, this is a > > statement of its own... >=20 > So what I was aiming at? Do we need a library for that? (Which would > certainly depend on the use cases where such a lookup would help.) Well, before going to solution space, we should agree that DNS is indeed failing to get the job done. I'm not convinced of that yet. 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 --oewGmZAZkT4pTohN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULH8/KkuBuNlUUl1AQKCagQAnoO+MFaRMDwy0jtnGMav6Hy7Lfs+Alm4 vSMQztC4kg8/sdIAOrwTiIpb5DAp1G2d3a5a8pTJAnGaCv4m0c91m0QYzo9KYFzD W5S16JAD3pAzZQCWjj69PTSt+x5ZuY9osMYTm4DduQrK/0Kudz3gmUOObPZ+owiu PXX/XDNOkOw= =TXuk -----END PGP SIGNATURE----- --oewGmZAZkT4pTohN-- From jouni.nospam@gmail.com Sun Nov 25 04:58:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F198A21F84ED for ; Sun, 25 Nov 2012 04:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRAET1bij9En for ; Sun, 25 Nov 2012 04:58:44 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1A321F84EA for ; Sun, 25 Nov 2012 04:58:43 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so8054163iaf.31 for ; Sun, 25 Nov 2012 04:58:43 -0800 (PST) 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=yfDdW6aagWriIa/GMAui+jyULa/wv8B+on9NLWPEjgE=; b=WyN+ytJOJja2QTztnxNLGk1SlVvtJSf1m9/yWmTK8Dbk52LXggBDCn+YOOIY4d8Wp8 U9TKeel9CdB/fDW85fOCKM3ck+HmEyQt2BLIVnFAPpbOowR7N6I0fPw560Q0mTy9ycSH I9MruU+8dJ+XyKt3SlgdX5kQ5GTCTz15xGOZkzqhnysUEm9Ja5i4rlcbEicrWUdxHeuh stVnM698SkFHLBTzw1+H1ZkN961LQVJEFT8/waL9MiMyAPPpqbWVKxNqFucofL9wzDQp xVeR6+LG1LPGkzGPZWNaHgx1hj5uej2acr3ncHP7ZFItT02/5Ly4Z0l97WqBZE6+NOXt AQ0w== MIME-Version: 1.0 Received: by 10.42.51.142 with SMTP id e14mr7507028icg.2.1353848323124; Sun, 25 Nov 2012 04:58:43 -0800 (PST) Received: by 10.64.17.194 with HTTP; Sun, 25 Nov 2012 04:58:43 -0800 (PST) In-Reply-To: References: Date: Sun, 25 Nov 2012 14:58:43 +0200 Message-ID: From: jouni korhonen To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 12:58:45 -0000 Hi, On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) wrote: > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. Correct. > BTW, the below text in the security consideration section reads as if > GGSN/PGW and UE are on-link (wrt IPv6), if read together with the next > line. > > // > 9. Security Considerations > > .. .. > > > and the fact that the UE and the first-hop router (PDN-GW/GGSN or > SGW) are the only nodes on the link. For off-link IPv6 attacks, the > 3GPP EPS is as vulnerable as any IPv6 system. Excuse for my bad (non-native speaker) wording but that quote does not try to hint anything about on-link properties of the prefix. It would have been more appropriate quote the whole sentence where it also refers to the actual link model (which then can be found in Section 5.2.) What was intended to say here is that if an off-link host can launch an attack by sending IPv6 packets to the mobile host, then generic IPv6 host security concerns apply. In general this is/will be (hopefully) a bit more precisely described in draft-ietf-opsec-v6-01 and draft-ietf-v6ops-rfc3316bis. - Jouni > > > > Cheers, > Rajiv > > > > > // > 5.2. IPv6 Address Configuration > > .. .. > > > In the 3GPP link model, the /64 prefix assigned to the UE cannot be > used for on-link determination (because the L-bit in the Prefix > Information Option (PIO) in the RA must always be set to zero). If > the advertised prefix is used for SLAAC, then the A-bit in the PIO > must be set to one. Details of the 3GPP link-model and address > > > > > > > > -----Original Message----- > From: Cameron Byrne > Date: Wednesday, November 21, 2012 10:47 PM > To: Julien Laganier > Cc: "v6ops@ietf.org" , > "draft-byrne-v6ops-64share@tools.ietf.org" > > Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 > >>On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier >>wrote: >>> Hello, >>> >>> I have a question regarding the interaction between NUD and the method >>> described in this draft. >>> >>> The GGSN/PGW acting as a default router advertises via IPv6 RAs a /64 >>>prefix >>> over the point-to-point link to the User Equipment. >>> >>> Assuming the User Equipment employs the method described in this draft >>>and >>> uses "the 3GPP network assigned /64 to assign itself a /128 subnet >>>address >>> to the 3GPP radio interface for consistent network reachability and the >>>same >>> address with a /64 subnet to the tethered LAN interface.The tethered LAN >>> interface may then advertise the /64 subnet to the LAN with RA." >>> >>> Now a host on the tethered LAN will configure an IPv6 address with SLAAC >>> based on the advertized /64, and starts to use it. >>> >>> When a downlink packets sent towards a host on the tethered LAN arrives >>>at >>> the GGSN/PGW, who believes the /64 is onlink, if the GGSN/PGW attempts >>>NUD >>> towards that destination address, in the current description of the >>>method >>> the UE will not reply (it has configured only one /128 on its interface >>> facing the 3GPP network). Thus it seems GGSN/PGW initiated NUD will >>>fail. >>> >>> So it seems to me that the current method would work only if a) the >>>GGSN/PGW >>> doesn't perform NUD for downlink packets sent over the point-to-point >>>link, >>> or b) the UE answers NUD probes for all addresses in the /64. >>> >>> Is this correct? >>> >> >>AFAIK, the GGSN/PGW does not do NUD. The /64 is considered off-link >>[1] and therefore no host resolution is done >> >>[1] http://tools.ietf.org/html/rfc6459#section-5.2 >> >> >> >> >> >>CB >> >>> Thanks, >>> >>> --julien >>> >>> >>> >>> _______________________________________________ >>> 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 rajiva@cisco.com Sun Nov 25 05:18:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC821F85A7 for ; Sun, 25 Nov 2012 05:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3yvVQA1oywv for ; Sun, 25 Nov 2012 05:18:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6473121F8551 for ; Sun, 25 Nov 2012 05:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4869; q=dns/txt; s=iport; t=1353849511; x=1355059111; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DUH2TOJp/+0MlnqtHl6T2HDIMvLsXc3l0ZwLbgl8ckY=; b=Y5wGGXoda4zqBY/28x5IU/Uj4jD79e7rcNRb07xrui8QT6S2UswGywYU MxRSLtWiMsj4qwwCSuJWyWyW40hX6m1lcrTFJfpYtdDvujfJKVTaWkrPo JXteshQGLPbXHYsaKQMIoyi+GlPqnhJIF+q577iC8svhJ6ATIMGnxH8sF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYZAEMZslCtJV2Z/2dsb2JhbABEgXQGAb5FFnOCHgEBAQQBAQE3NAsMBgEIEQMBAgsUMQYLHQgCBA4FCIdzAw8MszgNiVSLTmmDYGEDlCyCcYoYhRCCb4Id X-IronPort-AV: E=McAfee;i="5400,1158,6906"; a="145904881" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 25 Nov 2012 13:18:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAPDIUAU024166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Nov 2012 13:18:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.44]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Sun, 25 Nov 2012 07:18:30 -0600 From: "Rajiv Asati (rajiva)" To: jouni korhonen Thread-Topic: [v6ops] NUD and draft-byrne-v6ops-64share-03 Thread-Index: AQHNyE7JdfZgN8oHY02vek4D15enpZf1nCEAgAL3eYCAAlmPgP//sbKA Date: Sun, 25 Nov 2012 13:18:29 +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.2.4.120824 x-originating-ip: [10.82.217.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F544DFA5FE5844EA0FE8E99B957830A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 13:18:32 -0000 Jouni, That sounds good. In sync. Cheers, Rajiv -----Original Message----- From: jouni korhonen Date: Sunday, November 25, 2012 7:58 AM To: Rajiv Asati Cc: Cameron Byrne , Julien Laganier , "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 >Hi, > >On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) >wrote: >> >> Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. > >Correct. > > >> BTW, the below text in the security consideration section reads as if >> GGSN/PGW and UE are on-link (wrt IPv6), if read together with the next >> line. >> >> // >> 9. Security Considerations >> >> .. .. >> >> >> and the fact that the UE and the first-hop router (PDN-GW/GGSN or >> SGW) are the only nodes on the link. For off-link IPv6 attacks, the >> 3GPP EPS is as vulnerable as any IPv6 system. > >Excuse for my bad (non-native speaker) wording but that quote does not >try to hint anything about on-link properties of the prefix. It would >have been more appropriate quote the whole sentence where it also >refers to the actual link model (which then can be found in Section >5.2.) What was intended to say here is that if an off-link host can >launch an attack by sending IPv6 packets to the mobile host, then >generic IPv6 host security concerns apply. > >In general this is/will be (hopefully) a bit more precisely described >in draft-ietf-opsec-v6-01 and draft-ietf-v6ops-rfc3316bis. > >- Jouni > >> >> >> >> Cheers, >> Rajiv >> >> >> >> >> // >> 5.2. IPv6 Address Configuration >> >> .. .. >> >> >> In the 3GPP link model, the /64 prefix assigned to the UE cannot be >> used for on-link determination (because the L-bit in the Prefix >> Information Option (PIO) in the RA must always be set to zero). If >> the advertised prefix is used for SLAAC, then the A-bit in the PIO >> must be set to one. Details of the 3GPP link-model and address >> >> >> >> >> >> >> >> -----Original Message----- >> From: Cameron Byrne >> Date: Wednesday, November 21, 2012 10:47 PM >> To: Julien Laganier >> Cc: "v6ops@ietf.org" , >> "draft-byrne-v6ops-64share@tools.ietf.org" >> >> Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 >> >>>On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier >>>wrote: >>>> Hello, >>>> >>>> I have a question regarding the interaction between NUD and the method >>>> described in this draft. >>>> >>>> The GGSN/PGW acting as a default router advertises via IPv6 RAs a /64 >>>>prefix >>>> over the point-to-point link to the User Equipment. >>>> >>>> Assuming the User Equipment employs the method described in this draft >>>>and >>>> uses "the 3GPP network assigned /64 to assign itself a /128 subnet >>>>address >>>> to the 3GPP radio interface for consistent network reachability and >>>>the >>>>same >>>> address with a /64 subnet to the tethered LAN interface.The tethered >>>>LAN >>>> interface may then advertise the /64 subnet to the LAN with RA." >>>> >>>> Now a host on the tethered LAN will configure an IPv6 address with >>>>SLAAC >>>> based on the advertized /64, and starts to use it. >>>> >>>> When a downlink packets sent towards a host on the tethered LAN >>>>arrives >>>>at >>>> the GGSN/PGW, who believes the /64 is onlink, if the GGSN/PGW attempts >>>>NUD >>>> towards that destination address, in the current description of the >>>>method >>>> the UE will not reply (it has configured only one /128 on its >>>>interface >>>> facing the 3GPP network). Thus it seems GGSN/PGW initiated NUD will >>>>fail. >>>> >>>> So it seems to me that the current method would work only if a) the >>>>GGSN/PGW >>>> doesn't perform NUD for downlink packets sent over the point-to-point >>>>link, >>>> or b) the UE answers NUD probes for all addresses in the /64. >>>> >>>> Is this correct? >>>> >>> >>>AFAIK, the GGSN/PGW does not do NUD. The /64 is considered off-link >>>[1] and therefore no host resolution is done >>> >>>[1] http://tools.ietf.org/html/rfc6459#section-5.2 >>> >>> >>> >>> >>> >>>CB >>> >>>> Thanks, >>>> >>>> --julien >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 marka@isc.org Sun Nov 25 05:36:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B921F8551 for ; Sun, 25 Nov 2012 05:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+ANY7d1tt+p for ; Sun, 25 Nov 2012 05:36:46 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D526621F8546 for ; Sun, 25 Nov 2012 05:36:46 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 71876C95C3; Sun, 25 Nov 2012 13:36:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ac71:d37b:5942:37eb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 39244216C3D; Sun, 25 Nov 2012 13:36:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E33C92C1E08B; Mon, 26 Nov 2012 00:36:33 +1100 (EST) To: joel jaeggli From: Mark Andrews References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <50B18479.304@bogus.com> In-reply-to: Your message of "Sat, 24 Nov 2012 18:37:45 -0800." <50B18479.304@bogus.com> Date: Mon, 26 Nov 2012 00:36:33 +1100 Message-Id: <20121125133633.E33C92C1E08B@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 13:36:47 -0000 In message <50B18479.304@bogus.com>, joel jaeggli writes: > On 11/24/12 3:39 PM, Ted Lemon wrote: > > On Nov 24, 2012, at 2:12 PM, Gert Doering wrote: > >> I'm not necessarily married to reverse DNS, but I *like* that paradigm, > >> "every Internet-reachable host should have a name, and a FQDN at that". > > Why? > > what fqdn should a privacy address have? The reverse of a IPv6 address is a legal fully qualified hostname. R(address) PTR R(address) R(address) AAAA address When a host generates a new privacy address it adds a AAAA and PTR address pair for it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sthaug@nethelp.no Sun Nov 25 06:10:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7321F8531 for ; Sun, 25 Nov 2012 06:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P8e+8wIhl1Z for ; Sun, 25 Nov 2012 06:10:17 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 62E6D21F856C for ; Sun, 25 Nov 2012 06:10:16 -0800 (PST) Received: (qmail 74194 invoked from network); 25 Nov 2012 14:10:13 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 25 Nov 2012 14:10:13 -0000 Date: Sun, 25 Nov 2012 15:10:13 +0100 (CET) Message-Id: <20121125.151013.74684693.sthaug@nethelp.no> To: v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: <20121125133633.E33C92C1E08B@drugs.dv.isc.org> References: <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <50B18479.304@bogus.com> <20121125133633.E33C92C1E08B@drugs.dv.isc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 14:10:17 -0000 > > what fqdn should a privacy address have? > > The reverse of a IPv6 address is a legal fully qualified hostname. > > R(address) PTR R(address) > R(address) AAAA address > > When a host generates a new privacy address it adds a AAAA and PTR > address pair for it. And the whole point of this exercise is just to ensure that the IPv6 address has forward and reverse entries - but which don't really convey a lot of information... As an ISP, my immediate reaction is no thank you - this is extra complexity with no real benefits. I'd much rather spend my resources working to get rid of those systems and ISPs that *require* working DNS names for no good reason. Steinar Haug, AS 2116 From Ted.Lemon@nominum.com Sun Nov 25 06:16:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A821F8466 for ; Sun, 25 Nov 2012 06:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+BvOf-Ji2Mn for ; Sun, 25 Nov 2012 06:15:58 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0161D21F841B for ; Sun, 25 Nov 2012 06:15:57 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULIoGi+HSxsIAfsmhFni7HRqFaVCoBjT@postini.com; Sun, 25 Nov 2012 06:15:58 PST 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 2A0AE1B8075 for ; Sun, 25 Nov 2012 06:15:54 -0800 (PST) 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 20103190043; Sun, 25 Nov 2012 06:15:54 -0800 (PST) (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; Sun, 25 Nov 2012 06:15:48 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+wCgXH8AABACkIAACVEVgAAXWEKAAAdE3IA= Date: Sun, 25 Nov 2012 14:15:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> In-Reply-To: <20121125104739.GV19111@Space.Net> 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="Windows-1252" Content-ID: <95F6FD0DF9A53542B3C5538601E86D52@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 14:16:03 -0000 On Nov 25, 2012, at 5:47 AM, Gert Doering wrote: > I find it convenient to know who I'm talking to, or at least, where he's > coming from (like "chinatelecom.net" or "t-online.de"). You may find it convenient, but you don't actually know. You just have so= me information that someone you don't know put in the DNS. The idea that = this constitutes "knowing" in any meaningful sense is mistaken. I get wha= t you mean=97the information is often (at least apparently) accurate, and i= s useful at times. But I think it's important to recognize it for what it= is, and that means not taking it as something that can result in "knowing"= anything. Also, your argument refers specifically to PTR records; my question was, wh= y do we need A/AAAA records for all hosts that connect to the internets. = E.g., right now my laptop is an IPv4 and an IPv6 host. The IPv4 host exis= ts behind a NAT. No A record refers to it, because that's not possible. = Yet from a functional standpoint it is a host connected to the Internet. I would be the first to admit that my laptop's connection to the IPv4 inter= net is suboptimal. But what specifically am I, or are you, missing out on= because it doesn't have an A record? It also doesn't have an AAAA record= , because it's a pain to set up and I haven't bothered. What am I missing= out on because of this? Is it just that you can't identify my laptop by = name when it connects to your web server? On Nov 25, 2012, at 8:36 AM, Mark Andrews wrote: > When a host generates a new privacy address it adds a AAAA and PTR > address pair for it. Please, tell me what host you are talking about. Are you speaking theoret= ically, or referring to a specific implementation? From gert@space.net Sun Nov 25 08:36:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC93221F85C0 for ; Sun, 25 Nov 2012 08:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NYmxCNtObzA for ; Sun, 25 Nov 2012 08:36:46 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 8C07321F85B4 for ; Sun, 25 Nov 2012 08:36:46 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 571FA602A2 for ; Sun, 25 Nov 2012 17:36:45 +0100 (CET) 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 324DE6028F for ; Sun, 25 Nov 2012 17:36:45 +0100 (CET) Received: (qmail 52254 invoked by uid 1007); 25 Nov 2012 17:36:45 +0100 Date: Sun, 25 Nov 2012 17:36:45 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20121125163645.GA19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q34SDXSDkPcw2Le4" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 16:36:47 -0000 --Q34SDXSDkPcw2Le4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Nov 25, 2012 at 02:15:47PM +0000, Ted Lemon wrote: > I would be the first to admit that my laptop's connection to the IPv4 int= ernet is suboptimal. But what specifically am I, or are you, missing out = on because it doesn't have an A record? =20 Actually, the IPv4 address that shows up in my logs is quite likely to have a PTR record, and for most ISPs that use generic reverse DNS names, it will also have a matching A... 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 --Q34SDXSDkPcw2Le4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULJJHakuBuNlUUl1AQJDugP+ON4Ff+0R4gH/TFnSJ/rxsy3clh2UZANK uFBk8ITekSWh9ooepuKBZjq0V5pzfEuAtvmE3ydg/7csihy8u25hVeUYLVabS/Ye +H3E8jHfc9rofMYOYVajdYB84FLsk0tHXZB5zjGgsznD7warLOjuEHzutCabWG+R mCejB4zipg0= =XmJM -----END PGP SIGNATURE----- --Q34SDXSDkPcw2Le4-- From swmike@swm.pp.se Sun Nov 25 09:54:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0602021F85F0 for ; Sun, 25 Nov 2012 09:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKDxwZXwq5Ja for ; Sun, 25 Nov 2012 09:54:31 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6D21F85D8 for ; Sun, 25 Nov 2012 09:54:30 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5471E9C; Sun, 25 Nov 2012 18:54:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4C8669A; Sun, 25 Nov 2012 18:54:27 +0100 (CET) Date: Sun, 25 Nov 2012 18:54:27 +0100 (CET) From: Mikael Abrahamsson To: Gert Doering In-Reply-To: <20121125163645.GA19111@Space.Net> Message-ID: References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 17:54:32 -0000 On Sun, 25 Nov 2012, Gert Doering wrote: > Actually, the IPv4 address that shows up in my logs is quite likely to > have a PTR record, and for most ISPs that use generic reverse DNS names, > it will also have a matching A... Someone needs to put the functionality into all common dns servers to statelessly handle large zones of A and PTR, as in "in this /36, the forward/reverse format is if you don't have any other information". I want to overload some WHOIS info into dns for spam filtering as well, such as "in this /44, all customers are /56 unless otherwise more specifically stated". WHOIS doesn't really scale well for large number of lookups, DNS does, but for IPv6 we need some new operational practices (involving new code in the DNS servers). I don't know if an RFC is needed, but it would probably help. -- Mikael Abrahamsson email: swmike@swm.pp.se From Ted.Lemon@nominum.com Sun Nov 25 12:12:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450E821F8651 for ; Sun, 25 Nov 2012 12:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A90hHVuAf70p for ; Sun, 25 Nov 2012 12:12:16 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8203721F85B4 for ; Sun, 25 Nov 2012 12:12:16 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKULJ7oFf9IegsxvEu2LD/+Uv/cmMxEDcU@postini.com; Sun, 25 Nov 2012 12:12:16 PST 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 B544C1B80A3 for ; Sun, 25 Nov 2012 12:12:15 -0800 (PST) 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 AB6DA190043; Sun, 25 Nov 2012 12:12:15 -0800 (PST) (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; Sun, 25 Nov 2012 12:12:10 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+wCgXH8AABACkIAACVEVgAAXWEKAAAdE3IAABOxXgAAHhdOA Date: Sun, 25 Nov 2012 20:12:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747412B91@mbx-01.win.nominum.com> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> In-Reply-To: <20121125163645.GA19111@Space.Net> 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 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 20:12:17 -0000 On Nov 25, 2012, at 11:36 AM, Gert Doering wrote: > Actually, the IPv4 address that shows up in my logs is quite likely to > have a PTR record, and for most ISPs that use generic reverse DNS names, > it will also have a matching A... True, but it's not the address of the host, because the host has no address= . Anyway, it seems that you are saying that the reason for the rule that = hosts ought to have names is so that we can look them up. IOW, there is n= o benefit to the person who has the host, unless they want you to be able t= o look them up. From victor.kuarsingh@gmail.com Sun Nov 25 12:58:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1A521F862E for ; Sun, 25 Nov 2012 12:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSTfK4yPJEtU for ; Sun, 25 Nov 2012 12:58:41 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2605821F8613 for ; Sun, 25 Nov 2012 12:58:41 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so8632447ieb.31 for ; Sun, 25 Nov 2012 12:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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; bh=hnXxBuJFijv3bDRJrOXn6GUo99qG9gbLQ2lmKtJ1tQU=; b=FoZodBaSyOkSPQ7zlJHzlsPx/llyYB6VrRq8lEvnF0H3aH1v+nIyr56tGW9+uW2gPP 25rdv4PbmzReFER7Xho7HE8yV4Q1x3z2Be6r7KLsP4JIY8rOTRiFFjZow/90OtyE+pdb aYopxGTJjwT0HOWSpPPMABSxCmT0uL0uY5y0Lzc7a3uTjMBxLm/pUtilNlGY4zlAUDpe aHRqrY8eoe1un8z1XpkCzBxjWGZ50yYnINpyXV6NS8sMpqUojiNb93+Kkws1yXbB9NWa cgKIg6aOG5/SAAUr3+AkhT2WP90AGhX8gduoUj5DGHtsQsbi+jo8B5dvrF+6PQcWNufo N9oQ== Received: by 10.50.150.167 with SMTP id uj7mr11893530igb.33.1353877120599; Sun, 25 Nov 2012 12:58:40 -0800 (PST) Received: from [192.168.1.44] ([74.198.164.120]) by mx.google.com with ESMTPS id bg10sm9275777igc.6.2012.11.25.12.58.38 (version=SSLv3 cipher=OTHER); Sun, 25 Nov 2012 12:58:40 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 25 Nov 2012 15:58:56 -0500 From: Victor Kuarsingh To: Ted Lemon , Gert Doering Message-ID: Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747412B91@mbx-01.win.nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 20:58:41 -0000 On 2012-11-25 3:12 PM, "Ted Lemon" wrote: >On Nov 25, 2012, at 11:36 AM, Gert Doering wrote: >> Actually, the IPv4 address that shows up in my logs is quite likely to >> have a PTR record, and for most ISPs that use generic reverse DNS names, >> it will also have a matching A... > >True, but it's not the address of the host, because the host has no >address. Anyway, it seems that you are saying that the reason for the >rule that hosts ought to have names is so that we can look them up. >IOW, there is no benefit to the person who has the host, unless they want >you to be able to look them up. In line with what Gert said, your host does often have a A/PTR for the NAT address on your home gateway (assuming you are behind a gateway). If you are directly attached to a network (say a modem), then the ISP may often generate a A/PTR of the assigned address. Your "unnamed" host, according to many Internet hosts will have a name associated with it (the one associated with the NAT or directly addressed host). I am not saying this is good/bad, just noting how it works in many places today. As for IPv6, I will be honest and say that I am drawn to the notation that some continuity with what we had in IPv4 may be desired/needed. I understand many argue against this, but can we guarantee that we don't run into problems if we don't have this functionality for the future? Perhaps we don't absolutely need it now, but can we say never? I would say that there are some operational benefits of having this. I can say that resolving an address to a name can help in many regards (operational focus). Many times this information is know via various network/system state entries (I.e. DHCP, routing tables etc). But going the long way to resolve something may not be very optimal. Having a way of making this resolution quicker and more functional is a benefit in IMHO. Regards, Victor K > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Sun Nov 25 13:11:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D26421F8648 for ; Sun, 25 Nov 2012 13:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKxWsT0U51cd for ; Sun, 25 Nov 2012 13:11:10 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8821F8564 for ; Sun, 25 Nov 2012 13:11:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKULKJbv8MwJL9lNmAThiMriFTdMLhaTmx@postini.com; Sun, 25 Nov 2012 13:11:10 PST 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 954ED1B80BD for ; Sun, 25 Nov 2012 13:11:09 -0800 (PST) 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 89C0B190043; Sun, 25 Nov 2012 13:11:09 -0800 (PST) (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; Sun, 25 Nov 2012 13:10:57 -0800 From: Ted Lemon To: Victor Kuarsingh Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+wCgXH8AABACkIAACVEVgAAXWEKAAAdE3IAABOxXgAAHhdOAAAGiRwAAAGtKAA== Date: Sun, 25 Nov 2012 21:10:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747412CA0@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 21:11:11 -0000 To be clear, what I was asking is not "does somebody imagine a use for all = hosts having names." I can easily imagine this myself. What I was askin= g was what specific use case Gert had in mind. It seems pretty clear that= you and he both have the same use case in mind: being able to acquire advi= sory, untrusted information that may or may not truthfully name a node with= which you are exchanging packets. From gert@space.net Sun Nov 25 13:40:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF0A21F84C5 for ; Sun, 25 Nov 2012 13:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtDcUtAuv810 for ; Sun, 25 Nov 2012 13:40:52 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5521F84BB for ; Sun, 25 Nov 2012 13:40:51 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5CA8C602A6 for ; Sun, 25 Nov 2012 22:40:49 +0100 (CET) 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 325F660298 for ; Sun, 25 Nov 2012 22:40:49 +0100 (CET) Received: (qmail 46867 invoked by uid 1007); 25 Nov 2012 22:40:49 +0100 Date: Sun, 25 Nov 2012 22:40:49 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20121125214049.GC19111@Space.Net> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412B91@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yo1gx9odtFoEXWwG" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747412B91@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 21:40:53 -0000 --yo1gx9odtFoEXWwG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Nov 25, 2012 at 08:12:09PM +0000, Ted Lemon wrote: > On Nov 25, 2012, at 11:36 AM, Gert Doering wrote: > > Actually, the IPv4 address that shows up in my logs is quite likely to > > have a PTR record, and for most ISPs that use generic reverse DNS names, > > it will also have a matching A... >=20 > True, but it's not the address of the host, because the host has no addre= ss. Anyway, it seems that you are saying that the reason for the rule tha= t hosts ought to have names is so that we can look them up. IOW, there is= no benefit to the person who has the host, unless they want you to be able= to look them up. So what's the benefit to you, having a name? 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 --yo1gx9odtFoEXWwG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBULKQYakuBuNlUUl1AQI68QQAvc/KxCHnXPiwxe1tR1WnTcuHMu4myNmS pY5YNXs67xZ/nhvHMFKQpp/gqOrxnBPJ0ZZllDo2rf1CGVglmPZ7MIpbXIkRPiH6 brIAPBLv/PjjqeUBaFdCSijJHX1KJplerStiIasyJ/DrEtHFzCvxw2T5wgWF24lJ aNySLSY4wek= =kSXr -----END PGP SIGNATURE----- --yo1gx9odtFoEXWwG-- From aservin@lacnic.net Sun Nov 25 13:43:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3021F85D8 for ; Sun, 25 Nov 2012 13:43:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYRX2rXtb0Jd for ; Sun, 25 Nov 2012 13:43:07 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8858B21F84CD for ; Sun, 25 Nov 2012 13:43:07 -0800 (PST) Received: from [IPv6:2800:af:ba30:ff29:3420:a147:e1bc:f842] (unknown [IPv6:2800:af:ba30:ff29:3420:a147:e1bc:f842]) by mail.lacnic.net.uy (Postfix) with ESMTP id C200D308436 for ; Sun, 25 Nov 2012 19:43:03 -0200 (UYST) Message-ID: <50B290E6.10300@lacnic.net> Date: Sun, 25 Nov 2012 19:43:02 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <20121125115840.1c47fdae@simplex.0x539.de> <20121125110630.GW19111@Space.Net> In-Reply-To: <20121125110630.GW19111@Space.Net> X-Enigmail-Version: 1.4.6 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 version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 21:43:13 -0000 WEIRDS? It would be json and http. For some apps it may be easier than DNS. Regards, as On 25/11/2012 09:06, Gert Doering wrote: > Hi, > > On Sun, Nov 25, 2012 at 11:58:40AM +0100, Philipp Kern wrote: >> On Sun, 25 Nov 2012 11:47:39 +0100 Gert Doering >> wrote: >>> I find it convenient to know who I'm talking to, or at least, >>> where he's coming from (like "chinatelecom.net" or >>> "t-online.de"). >> >> well, as a provider you know the source AS. As a server provider >> we could solve that with CIDR lists? For after the fact matching >> like access log processing that should be doable. Currently we >> also have few enough /32 and PI /48 so that matching could be >> done on the fly. But that's obviously not guaranteed to remain >> that way??? > > Of course I can get the info with "whois" (or other tools) today, > but none of my machines knows how to do that. Reverse DNS is > simple, and they know how to query it - if someone's machine has > its own name, it will give it to me, and if the ISP only does > generic rDNS, this is a statement of its own... > > Gert Doering -- NetMaster > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From aservin@lacnic.net Sun Nov 25 13:48:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6021F8676 for ; Sun, 25 Nov 2012 13:48:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAJyndue8vej for ; Sun, 25 Nov 2012 13:48:52 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E521F8671 for ; Sun, 25 Nov 2012 13:48:52 -0800 (PST) Received: from [IPv6:2800:af:ba30:ff29:3420:a147:e1bc:f842] (unknown [IPv6:2800:af:ba30:ff29:3420:a147:e1bc:f842]) by mail.lacnic.net.uy (Postfix) with ESMTP id E3F14308445 for ; Sun, 25 Nov 2012 19:48:48 -0200 (UYST) Message-ID: <50B29240.1010205@lacnic.net> Date: Sun, 25 Nov 2012 19:48:48 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> In-Reply-To: X-Enigmail-Version: 1.4.6 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 version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 21:48:53 -0000 The "problem" with WHOIS is not scalability. It is that it does not contain information about single IP addresses. The granularity just goes to some level of allocation from ISPs to other entities. Scalability may be improved by WEIRDS work, but containing more granular information at IP level is much more complex. Regards, as On 25/11/2012 15:54, Mikael Abrahamsson wrote: > On Sun, 25 Nov 2012, Gert Doering wrote: > >> Actually, the IPv4 address that shows up in my logs is quite likely to >> have a PTR record, and for most ISPs that use generic reverse DNS >> names, it will also have a matching A... > > Someone needs to put the functionality into all common dns servers to > statelessly handle large zones of A and PTR, as in "in this /36, the > forward/reverse format is if you don't have any other > information". > > I want to overload some WHOIS info into dns for spam filtering as well, > such as "in this /44, all customers are /56 unless otherwise more > specifically stated". > > WHOIS doesn't really scale well for large number of lookups, DNS does, > but for IPv6 we need some new operational practices (involving new code > in the DNS servers). I don't know if an RFC is needed, but it would > probably help. > From Ted.Lemon@nominum.com Sun Nov 25 13:49:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E021F868D for ; Sun, 25 Nov 2012 13:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdjnJGo91UPY for ; Sun, 25 Nov 2012 13:49:58 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 159CC21F867B for ; Sun, 25 Nov 2012 13:49:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKULKShJYCU7e0YZqkekUl20cWbh9A2/g2@postini.com; Sun, 25 Nov 2012 13:49:58 PST 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 89AC31B80BD for ; Sun, 25 Nov 2012 13:49:56 -0800 (PST) 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 7E8C4190043; Sun, 25 Nov 2012 13:49:56 -0800 (PST) (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; Sun, 25 Nov 2012 13:49:50 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H+TYwvAYjHBnzSieDp2O6i+YS+wCgXH8AABACkIAACVEVgAAXWEKAAAdE3IAABOxXgAAHhdOAAAMYvoAAAFBRAA== Date: Sun, 25 Nov 2012 21:49:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747412D72@mbx-01.win.nominum.com> References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412B91@mbx-01.win.nominum.com> <20121125214049.GC19111@Space.Net> In-Reply-To: <20121125214049.GC19111@Space.Net> 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 Operations Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Nov 2012 21:49:58 -0000 On Nov 25, 2012, at 4:40 PM, Gert Doering wrote: > So what's the benefit to you, having a name? To my mind, the main benefit of having a name is that you want to be referr= ed to. So a host needs a name if other hosts will be contacting it at the= direction of humans. And, as you and Victor have suggested, it is also u= seful to have a name to call a host with which you are communicating, if a = human is going to be thinking about the relationship between the two endpoi= nts. So there's a clear purpose to naming a device if we want it to be a web ser= ver, or a file server, or something like that, and there's a clear purpose = to some kind of name if we want to be able to debug a connection. But the= se purposes relate to what function the host is serving, and aren't innate = qualities of the host. From swmike@swm.pp.se Sun Nov 25 19:13:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9DC21F86A9 for ; Sun, 25 Nov 2012 19:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CG3Untns8ud for ; Sun, 25 Nov 2012 19:13:12 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0525921F86A8 for ; Sun, 25 Nov 2012 19:13:11 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 510D69C; Mon, 26 Nov 2012 04:13:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4991E9A; Mon, 26 Nov 2012 04:13:09 +0100 (CET) Date: Mon, 26 Nov 2012 04:13:09 +0100 (CET) From: Mikael Abrahamsson To: Arturo Servin In-Reply-To: <50B29240.1010205@lacnic.net> Message-ID: References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> <50B29240.1010205@lacnic.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Nov 2012 03:13:15 -0000 On Sun, 25 Nov 2012, Arturo Servin wrote: > The "problem" with WHOIS is not scalability. It is that it does > not contain information about single IP addresses. The granularity just > goes to some level of allocation from ISPs to other entities. It depends on what problem you're trying to solve. If you want to convey "ip-w-x-y-z.isp.net", because people want to get an idea what ISP you're using, then you don't need individualism. -- Mikael Abrahamsson email: swmike@swm.pp.se From ek@google.com Mon Nov 26 23:49:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A305321F8670 for ; Mon, 26 Nov 2012 23:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfb3FSa5dxy6 for ; Mon, 26 Nov 2012 23:49:49 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07EEB21F862A for ; Mon, 26 Nov 2012 23:49:48 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so9411979qca.31 for ; Mon, 26 Nov 2012 23:49:48 -0800 (PST) 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=vOp4v5pl6kEwvTE+XgfC7pRZlD+OUG47YhKUPFcc1NE=; b=LBDs7n1YWLMwWa2iJx3LLMiWJIjjmL/oMunPeY1FCg3AFNzobCrs5XUl2K9sLzHQIu c2ihluAdLqf/dHGeE3rArNOLo0nIpAOHC6Vewtc2x4XZmp0XppPH3tlBEccXglLbuIq4 4ZHqztEUnJoji+b5unWGKUaBB3729s85nPryB77BWNIvmbjrXoAzA1r3/BapKs3Qd3Pb YSmpZsRmp7DKPDlP4uSCizYJPY2PDAukVPzla5EG4qbm9QxMzcpM6LvE6eh+ljlg5BzM MVJSmfGpZclCTorlRHbbJsNDVWmV/4ZX//qLXrIHQBG77quOVSfRkgzh3MzqUaOoc1GR U/aQ== 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=vOp4v5pl6kEwvTE+XgfC7pRZlD+OUG47YhKUPFcc1NE=; b=OkNMnQhKCgz+a+exmNT1R6tEnnvcNgs0xvGzoeiRyne9l6qJOFYoEeGOik7ieQQ2yo lcjhvsXnEhqYqHzmO0hPKgKfQ8w+L+IX+vhvn3oq8b1PlPDwqUSX+FNlIsiUZvKDi6xs GM3/yHP/8JLEmgnBi23VMvR5+mSlB7p1uw457b9CwIt0vyYtueqYE3rVxmRn8tMkhN7e 8c86He5iBF58AlzmeBF9Yp4NmPgbA6UdrsOGC6WJp/Y5B1AGKNdCMePc+QHxhEl8Yxz4 ZECnNJ7CZKvZtjd39xiLMmXWvqYnpixIvtfA8YneEbHy+snZFBVjYhBEH+bUFqQLiJrs Lbpw== Received: by 10.224.193.7 with SMTP id ds7mr15178150qab.23.1354002588341; Mon, 26 Nov 2012 23:49:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.142.15 with HTTP; Mon, 26 Nov 2012 23:49:28 -0800 (PST) In-Reply-To: <50A54899.1040902@bogus.com> References: <1353007976.97173.YahooMailNeo@web32502.mail.mud.yahoo.com> <50A54899.1040902@bogus.com> From: Erik Kline Date: Tue, 27 Nov 2012 16:49:28 +0900 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQke4RpGnUORvurcQW2HM8dLe2abbOx5SZFMaRI/oQY28Hj83YCTSLBsAuoUXB3ACcoTUxr8/Ys6vLckw5MDDEkK2VBDfKyGtDNQrLbVFRgZUtTPWkSWbeqvhBk1AETh94lVw5qhYsoYuKQxfMoNlScZ758yr43iN32ChPpXqES1TDxLMQ1wC8HXTyTfMkWvakDqMgo8 Cc: v6ops v6ops WG Subject: Re: [v6ops] Short presentation on "A Larger Loopback Prefix for 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, 27 Nov 2012 07:49:49 -0000 I'm generally in favor of it, but then I said the same thing 3 years ago: http://www.ietf.org/mail-archive/web/ipv6/current/msg11018.html I could even be convinced of something bigger than just a /48, but I haven't given it much thought. From gvandeve@cisco.com Tue Nov 27 04:34:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF70A21F84CA; Tue, 27 Nov 2012 04:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e0gqJ+5-IwM; Tue, 27 Nov 2012 04:34:46 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2021F84C7; Tue, 27 Nov 2012 04:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1354019686; x=1355229286; h=from:to:cc:subject:date:message-id:mime-version; bh=jilI+d7J8hhH5BQ1OYKseTxSsgjdK4brZ32gpHpdPB8=; b=JlEH27V66sOS8q8dGB0dlcyrl/7j+rQDxILQuQJmlu2hCgYJLxSGrIxu B5uCCwLk7nmJfAGK6gETaISpFxE/GL0hm1GvtWoyxNG2bCmCcXwbz0jcE 3zz/vzgCmkexP+aLTArjtl986GGEowVGeaLRrV/e+K749cQQMpa8CKllf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngLADOytFCtJXG8/2dsb2JhbABEgkmDGbpFgQIHgiABBB0QTBIBDB5WJgEEDg2IBQywGJBMjD6DVWEDlx2PKIJvgWgXHg X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146607396" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 27 Nov 2012 12:34:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qARCYjPG023820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:34:45 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:34:44 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" Thread-Index: Ac3Mmyvmk7+I5HczQcyRUdYsnOR6pw== Date: Tue, 27 Nov 2012 12:34:43 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "dhc@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "savi@ietf.org" Subject: [v6ops] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Nov 2012 12:34:46 -0000 --_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, During IETF85 meeting this draft was found useful as WG document by the OPS= EC WG. This is a call for WG adoption of this work. Please voice your comments in = OPSEC WG email alias. Latest document: http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-sh= ield/ Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

During IETF85 meeting this draft was found useful as= WG document by the OPSEC WG.

 

This is a call for WG adoption of this work. Please = voice your comments in OPSEC WG email alias.

 

Latest document: http://datatracker.ietf.org/doc/dra= ft-gont-opsec-dhcpv6-shield/

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_-- From gvandeve@cisco.com Tue Nov 27 04:44:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0821F84F6; Tue, 27 Nov 2012 04:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3IQodLIZejn; Tue, 27 Nov 2012 04:44:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0921F8530; Tue, 27 Nov 2012 04:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4183; q=dns/txt; s=iport; t=1354020294; x=1355229894; h=from:to:cc:subject:date:message-id:mime-version; bh=oax3ZHETYu6ufC9I/umISwezdwXYOHgE/Kmmrdd/XXA=; b=IXvkFWcWyyIqifGwG1G/KKkk9Rf5+1Aq6HkfgU1nbqiHDpzFc+y3iXs+ 3bZEDMafL/FeFpxMFL1MeRVQRklvaNYtKujGZbUVlDLiBrIrONF42xKmK sIdTs4ORiaBokArD1kub2i3JLTwBRa776gWfGNPWHO3qBTxNSxNz8/oEs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsLAIG0tFCtJXG9/2dsb2JhbABEgkmDGbEwiRWBAgeCGgYBBB0QTBIBKlYmAQQODYVBB4IfHgywGZBKkBNhA5cdjyiCb4Id X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146612011" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 27 Nov 2012 12:44:53 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qARCirLI026089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:44:53 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:44:53 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Call for WG adoption - Network Reconnaissance in IPv6 Networks Thread-Index: Ac3MnIXJcUynRZMASfCNcCJaERG/Rg== Date: Tue, 27 Nov 2012 12:44:52 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: [v6ops] Call for WG adoption - Network Reconnaissance in IPv6 Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Nov 2012 12:44:55 -0000 --_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear, Please find this request for WG adoption for "Network Reconnaissance in IPv= 6 Networks" This work is to update RFC5157. Please speak to voice your opinion. Latest draft can be found at: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear,

 

Pleas= e find this request for WG adoption for “= Network Reconnaissance in IPv6 Networks”

This = work is to update RFC5157. Please speak to voice your opinion.

=  

Lates= t draft can be found at:

http://tools.ietf.org/html/draft-gont-opsec-ipv6-= host-scanning-02

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_-- From gvandeve@cisco.com Tue Nov 27 04:57:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5031B21F8466; Tue, 27 Nov 2012 04:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzUXmG3ENNBc; Tue, 27 Nov 2012 04:57:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF421F8464; Tue, 27 Nov 2012 04:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2993; q=dns/txt; s=iport; t=1354021053; x=1355230653; h=from:to:cc:subject:date:message-id:mime-version; bh=nw2fSZKySjIWdNobkVNo4pL1xE//gg5S1kjzc6S0xyM=; b=hOggX5QD1fVcOirpl1jquKw9szHq9eY03uEa1Uucet8PJNF3TgMkR7G8 6x6rXUBhP0N0flYjEi9erMLnvzwd5de1xM5b+kdZGOq5E2o/mO+yKB46k asJwwVDeJaG2aUw8nL6wgS8T5BbpDVN0tPN7u4owSqpi0WNQSfypYdw5d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkLAAS4tFCtJV2a/2dsb2JhbABEgkmDGbpFgQIHgiABBB0QTBIBDB4ZPSYBBA4NiAUMsB2QS5ATYQOXHY8ogm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146396834" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2012 12:57:33 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qARCvXwM004704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:57:33 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:57:32 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Thread-Index: Ac3Mnk8XCC7UKWxNT+OWDCCme2iK1A== Date: Tue, 27 Nov 2012 12:57:32 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: [v6ops] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Nov 2012 12:57:34 -0000 --_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find this call as result of IETF85 OPSEC meeting for WG adoption for document http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/ Please speak out during the next 2 weeks on your opinion to adopt within OP= SEC or not adopt. Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Please find this call as result of IETF85 OPSEC meet= ing for WG adoption for

document http://datatracker.ietf.org/doc/draft-gont-= opsec-vpn-leakages/

 

Please speak out during the next 2 weeks on your opi= nion to adopt within OPSEC or not adopt.

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_-- From gert@space.net Tue Nov 27 05:03:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9721F84C7 for ; Tue, 27 Nov 2012 05:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysnr9pNNOujv for ; Tue, 27 Nov 2012 05:03:55 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id C356A21F84BB for ; Tue, 27 Nov 2012 05:03:54 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7EF8E6038C for ; Tue, 27 Nov 2012 14:03:53 +0100 (CET) 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 609AE60372 for ; Tue, 27 Nov 2012 14:03:53 +0100 (CET) Received: (qmail 21665 invoked by uid 1007); 27 Nov 2012 14:03:53 +0100 Date: Tue, 27 Nov 2012 14:03:53 +0100 From: Gert Doering To: "Gunter Van de Velde \(gvandeve\)" Message-ID: <20121127130353.GH19111@Space.Net> References: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Nov 2012 13:03:56 -0000 Hi, On Tue, Nov 27, 2012 at 12:57:32PM +0000, Gunter Van de Velde (gvandeve) wrote: > Please find this call as result of IETF85 OPSEC meeting for WG adoption for > document http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/ > > Please speak out during the next 2 weeks on your opinion to adopt within OPSEC or not adopt. Adopt. Useful operational security considerations -> opsec. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jeanmichel.combes@gmail.com Wed Nov 28 08:06:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9C21F88C9; Wed, 28 Nov 2012 08:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU81GbwdBJNo; Wed, 28 Nov 2012 08:06:53 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8821F8821; Wed, 28 Nov 2012 08:06:52 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6544465vbb.31 for ; Wed, 28 Nov 2012 08:06:52 -0800 (PST) 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=Fq561Uv544RjXy3tG6gepy0rWKCeDjcRzyghTNbcmA4=; b=ViJyvONAEX0TD3c+ejxWyxeI9+VUyXBdI/ICZ0B7bQkyq/6TA3cVlpJacaQtKAJPdc Q/SYXkaFU82JOSUeO2CK3rx5ACzVK0IxI7pkEJ0QinqTeZ6oyJ2Mjl6z9pbsVZGSWpPn MLYKwbffaG9l5VsHoZ/4ewFkEiCDRDa41GDC40poug1+h4jaVTd0mxRhsvg8TAbJxiHQ vzJiPzN+jWjQxCjuMlTox1n8iFJLdKjww/TGDPvcbydOmBNYjdzMKW3z65zmruWbm2Pn YXOWZdHXcGqn1tQvds+HeSkqcuG62N7qeBGmeO1tIzdNTfa2SeEw5F6kT14N5yWnxUut DIkQ== MIME-Version: 1.0 Received: by 10.52.29.141 with SMTP id k13mr25171647vdh.131.1354118812274; Wed, 28 Nov 2012 08:06:52 -0800 (PST) Received: by 10.221.7.9 with HTTP; Wed, 28 Nov 2012 08:06:52 -0800 (PST) In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> Date: Wed, 28 Nov 2012 17:06:52 +0100 Message-ID: From: Jean-Michel Combes To: "Gunter Van de Velde (gvandeve)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhc@ietf.org" , "opsec@ietf.org" , "savi@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [v6ops] [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Nov 2012 16:06:54 -0000 Hi, >From my point of view, this document doesn't compete with SAVI works (i.e., SAVI goals are to prevent IP address spoofing, using address assignment/management protocols signaling). Now, with DHCP SAVI (cf. https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/), we have the same feature, but with less details (i.e., process to identify a DHCPv6 message is not described in DHCP SAVI). As I already told during OPSEC meetings, DHCP Shield may be necessary in environment where DHCP SAVI is not deployed. Moreover, DHCP SAVI may use the process described in this document when performing DHCP signaling filtering. Unlike RA Guard, which only provides a mitigation (i.e., if you want a strong security, SEND is the right solution), there is a real need for DHCP Shield because, IMHO, there is no strong security for DHCP signaling today (PSK based security, currently specified, is not usable from a scalability point of view and CGA based security needs that DHCP clients must know the DHCP servers' IP unicast addresses). So, I support the adoption of this document as WG document. Best regards. JMC. 2012/11/27 Gunter Van de Velde (gvandeve) : > Hi folks, > > > > During IETF85 meeting this draft was found useful as WG document by the > OPSEC WG. > > > > This is a call for WG adoption of this work. Please voice your comments in > OPSEC WG email alias. > > > > Latest document: > http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-shield/ > > > > Kind Regards, > > OPSEC chairs > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From julien.ietf@gmail.com Wed Nov 28 09:52:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D8021F8843 for ; Wed, 28 Nov 2012 09:52:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dVOpX3+r5HF for ; Wed, 28 Nov 2012 09:52:09 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFE521F841C for ; Wed, 28 Nov 2012 09:52:09 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so9644714pbc.31 for ; Wed, 28 Nov 2012 09:52:09 -0800 (PST) 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=82jjeGOi+rEp3ofytsuiw1arT++vRlC2rlirYixng1o=; b=yPd41Og7rFZxlXG1P5xe8bVm6Wn9pYCN7oGuqJPgxRr27Ls4YXyt4P0FqfwTEQ8Su4 gfw+fbIHazxeZ6sjbUKmBL+NEX5WgOaQ/A54yOIt6bSnBZwv6HpfxwcNq+DaSU4Q4kuq JKx71cBtkSGDH+GGJ1rnS1vgwYKvAM1aJdzdQkOPN2OyqAURLT2joOQknRjj7Q3zw6XT sT5I50JN3Hzdr6OjXQbdVMSYzTs0AoBCd3oFNsu8Zl+qpJ7Ik6aryhVUCqQ0leO4oqAw l+lMIKM1trH4qupg4Luyzo/FUI/ihKr2dyvVOp9chT8l8uhGCTeaBFa5prEH6QiknE9S JjEw== MIME-Version: 1.0 Received: by 10.68.252.40 with SMTP id zp8mr60834371pbc.66.1354125129294; Wed, 28 Nov 2012 09:52:09 -0800 (PST) Received: by 10.68.127.163 with HTTP; Wed, 28 Nov 2012 09:52:09 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 09:52:09 -0800 Message-ID: From: Julien Laganier To: jouni korhonen Content-Type: multipart/alternative; boundary=047d7b2e09fd50232104cf91d33d Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Nov 2012 17:52:10 -0000 --047d7b2e09fd50232104cf91d33d Content-Type: text/plain; charset=ISO-8859-1 Rajiv and Jouni, On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen wrote: > Hi, > > On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) > wrote: > > > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. > > Correct. > > I know that there's no DAD for addresses in the /64. My comment was about NUD... --julien --047d7b2e09fd50232104cf91d33d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rajiv and Jouni,


On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen &l= t;jouni.nospam@= gmail.com> wrote:
Hi,

On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
>
> Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE.

Correct.


I know that th= ere's no DAD for addresses in the /64.=A0

My c= omment was about NUD...

--julien
--047d7b2e09fd50232104cf91d33d-- From jouni.nospam@gmail.com Thu Nov 29 00:17:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8AD21F89FA for ; Thu, 29 Nov 2012 00:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeWGTs1ASOF6 for ; Thu, 29 Nov 2012 00:17:46 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5BA321F8A26 for ; Thu, 29 Nov 2012 00:17:45 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so12151167lbk.31 for ; Thu, 29 Nov 2012 00:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hPBg2sNfLiNrezV88pg9jXuXVWtEkDlTAPX+NO4UInk=; b=yc8V8Hqp1U2tScVUL3WvVzSDXpf8OobpHgsmMFzdswOt+W6zoU5sHjce8pP+wlGaeA QXL9SoAOKJmcM+r1+x+v4Ue5aa6BRJ34TunCMIcDmm7NnE5ilWowlkx5EwwF3aHlLoEy afyYyUjl/1sFeKrijr4iuhuuVTlRc4M/fv1MP/lCRbwqPxAR77IlLqykQamfnaLRiX1Q nH4v4AkrPqxiRVlg0/W6UaWBA0tPyocHRkyt4oHqIXNsybUU0cmjG9KOhFxEvLZ4yl5R UClYwQP3WASDuGMXAyD2Qfe2PRH1ZXiq9g7vcMtSkDdpru66ok5BcxJm5EenA9eLnjOA mn8w== Received: by 10.152.106.237 with SMTP id gx13mr20468119lab.46.1354177064640; Thu, 29 Nov 2012 00:17:44 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id l9sm433211lbf.7.2012.11.29.00.17.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 00:17:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 29 Nov 2012 10:17:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Julien Laganier X-Mailer: Apple Mail (2.1085) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Nov 2012 08:17:46 -0000 On Nov 28, 2012, at 7:52 PM, Julien Laganier wrote: > Rajiv and Jouni, >=20 >=20 > On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen = wrote: > Hi, >=20 > On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) = wrote: > > > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. >=20 > Correct. >=20 >=20 > I know that there's no DAD for addresses in the /64.=20 >=20 > My comment was about NUD... And no NUD either. - Jouni >=20 > --julien