From nobody Sun May 1 04:47:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162B712D1E1 for ; Sun, 1 May 2016 04:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.117 X-Spam-Level: X-Spam-Status: No, score=-114.117 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGNAm7IodYKO for ; Sun, 1 May 2016 04:47:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9290B12B044 for ; Sun, 1 May 2016 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=137; q=dns/txt; s=iport; t=1462103224; x=1463312824; h=date:from:message-id:to:subject:cc; bh=giOduP820ef6Ngmde/FZSdafeStKYsZ2p2X3ezgL/iE=; b=RypStbLZrtqxQaiomurQVitPcgaedah4xqXTzROrg+IoXeUGbzz6PPSj jVruLQo6Ty405J7Wt1om0L6psNzupjl8IizHtMHkg/LV1o/4HnxNCLlEd gEv/GMrhrYVSNOTRMz1DH/EoEP7GEb+0N54RyUVAe5Pjxuc/YRrLzzhTf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CQCY6yVX/4ENJK1egzhTfqk6AZBJg?= =?us-ascii?q?XYihWUJgRw6EgEBAQEBAQFlJ4VBPDSJCgEOw0cBAQEHAQEBAQEbim2FCYUKBY5?= =?us-ascii?q?LiUmFfIltARVOg3+IXY8xJw0uhAuIMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,561,1454976000"; d="scan'208";a="103385555" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2016 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u41Bl3NG006652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 May 2016 11:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u41Bl3Dw021757; Sun, 1 May 2016 04:47:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u41Bl2f8021724; Sun, 1 May 2016 04:47:02 -0700 Date: Sun, 1 May 2016 04:47:02 -0700 From: fred@cisco.com Message-Id: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-anderson-v6ops-v4v6-xlat-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 11:47:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. Please take a look at it and comment. From nobody Sun May 1 06:00:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7612D519 for ; Sun, 1 May 2016 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRs2QSmWpLg1 for ; Sun, 1 May 2016 06:00:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F11E12D0B2 for ; Sun, 1 May 2016 06:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=906; q=dns/txt; s=iport; t=1462107625; x=1463317225; h=date:from:message-id:to:subject; bh=CPo7ftVrtq2gHPkS42CZTlw1c4jGtf6lVaI0Gihiul8=; b=ZwrH7hjhXLjwcGdIEq75SENnxuQEXNi/mH+imryuqSxYv3wk1h8gCahI QCNoXRqzazYixnOfesYo463uuaxfl77bI8lfZCkEBZMhhWTmZzgzEYFg6 fEy7dLSREqcQQkYiLq+jo3yDyKDt5TfbxpEfz5BcJWeTnt0RNLo0O4GZq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgD3/CVX/5FdJa1egzirCwGQOwENg?= =?us-ascii?q?XaHKjgUAQEBAQEBAWUnhX00iQoBo0mgFwEBCAEBAQEBG492hQoFjkuJSYEum3u?= =?us-ascii?q?PMR4BAUKEC4gxAQEB?= X-IronPort-AV: E=Sophos;i="5.24,562,1454976000"; d="scan'208";a="97549877" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 May 2016 13:00:25 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u41D0OtO020874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 May 2016 13:00:25 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u41D0Ohu007964 for ; Sun, 1 May 2016 06:00:24 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u41D0Onr007963 for v6ops@ietf.org; Sun, 1 May 2016 06:00:24 -0700 Date: Sun, 1 May 2016 06:00:24 -0700 From: fred@cisco.com Message-Id: <201605011300.u41D0Onr007963@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 13:00:27 -0000 RFC Editor: AUTH48,Sent to the RFC Editor 2016-02-29 draft-ietf-v6ops-mobile-device-profile RFC Editor: EDIT 2016-04-13 draft-ietf-v6ops-ipv6-ehs-in-real-world IESG: IESG Evaluation 2016-04-27 draft-bao-v6ops-rfc6145bis 2016-04-01 draft-ietf-v6ops-host-addr-availability WG: Unupdated WG Document 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem 2016-02-08 draft-ietf-v6ops-ula-usage-considerations 2016-01-21 draft-ietf-v6ops-unique-ipv6-prefix-per-host Individual Submission: Unupdated 2016-03-21 draft-ybai-v6ops-ipv6-for-openstack 2016-03-11 draft-gont-v6ops-ipv6-ehs-packet-drops 2016-02-27 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node 2016-01-05 draft-templin-v6ops-pdhost 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment Individual Submission: Updated 2016-05-01 draft-anderson-v6ops-v4v6-xlat-prefix From nobody Sun May 1 07:18:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2712B049 for ; Sun, 1 May 2016 07:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy3yE2PT0DAq for ; Sun, 1 May 2016 07:17:55 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3343E12B013 for ; Sun, 1 May 2016 07:17:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1112FA2; Sun, 1 May 2016 16:17:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1462112272; bh=Bd9nJRYZNwxFtVyb0CPABto4+CzrMWYCriJ7Yj6HOFM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=HmEOoOScjANfFoTLJqhUZO43U7epXLQNHvAjuyAKI/sh1zC5OTaRbwga2BFcunkKQ Q8MOtY3K2BJnkdX0F934T+SkTJiNNML07B30v4nNTgCAvjr5X03RqaFjqSe4FrPSuj vHoF2tGJyxYMh3PEr1YHDEgSHrq3Cwp8rxv4bEHE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 049C6A1 for ; Sun, 1 May 2016 16:17:52 +0200 (CEST) Date: Sun, 1 May 2016 16:17:51 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> Message-ID: References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 14:17:58 -0000 On Sun, 1 May 2016, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. Please take a look at it and comment. I like it. So this draft would update https://www.ietf.org/rfc/rfc5156.txt ? Or that isn't needed? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun May 1 11:01:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384F312D156 for ; Sun, 1 May 2016 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHCTDa8vuZUk for ; Sun, 1 May 2016 11:00:58 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756B012D14E for ; Sun, 1 May 2016 11:00:58 -0700 (PDT) Received: from [2a02:fe0:c420:874::8b1] (port=47101 helo=envy.e5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1awvfq-0007Zp-Rv; Sun, 01 May 2016 20:00:54 +0200 Date: Sun, 1 May 2016 20:00:54 +0200 From: Tore Anderson To: Mikael Abrahamsson Message-ID: <20160501200054.4dfa5a9d@envy.e5.y.home> In-Reply-To: References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 18:01:00 -0000 Hi Mikael, * Mikael Abrahamsson > > http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. > > I like it. > > So this draft would update https://www.ietf.org/rfc/rfc5156.txt ? Or > that isn't needed? I checked RFC6052 and RFC6666, which are examples of previously published documents that are designating special-use IPv6 prefixes. None of them update RFC5156. Therefore I am assuming it is not necessary. Tore From nobody Mon May 2 02:52:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183BB12D10A for ; Mon, 2 May 2016 02:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thFv-1npUckW for ; Mon, 2 May 2016 02:52:23 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB9112D0DA for ; Mon, 2 May 2016 02:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3289; q=dns/txt; s=iport; t=1462182743; x=1463392343; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5xbE25FeQ3CgftDFvaEGl0hzmcCyVG4zLVPAGmJmyIw=; b=P/o1EBRvjTEt9OVtxmoUnYj1NrduoPyWPnwg+eXlVqQRVOD10mZ0MMkl HwXdRg3SRUtg2a/tpsnfFOaNCsJE6lg7H+q1MCaKqiIqx711DFp1JPzr/ IzGTcSLeUH6XOkXFiofNhyglBrd1X01wTRv4pLO//bezgYGizPYQwjApF Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AgDbIidX/5hdJa1cgzhTfQa5bQ6Bd?= =?us-ascii?q?iKFbgKBJDgUAQEBAQEBAWUnhEEBAQEDAXkFCwIBCBguMiUCBA4FDogUCA64GAE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ0IiBcIgk6HaIIrBZgUAYMngWdtiByBZ06MX?= =?us-ascii?q?IYkiQwBHgFDg2tsAYgHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,566,1454976000"; d="asc'?scan'208";a="268464773" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 09:52:22 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u429qM8Y030990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 09:52:22 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 04:52:21 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 2 May 2016 04:52:21 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix Thread-Index: AQHRpFhSzghv5oHQ+k+cnDxBLi+o6A== Date: Mon, 2 May 2016 09:52:21 +0000 Message-ID: <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> In-Reply-To: <20160501200054.4dfa5a9d@envy.e5.y.home> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_97C8F032-292F-497D-B3B4-7CA8B29F242E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:52:25 -0000 --Apple-Mail=_97C8F032-292F-497D-B3B4-7CA8B29F242E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 1, 2016, at 11:00 AM, Tore Anderson wrote: >=20 > Hi Mikael, >=20 > * Mikael Abrahamsson >=20 >>> http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. >>=20 >> I like it. >>=20 >> So this draft would update https://www.ietf.org/rfc/rfc5156.txt ? Or >> that isn't needed? >=20 > I checked RFC6052 and RFC6666, which are examples of previously > published documents that are designating special-use IPv6 prefixes. > None of them update RFC5156. Therefore I am assuming it is not > necessary. We actually have a couple of prefixes that might be standardly used for = translation; one of them (64:ff9b::/96) is in RFC 6052, and another = (::ffff:0:0/96) in RFC 2765. They both have the property that the can't = be advertised in BGP, if one believes in 64 bit IIDs, 64:ff9b:: has the = property that several instances of it can be deployed in the same subnet = (64:ff9b::1:0/96, 64:ff9b::2:0/96, 64:ff9b::3:0/96...). So if the issue = is that you want a standard prefix that can have multiple instances in = the same network, that already exists. I would question whether you want = them all in the same subnet, but that's a fine point. In addition, in the CERNET2 IVI implementation, which also found its way = into RFC 6052, one can use a prefix from one's own allocation. CERNET2 = has the prefix straddle bit 64, so that they can multiple IPv4-embedded = prefixes matching IPv4 prefixes visible from outside, and if you really = want a /96, fine, use something like 2001:db8:0:1::/96, = 2001:db8:0:1::/96, and so on just like with 64:ff9b::/96. They would = have the properties of being able to have multiple translation instances = in the same network on DIFFERENT subnets, and also be able to be = advertised in BGP (whether you think that desirable or not being a = separate question). I'm scratching my head at what 64::/16 gives you that you don't already = have. --Apple-Mail=_97C8F032-292F-497D-B3B4-7CA8B29F242E 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----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVycjVEayAOS/EQ8MAQIKpA//UNZ3QYxXfx+5RflzV9MX4+o0QhdKMGlc HyjJD8EV5fhAcOmHQn/LeOA6BjlIRReXR4+arMqdH4IfVdsqBP2LslW8miiY6r7W QWQQdFG+SLKWBv5qmkZgTgeZFcmI7FaRWIEDS/CrLZqYZso5Rd0zRIMY/bLBqIw5 e+57kFbM4ybVxd0wxoSaaL93e5hjewdrnGgjIvFJ68Csk/AR/sS3fT+E15axQXJj T8fRnqez9nU368YAFBXDyQL1BV11QUmyaUPlsjxcDRqmSbKvpOArNcTgR36RR9yv /LiOLMD5S+9e/64tE7R6Ti9PA5Ezvybp2gAQW7p+spO6xAFDREI1JZuGBGqx87ZY LpZoG9Z/+omGtl+ZYuJ7SOrs8WbQxLo9cxN4KBFsXacFtvfh+SN0YBjOL1sxmGP5 GHz2dWA+d3lUMDLP5raFDa7p+bUesUQKtdXel85UzdoiavNilywSVMEtrK0dZbIW jMWCeHjh3GGZFRGnJqivYzAJnSR4zhHbBgNnxPcY+pPvnTws6aN7H9AxXXi7LqXF 7xkqIJHN6iSzfH+ENlnPJkiBZKToqGl1bWp3THK01cv6FNYj7JNL94TBfCWp2+ZA 3SuxIubzit15thdXJr9eakrkcRUXGyntZZVG2B4qhJD8U0ZpOd5C/bGrnadUJ3Nh Z4Tl6FkQteI= =nEth -----END PGP SIGNATURE----- --Apple-Mail=_97C8F032-292F-497D-B3B4-7CA8B29F242E-- From nobody Mon May 2 03:21:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3982112B051 for ; Mon, 2 May 2016 03:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HI8WKYms6Hx for ; Mon, 2 May 2016 03:21:51 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3C912B03F for ; Mon, 2 May 2016 03:21:51 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=33276 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1axAz7-0005Bm-88; Mon, 02 May 2016 12:21:49 +0200 Date: Mon, 2 May 2016 12:21:48 +0200 From: Tore Anderson To: "Fred Baker (fred)" Message-ID: <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> In-Reply-To: <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:21:53 -0000 Hi Fred, * "Fred Baker (fred)" > We actually have a couple of prefixes that might be standardly used > for translation; one of them (64:ff9b::/96) is in RFC 6052, and > another (::ffff:0:0/96) in RFC 2765. They both have the property that > the can't be advertised in BGP, if one believes in 64 bit IIDs, > 64:ff9b:: has the property that several instances of it can be > deployed in the same subnet (64:ff9b::1:0/96, 64:ff9b::2:0/96, > 64:ff9b::3:0/96...). So if the issue is that you want a standard > prefix that can have multiple instances in the same network, that > already exists. I would question whether you want them all in the > same subnet, but that's a fine point. The problem with this is that 64:ff9b::1:0/96, 64:ff9b::2:0/96, and 64:ff9b::3:0/96 all describe the exact same prefix. The "1", "2", and "3" digits are part of the suffix, and will by most tools be zeroed out. Thus you cannot, for example, configure your "blue" NAT64 instance with 64:ff9b::1:0/96, "red" NAT64 with 64:ff9b::2:0/96, "yellow" with 64:ff9b::3:0/96 and so on without creating an ambiguity or randomness as to which instance will be used for an packet sent to from 2001:db8::123 to 64:ff9b::192.0.2.0. What *would* have been nice to be able to do, is to for example have: 64:ff9b::0.0.0.0/96 - NAT64 blue 64:ff9b::1:0.0.0.0/96 - NAT64 red 64:ff9b::2:0.0.0.0/96 - NAT64 yellow 64::0.0.0.0/96 - NAT64 green 64:f00::/64 - SIIT black 64:1234:ff00::/40 IVI brown ...and so on. However, RFC6052 only allows for "NAT64 blue" in the list above, all the others would be squatting on unallocated space. This draft would change that. > In addition, in the CERNET2 IVI implementation, which also found its > way into RFC 6052, one can use a prefix from one's own allocation. > CERNET2 has the prefix straddle bit 64, so that they can multiple > IPv4-embedded prefixes matching IPv4 prefixes visible from outside, > and if you really want a /96, fine, use something like > 2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with > 64:ff9b::/96. They would have the properties of being able to have > multiple translation instances in the same network on DIFFERENT > subnets, and also be able to be advertised in BGP (whether you think > that desirable or not being a separate question). If you want do run IVI as specified in RFC6219 using your own GUA allocation you'll need a /32 (well, strictly speaking, you'll only need a /40 but it mandates that bits 33-40 are all "1", so either you need a /32 or be extremely lucky about which /40 you've got). Furthermore if you want to run two instances of IVI you most defintively need a /31. The standard assignment size an end user can reasonably expect to receive is on the other hand a /48, so much smaller and thus prevents the use of IVI. This draft would help with that, ensuring that everyone can run 64k instances of IVI in their network if they'd like (using 64:X:ff00::/40 where X can be any value from 0x0 to 0xffff). Tore From nobody Mon May 2 08:00:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B602912D567 for ; Mon, 2 May 2016 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKs3h4CR9atL for ; Mon, 2 May 2016 08:00:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAA312D55A for ; Mon, 2 May 2016 08:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3202; q=dns/txt; s=iport; t=1462201212; x=1463410812; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cuBesNCmEYvSX6xYWmPdSID5IAn/CPhbblG/NP0YMIk=; b=ezDXFIFA+8oqjKjVW5qrpSy5q+DuR5DDwvc+Tdcqk9NqAC9UTfV9nIZH FRtskCfxWULFCajSbRHaGHXrxhjvNa/aj/DRGTNIrY5g7bhB5aGV9gk9D SSNXyZF/S+E8oWGL7ETvo7VxDOAmzYBESLMaMX7bYFVcXad1q31Z0UgQI U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNBQBGaydX/5hdJa1egziBUAa7dIJOg?= =?us-ascii?q?0ICgS48EAEBAQEBAQFlJ4RBAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFAi6HAEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQ0IiBcIgk6HaIIrBZgUAYMngWeJCY8RjzABNyuCB?= =?us-ascii?q?RuBS2yICH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="asc'?scan'208";a="267930642" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 15:00:12 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u42F0B1B010062 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 15:00:12 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 10:00:11 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 2 May 2016 10:00:11 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix Thread-Index: AQHRpFhSzghv5oHQ+k+cnDxBLi+o6A== Date: Mon, 2 May 2016 15:00:11 +0000 Message-ID: References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> In-Reply-To: <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_E500609F-AF3C-45FE-8DCA-8B438C2CAAA0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 15:00:14 -0000 --Apple-Mail=_E500609F-AF3C-45FE-8DCA-8B438C2CAAA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 2, 2016, at 3:21 AM, Tore Anderson wrote: > * "Fred Baker (fred)" >> In addition, in the CERNET2 IVI implementation, which also found its >> way into RFC 6052, one can use a prefix from one's own allocation. >> CERNET2 has the prefix straddle bit 64, so that they can multiple >> IPv4-embedded prefixes matching IPv4 prefixes visible from outside, >> and if you really want a /96, fine, use something like >> 2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with >> 64:ff9b::/96. They would have the properties of being able to have >> multiple translation instances in the same network on DIFFERENT >> subnets, and also be able to be advertised in BGP (whether you think >> that desirable or not being a separate question). >=20 > If you want do run IVI as specified in RFC6219 using your own GUA > allocation you'll need a /32 (well, strictly speaking, you'll only = need > a /40 but it mandates that bits 33-40 are all "1", so either you need > a /32 or be extremely lucky about which /40 you've got). Furthermore = if > you want to run two instances of IVI you most defintively need a /31. > The standard assignment size an end user can reasonably expect to > receive is on the other hand a /48, so much smaller and thus prevents > the use of IVI. >=20 > This draft would help with that, ensuring that everyone can run 64k > instances of IVI in their network if they'd like (using 64:X:ff00::/40 > where X can be any value from 0x0 to 0xffff). Well, except that RFC 6052 allows for variants that CERNET2 didn't = choose. As I said, you could literally (and in this, I'm suggesting that = 2001:db8::/32 is standing in for your allocated prefix) use 2001:db8:0:0::/96 NAT64 blue 2001:db8:0:1::/96 NAT64 red 2001:db8:0:2::/96 NAT64 yellow and so on. So it's something already doable. --Apple-Mail=_E500609F-AF3C-45FE-8DCA-8B438C2CAAA0 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----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVydrekayAOS/EQ8MAQLlgQ//cpT3omC0ejyDG/CLEjQUNrhO08mtvJLH XL/hS0kNYTrZ41A5DECTWNKChV7qverYym6a37F1UuQuSZNFvuzcZKPWmEiONPpz YD7zpaE81Bb/OzjC697y8E4SQUUudO/aa9z+NCz1QGlCGsv5c4d4eeuR6bHbCL9Z vyg5mH356wdMwfSTrF5yPlxGF1Bk/+/T3Xv+a5xE0jgj6nHKP0Gyl5D6JD6q/OYN RK+uTXT8oyZamTjexp4epSHn9++bUCogSOnQg5ZWDMAWCDsFsjei24+i3Ll5kM9n /OchygVnFN65Q77EJBH92H0rxeaLaNibZu3rbAnlbhgd7XXeANonwxds7IvPc5yb xu1GqKU0Em4VMr5kMSYeyYD/sBIisAlvOIUGDizfXl2EeMnNzo3VEulQA5Ij4nLw 4JZjMey42n+NVJ89vCOfATq8K+7eMPfb38Zc5mxXHnZB6JfIMWZRv30kk+0j+cD1 HrlKVhEDX4exYcw3xBqBVtvq0YltvuYahrdLQIZIpUvnYnbhGGSransXLsVt4TpV 86cavvDNugjxqVp/QkbeapDcZ9buyU5cfrXbh/0XZHPqc/9mtAVzkNp8c1TgPCSZ eeAX6qa6oE2EWbnjjkO8xFNgkZJa6FYyNlVs561Y9KUcWihe/oFORK3rgDB6rkDO uC2wlOwDn0w= =rhBq -----END PGP SIGNATURE----- --Apple-Mail=_E500609F-AF3C-45FE-8DCA-8B438C2CAAA0-- From nobody Mon May 2 12:11:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26B912D168 for ; Mon, 2 May 2016 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPexIHFszfFY for ; Mon, 2 May 2016 12:11:30 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A613012D16B for ; Mon, 2 May 2016 12:11:30 -0700 (PDT) Received: from [2a02:fe0:c420:874::8b1] (port=52462 helo=envy.e5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1axJFf-0001Se-Id; Mon, 02 May 2016 21:11:27 +0200 Date: Mon, 2 May 2016 21:11:26 +0200 From: Tore Anderson To: "Fred Baker (fred)" Message-ID: <20160502211126.3272bb2c@envy.e5.y.home> In-Reply-To: References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:11:32 -0000 * Fred Baker (fred) > > On May 2, 2016, at 3:21 AM, Tore Anderson wrote: > > If you want do run IVI as specified in RFC6219 using your own GUA > > allocation you'll need a /32 (well, strictly speaking, you'll only need > > a /40 but it mandates that bits 33-40 are all "1", so either you need > > a /32 or be extremely lucky about which /40 you've got). Furthermore if > > you want to run two instances of IVI you most defintively need a /31. > > The standard assignment size an end user can reasonably expect to > > receive is on the other hand a /48, so much smaller and thus prevents > > the use of IVI. > > > > This draft would help with that, ensuring that everyone can run 64k > > instances of IVI in their network if they'd like (using 64:X:ff00::/40 > > where X can be any value from 0x0 to 0xffff). > > Well, except that RFC 6052 allows for variants that CERNET2 didn't > choose. As I said, you could literally (and in this, I'm suggesting > that 2001:db8::/32 is standing in for your allocated prefix) use > > 2001:db8:0:0::/96 NAT64 blue > 2001:db8:0:1::/96 NAT64 red > 2001:db8:0:2::/96 NAT64 yellow > > and so on. So it's something already doable. I probably have confused matters by talking about two different things (NAT64 and IVI) at once, sorry about that. I'll to be clearer: First off, I agree completely with your table above, when running multiple instances of NAT64 (RFC6146) and 96-bit prefixes, lack of available ISP/RIR-assigned global address space isn't likely to be a problem. /96s are easy to come by. IVI (RFC6219) is another matter entirely since it requires that the operator has a /40-bit (or more realistically a /32-bit) prefix (cf. section 3.1). The availability of ISP/RIR-assigned GUA space is thus quite likely to be a problem for operators wanting to deploy IVI. Available GUA space could also be a problem if you're running NAT64 or any other RFC6052-derivative technology, and for some reason want/need to use a NSP with a prefix length shorter than /64. As the I-D points out, the RFC6052 algorithm goes all the way down to /32 (see section 2.2). So that covers the "available space" part of the I-D's problem statement (which, to be clear, does not apply to RFC6052-derivative technologies like NAT64 when using 96-bit prefixes). The second part of the argument in the problem statement is that an operator might not *want* to use his own GUA space, regardless of how plentiful it might be. This is admittedly anecdotal, but it seems to me that this is the case for a majority of operators deploying NAT64 - pretty much every network I've visited that provide NAT64 service have been using the WKP 64:ff9b::/96 instead of using an NSP assigned from their own GUA space. So basically these operators are starting out with 64:ff9b::/96 for "NAT64 blue" (i.e., the first one to be deployed). If however at a later point in time they want to deploy another instance of NAT64 (or some other IPv4/IPv6 translation technology), they are currently forced to use GUA space even though that might not be what they prefer. I don't presume to know all the reasons why these operators are be preferring 64:ff9b::/96 over a GUA alternative, but speaking only for myself here's a few benefits: - Avoids making "the IPv4 internet" a subset of "my own network". Consider if your GUA assignment is 2001:db8:abc::/48, and you're IPv4/IPv6 translation system is using 2001:db8:abc::464:0.0.0.0/96. In this case, it is fairly easy to make the mistake of setting up some ACL or similar that treats 2001:db8:abc::/48 as "privileged" in some way, without realising that could also mean that the entire IPv4 internet has been granted the same access as internal clients. - Avoids advertising reachability to the IPv4/IPv6 translation system to the DFZ, if use of the system is intended only for internal/downstream nodes. There's no way to advertise "2001:db8:abc::/48 except 2001:db8:abc::464:0.0.0.0/96" in BGP. Using a distinct non-advertisable prefix provides a second line of defence against potential misuse of your translation system by unauthorised nodes anywhere on the global IPv6 internet. - The difference between addresses starting with "64:" instead of "20xy:" is immediately obvious, making it easy for a human operator reading logs or something to spot that an address is involved in some kind of IPv4/IPv6 translation instead of being just another regular IPv6 address. (Presumably this is the sole reason why RFC6052 reserved a WKP that started with "64:" in the first place.) Tore From nobody Mon May 2 16:33:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D459B12D68F for ; Mon, 2 May 2016 16:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOFk_H4wsoGU for ; Mon, 2 May 2016 16:33:18 -0700 (PDT) Received: from tsinghua.edu.cn (smtp33.tsinghua.edu.cn [166.111.204.57]) by ietfa.amsl.com (Postfix) with ESMTP id A683112D697 for ; Mon, 2 May 2016 16:33:16 -0700 (PDT) Received: from [127.0.0.1] (unknown [202.112.35.222]) by app4 (Coremail) with SMTP id DcxvpgAHldSa4ydXT1wgAA--.52119S3; Tue, 03 May 2016 07:33:02 +0800 (CST) Message-ID: <5727E39A.70005@cernet.edu.cn> Date: Tue, 03 May 2016 07:32:42 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040901090301090200020907" X-CM-TRANSID: DcxvpgAHldSa4ydXT1wgAA--.52119S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjDUYxBIdaVFxhVjvjDU0xZFpf9x0UUjRMFIVztD = X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 23:33:22 -0000 This is a multi-part message in MIME format. --------------040901090301090200020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fred Baker (fred) ??: >> On May 2, 2016, at 3:21 AM, Tore Anderson wrote: >> * "Fred Baker (fred)" >> >>> In addition, in the CERNET2 IVI implementation, which also found its >>> way into RFC 6052, one can use a prefix from one's own allocation. >>> CERNET2 has the prefix straddle bit 64, so that they can multiple >>> IPv4-embedded prefixes matching IPv4 prefixes visible from outside, >>> and if you really want a /96, fine, use something like >>> 2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with >>> 64:ff9b::/96. They would have the properties of being able to have >>> multiple translation instances in the same network on DIFFERENT >>> subnets, and also be able to be advertised in BGP (whether you think >>> that desirable or not being a separate question). >>> >> If you want do run IVI as specified in RFC6219 using your own GUA >> allocation you'll need a /32 (well, strictly speaking, you'll only need >> a /40 but it mandates that bits 33-40 are all "1", so either you need >> a /32 or be extremely lucky about which /40 you've got). Furthermore if >> you want to run two instances of IVI you most defintively need a /31. >> The standard assignment size an end user can reasonably expect to >> receive is on the other hand a /48, so much smaller and thus prevents >> the use of IVI. >> The RFC6219 just documents an example of IVI of using 2001:da8:ff00::/40, any prefixes defined in RFC6052 can be used. We have configurations in CERNET2 using multiple /48s and multiple /64s for different XLATs in production. When stateful NAT64 is used, we use well-known prefix, since no signaling scheme is required to pass the parameters of the prefix to DNS64, etc. >> This draft would help with that, ensuring that everyone can run 64k >> instances of IVI in their network if they'd like (using 64:X:ff00::/40 >> where X can be any value from 0x0 to 0xffff). >> > > Well, except that RFC 6052 allows for variants that CERNET2 didn't choose. As I said, you could literally (and in this, I'm suggesting that 2001:db8::/32 is standing in for your allocated prefix) use > > 2001:db8:0:0::/96 NAT64 blue > 2001:db8:0:1::/96 NAT64 red > 2001:db8:0:2::/96 NAT64 yellow > > and so on. So it's something already doable. > Yes. Regards, xing > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------040901090301090200020907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fred Baker (fred) 写道: 
On May 2, 2016, at 3:21 AM, Tore Anderson <tore@fud.no> wrote:
* "Fred Baker (fred)" <fred@cisco.com>
    
In addition, in the CERNET2 IVI implementation, which also found its
way into RFC 6052, one can use a prefix from one's own allocation.
CERNET2 has the prefix straddle bit 64, so that they can multiple
IPv4-embedded prefixes matching IPv4 prefixes visible from outside,
and if you really want a /96, fine, use something like
2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with
64:ff9b::/96. They would have the properties of being able to have
multiple translation instances in the same network on DIFFERENT
subnets, and also be able to be advertised in BGP (whether you think
that desirable or not being a separate question).
      
If you want do run IVI as specified in RFC6219 using your own GUA
allocation you'll need a /32 (well, strictly speaking, you'll only need
a /40 but it mandates that bits 33-40 are all "1", so either you need
a /32 or be extremely lucky about which /40 you've got). Furthermore if
you want to run two instances of IVI you most defintively need a /31.
The standard assignment size an end user can reasonably expect to
receive is on the other hand a /48, so much smaller and thus prevents
the use of IVI.

The RFC6219 just documents an example of IVI of using 2001:da8:ff00::/40, any prefixes defined in
RFC6052 can be used. We have configurations in CERNET2 using multiple /48s and multiple /64s
for different XLATs in production.

When stateful NAT64 is used, we use well-known prefix, since no signaling scheme is required to pass the
parameters of the prefix to DNS64, etc.


This draft would help with that, ensuring that everyone can run 64k
instances of IVI in their network if they'd like (using 64:X:ff00::/40
where X can be any value from 0x0 to 0xffff).
    

Well, except that RFC 6052 allows for variants that CERNET2 didn't choose. As I said, you could literally (and in this, I'm suggesting that 2001:db8::/32 is standing in for your allocated prefix) use

2001:db8:0:0::/96 NAT64 blue
2001:db8:0:1::/96 NAT64 red
2001:db8:0:2::/96 NAT64 yellow

and so on. So it's something already doable.

Yes.

Regards,

xing



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

--------------040901090301090200020907-- From nobody Mon May 2 17:54:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7930B12D690 for ; Mon, 2 May 2016 17:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiCa5406JHDP for ; Mon, 2 May 2016 17:54:42 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13BF12D53C for ; Mon, 2 May 2016 17:54:42 -0700 (PDT) Received: from [2a02:c0:2:4:1194:17:0:1006] (port=35007 helo=envy.e5.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1axObj-00012o-RF; Tue, 03 May 2016 02:54:36 +0200 Date: Tue, 3 May 2016 02:54:35 +0200 From: Tore Anderson To: Xing Li Message-ID: <20160503025435.5b8f4ef1@envy.e5.y.home> In-Reply-To: <5727E39A.70005@cernet.edu.cn> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> <5727E39A.70005@cernet.edu.cn> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 00:54:44 -0000 * Xing Li > The RFC6219 just documents an example of IVI of using=20 > 2001:da8:ff00::/40, any prefixes defined in > RFC6052 can be used. Hi Xing, That's interesting. I've always considered IVI to be fundamentally different from RFC6052 (and by extension RFC6145), as it seems to me that RFC6219 sections 3/3.1 prescribes an IVI address format that differs from RFC6052's in at least two respects: - RFC6219 specifies that =C2=ABbit 32 to bit 39 are all ones as the identifier of the IVI addresses=C2=BB, while RFC6052 does not mandate anything like that. - RFC6219 places bits 24-31 of the IPv4 address in bits 64-71 of the resulting IPv6 address, while RFC6052 places the same bits in 72-79 of the resulting IPv6 address (assuming a 40-bit prefix). Especially the second difference seems to me to create an unreconcilable incompatibility between the two algorithms. That is, if an IVI translator configured with the prefix 2001:db8:ff00::/40 attempts to translate the IPv4 address 198.51.100.123 to IPv6, it will per RFC6219 be translated to 2001:db8:ffc6:3364:7b00::. A RFC6052 translator using the same prefix would on the other hand translate the exact same IPv4 address to 2001:db8:ffc6:3364:007b:: instead. It seems to me, therefore, that in order to use stateless translation you'll need to use either IVI (per RFC6219) or SIIT (per RFC6052/RFC6145), and that if you attempt to mix the two in the same network it simply can't work very well. > We have configurations in CERNET2 using multiple /48s and > multiple /64s for different XLATs in production. In any case, "using multiple /48s .. for different XLATs" might be prohibitive for other operators regardless of which exact address mapping algorithm they're using, as the standard assignment size is a single /48 (or even smaller). While it might be possible to request a larger assignment, doing so will often involve a fair amount of LIR/RIR bureaucracy. The I-D would allow them to skip that and go straight to using locally significant prefixes drawn from 64::/16 instead. Tore From nobody Mon May 2 18:41:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7528612D102 for ; Mon, 2 May 2016 18:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GflqgioPnzv for ; Mon, 2 May 2016 18:41:43 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D6812D0C9 for ; Mon, 2 May 2016 18:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3944; q=dns/txt; s=iport; t=1462239703; x=1463449303; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ufHqYU0dCcNAHTidltJEtLG25KlHDNcllAdQDIj5yu8=; b=APOUl/SChH2Q/PRSs5UnediWBAXp5KHwLdWcpYtksl6agWnDG/jQVHr2 MsiaSQRH7vnFuO8GofDmVsu6SfJ9wjYMKeOS0BYJ1D0dwc5Rf+Ow67YVJ 81kU0H8L80oChBjpiHQiGiEmpnk0DUtbVntPLIXPMktgygYTsKv5Z1v5u 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtBQBFAShX/5tdJa1egziBUAa7f4YQA?= =?us-ascii?q?oE3PBABAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOiBQIqXqRHwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ0IiBcIgk6EDoMvK4IrBZgUAYMngWeDZIUlg?= =?us-ascii?q?WeNKoYkiQwBNyuDa2yHPX8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,570,1454976000"; d="asc'?scan'208";a="267323975" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 01:41:42 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u431fgsD002806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 01:41:42 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 20:41:41 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 2 May 2016 20:41:41 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix Thread-Index: AQHRpFhSzghv5oHQ+k+cnDxBLi+o6A== Date: Tue, 3 May 2016 01:41:41 +0000 Message-ID: <50531457-BB3C-43EE-A5F6-F0CAA871E204@cisco.com> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> <5727E39A.70005@cernet.edu.cn> <20160503025435.5b8f4ef1@envy.e5.y.home> In-Reply-To: <20160503025435.5b8f4ef1@envy.e5.y.home> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_54E736D8-ADF8-4246-A1C6-0800937B03A9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 01:41:45 -0000 --Apple-Mail=_54E736D8-ADF8-4246-A1C6-0800937B03A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2016, at 5:54 PM, Tore Anderson wrote: >=20 > * Xing Li >=20 >> The RFC6219 just documents an example of IVI of using >> 2001:da8:ff00::/40, any prefixes defined in >> RFC6052 can be used. >=20 > Hi Xing, >=20 > That's interesting. I've always considered IVI to be fundamentally > different from RFC6052 (and by extension RFC6145), as it seems to me > that RFC6219 sections 3/3.1 prescribes an IVI address format that > differs from RFC6052's in at least two respects: Interesting, as the origin of and fundamental argument for RFC 6145 was = to document IVI and update RFC 2765 with the CERNET experience. To me, = there is an operational difference in the way CERNET/CERNET2 deployed = it, but the algorithms are one and the same, the only difference being = the exact structure of the address. > - RFC6219 specifies that =C2=ABbit 32 to bit 39 are all ones as the > identifier of the IVI addresses=C2=BB, while RFC6052 does not mandate > anything like that. > - RFC6219 places bits 24-31 of the IPv4 address in bits 64-71 of the > resulting IPv6 address, while RFC6052 places the same bits in 72-79 > of the resulting IPv6 address (assuming a 40-bit prefix). >=20 > Especially the second difference seems to me to create an > unreconcilable incompatibility between the two algorithms. >=20 > That is, if an IVI translator configured with the prefix > 2001:db8:ff00::/40 attempts to translate the IPv4 address > 198.51.100.123 to IPv6, it will per RFC6219 be translated to > 2001:db8:ffc6:3364:7b00::. A RFC6052 translator using the same prefix > would on the other hand translate the exact same IPv4 address to > 2001:db8:ffc6:3364:007b:: instead. >=20 > It seems to me, therefore, that in order to use stateless translation > you'll need to use either IVI (per RFC6219) or SIIT (per > RFC6052/RFC6145), and that if you attempt to mix the two in the same > network it simply can't work very well. >=20 >> We have configurations in CERNET2 using multiple /48s and >> multiple /64s for different XLATs in production. >=20 > In any case, "using multiple /48s .. for different XLATs" might be > prohibitive for other operators regardless of which exact address > mapping algorithm they're using, as the standard assignment size is a > single /48 (or even smaller). While it might be possible to request a > larger assignment, doing so will often involve a fair amount of = LIR/RIR > bureaucracy. The I-D would allow them to skip that and go straight to > using locally significant prefixes drawn from 64::/16 instead. >=20 > Tore --Apple-Mail=_54E736D8-ADF8-4246-A1C6-0800937B03A9 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----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVygB1UayAOS/EQ8MAQL2Tw/+MiJIiwek/k1j5Mkr2dlqkVNaJmwjev3/ JXz8IZrssY9vbyZ3K1daU0XfwZpNE2/UShGpLcrfWx3/1Pj8qQ7APSXRP0RDfPNz EyVffSlSqL1dc7uz1kLrbt7H19ngj9mYtvHA38KTKly5Fqgs6+DiY2WQTAlhWQrV ADIU4Xe1dsbwXpQxVHIeFGGpvh1AZlfZywc83P2BcoYIgs7Vorsfs5qyYxiZEmuD PRoPiUd084WiJpKV25m/Fkx+5MHNcHexT9cjSEfQj+lIUN+FMpdF2laAkXP8LOsz zewSK+ct+566pU6SlBqdwDX/Tm1YGDjzvkDYoo3XoFTcvSiKGuyNyEzxeAUDCSOh dAnSMsUyl4u0VBdIGnsIC9qMz6xk6BYqe1+IMyWqqBY2DmPN2N+cuqQzsPp+1Ek1 Qv97L5hHLeFrgOIkyA3JbeB/5M8VoaJSVdE9mkosi+I23Kxpt/Tg5zKLDA+Cs646 Syo3+xIgQJzMx908uVTtiwYkmL/zRYrM6/ZvuR/DKVO8lerqReJApa49b6DEbGnh /mg3bul5ARaAbrbFjL3hFWq+Q1Czzv9hRv5igjbidIGGzZt+M7LGUNXsZOllxhaT pG9vdpMeGIYhXxxnqPOpO8DAbTcK3RgBh70UjSOE+kkj976Wjh3MjhZ7zzC+DN2Z N16IukEYUEg= =PBLG -----END PGP SIGNATURE----- --Apple-Mail=_54E736D8-ADF8-4246-A1C6-0800937B03A9-- From nobody Tue May 3 09:27:40 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B0812DA76; Tue, 3 May 2016 09:27:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503162731.8335.21186.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 09:27:31 -0700 Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] Alissa Cooper's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:27:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-host-addr-availability-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3: s/which is only available in 3GPP release 10/which has been made available as of 3GPP release 10/ Section 9.1: - May be better not to presume that operators do things "to avoid liability" - I don't think that particular sentence is necessary here. - I was surprised not to see a note here about interaction between this kind of host tracking and MAC address randomization, which I assume makes tracking harder independently of the whether the recommendations in this document are followed. But is it not discussed because operators who feel they need these kind of logs also prohibit MAC randomization? From nobody Tue May 3 14:37:46 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C37912D926; Tue, 3 May 2016 14:37:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503213743.8288.33797.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:37:43 -0700 Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] Kathleen Moriarty's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:37:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-v6ops-host-addr-availability-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the Complexity mentioned in section 4 should be a security consideration since there are more opportunities for mistakes that lead to data leakage. From nobody Tue May 3 15:22:46 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA35512D1AD; Tue, 3 May 2016 15:22:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503222244.8246.28466.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 15:22:44 -0700 Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] Ben Campbell's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 22:22:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-v6ops-host-addr-availability-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I am afraid the NAT66 cats are forever out of their bag, I am still glad to see this draft. Section 7: I _think_ the point of this section is to suggest that we cannot reasonably estimate an upper limit. But if it says that explicitly, I missed it. (I fear a careless reader will walk away thinking "20" is a good limit) Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to impose a hard limit/ From nobody Tue May 3 20:14:18 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82512D178; Tue, 3 May 2016 20:14:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504031415.8354.72069.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 20:14:15 -0700 Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 03:14:15 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-host-addr-availability-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3: * What is the term ePDG being used here? Can you please add a reference? The well known term in mobile networks is Evolved Packet Data Gateway that is used for IPsec tunnel termination. That does not seem to make sense here. * Maybe worth adding a reference to RFC7278 (64share) here as an example for "Extending the network (e.g., "tethering")." s/which is only available in 3GPP release 10/which is only available in 3GPP release 10 onwards/ Section 4: It is not clear what this bullet means. Can you clarify? " o Uncertainty, because it is not known in advance if a particular operation function will be available." From nobody Wed May 4 01:25:16 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76F12B018; Wed, 4 May 2016 01:25:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504082512.8358.20806.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 01:25:12 -0700 Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 08:25:12 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-v6ops-host-addr-availability-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I'm getting a bit outside my area of expertise here, but since I've been playing about with IPv6 recently and am not shy about asking silly questions... :-) - I think you're missing one other reason why people allocate /128's - in a hosting/VPS environment, the hoster might want to avoid VPS's that originate spam using many different source addresses over time so as to attempt to avoid IP address based (bad) reputation accruing to their outbound spam. Personally, I think associating such reputation scores with IPv6 prefixes or addresses is a bit dodgy, but this is I think something that is done in the wild, (no idea how frequently) so would be worth a mention. If you have good arguments as to why such a scheme is a bad idea, that'd be good to include as well. - I was a bit surprised to not see any mention here of ULAs. I've seen one DHCPv6 setup where my laptop was assigned a ULA with a very long lease in the hope of always having that connectivity to local systems that aren't all on the link. But having that plus real global addresses caused glitches as (I think) my OS (ubuntu) wasn't sure which of the addresses to use as the source for what. While I didn't explore what was going on there (I just zapped the lease:-), do you need to say how to handle cases where one has both real global and ULAs on an interface? - I would have liked if you had said that, other things being equal, OSes SHOULD prefer to use privacy addresses as the source address or as a default. Is there a reason to not say that? (Just wondering, I'm not trying to strongly argue that you do.) From nobody Wed May 4 08:12:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EDF12D713; Wed, 4 May 2016 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biZcV6LSuhjr; Wed, 4 May 2016 08:12:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C39C12D714; Wed, 4 May 2016 08:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w7ie00ptq+2hUMZ9UCV/oDV2oKA1ovdUmKLWn7n5raU=; b=gNSw6/xthvUsZRIzXoecB31GyhJEd5X+wq2CV8K7lP2Nw9huNwC1GRZA8VmwoVz6dHrvPPXs8TOX/MHauW4ZaySIh/AStjBr/Kz/5cAwhGAzKChXYzNf8WKXW8jHZs3yT/HE7IaSK7xFy7wVcPYDirHJZH9pOoDkqJRd8oNk6/4= Received: from BLUPR0501MB1044.namprd05.prod.outlook.com (10.160.35.143) by BLUPR0501MB1043.namprd05.prod.outlook.com (10.160.35.142) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 4 May 2016 15:10:58 +0000 Received: from BLUPR0501MB1044.namprd05.prod.outlook.com ([10.160.35.143]) by BLUPR0501MB1044.namprd05.prod.outlook.com ([10.160.35.143]) with mapi id 15.01.0477.016; Wed, 4 May 2016 15:10:58 +0000 From: Chris Bowers To: "rtgwg@ietf.org" , "v6ops@ietf.org" , "homenet@ietf.org" , "ipv6@ietf.org" , "routing-discussion@ietf.org" Thread-Topic: RTGWG Virtual Interim Meeting: May 31, 2016 Thread-Index: AdGlkFH1140hKmcyTVCsepgcooS0Tw== Date: Wed, 4 May 2016 15:10:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.11] x-ms-office365-filtering-correlation-id: 8cc861f5-964e-4640-37d9-08d3742e4c3b x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1043; 5:CitYsA2hzdNmJAdwkSrAbXXA/NLZEaM/KCdoPH5iG4QEhtSjRXcd818zmReb6J7wOEl5NGwF2oM2RBl037DF8Ll0gESF9K3JvObglTTmWMvMwtWr2/Lg0ZX4EsA1IaBhNgxSBiwByNB9uyD1puyvTg==; 24:oBzdpuZlsaHSujzxPwkIdjcE27S+u1/rlAH3puQM4Ccf9SuF7VrS9AhJ68e9wxYZOwNqjjCKX2CFrOTRRjb43KbMAZcu0d/V5JF/iJXZQqM=; 7:LNZuBFVWAA2PMJiTzKeMQAYc1WALI2pfmyb7dQ954qZEDBxSlAeFGbTPODZAJKr82VD1GO0mFpoUO5Y9wN385n8er12yXu8vVBs7/jCqOr0MLoj9zpV6yT+gp/snX3ibhl31v4SogLBsuCTDARTtpNx06255LHrcmXD2TbzFMXB3N67HWXsii7OnPuX3Na+3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1043; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(9101528026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1043; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1043; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(243025005)(377454003)(9686002)(77096005)(551544002)(3846002)(102836003)(50986999)(6116002)(74316001)(81166005)(4326007)(11100500001)(229853001)(5002640100001)(87936001)(1220700001)(10400500002)(5003600100002)(8936002)(5008740100001)(15975445007)(3480700004)(122556002)(92566002)(76576001)(16799955002)(86362001)(2201001)(2900100001)(2906002)(450100001)(19580395003)(2501003)(586003)(99286002)(3660700001)(19580405001)(5004730100002)(5001770100001)(3280700002)(33656002)(189998001)(66066001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1043; H:BLUPR0501MB1044.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 15:10:58.4232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1043 Archived-At: Cc: "rtgwg-chairs@ietf.org" , "rtgwg-ads@ietf.org" Subject: [v6ops] RTGWG Virtual Interim Meeting: May 31, 2016 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:12:35 -0000 RTGWG,=20 RTGWG will hold a virtual interim meeting on Tuesday May 31, 2016 from=20 10:00-12:00 Eastern Daylight Time (14:00-16:00 UTC).=20 The virtual interim will focus on the problem of ipv6 multi-homing with=20 provider-assigned addressing without NAT, and a proposed solution for=20 this problem, destination/source routing.=20 We have contacted several potential presenters based on the discussion=20 of this topic in Buenos Aires and on the RTGWG list and in v6ops. If you=20 are interested in presenting at this virtual interim and we have not=20 already contacted you, please contact us at rtgwg-chairs@ietf.org. We=20 are particularly interested in hearing from enterprises and service=20 providers, who are the ones affected by this problem and would need to=20 deploy and operate any solution we come up with.=20 A detailed agenda will be posted to the rtgwg mailing list at least a=20 week before the meeting. This initial announcement is being posted to rtgwg, v6ops, homenet,=20 6man, and routing-discussion mailing lists. We only plan to post=20 follow-up email related to this virtual interim to the rtgwg list, so=20 please subscribe to the rtgwg mailing list if you are interested in=20 following this. The WebEx details are as follows: RTGWG Virtual Interim Meeting=20 Tuesday, May 31, 2016=20 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs=20 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dma9394d256b2331260bd5416dc08fb5bd Meeting number: 648 728 108=20 Meeting password:interim1 Join by phone (US/Canada): 1-650-479-3208 International dial-in (PDF):=20 Thanks, Chris and Jeff From nobody Fri May 6 02:26:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B912D8DF for ; Fri, 6 May 2016 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44eQ7_EZGy0J for ; Fri, 6 May 2016 02:26:39 -0700 (PDT) Received: from tsinghua.edu.cn (smtp38.tsinghua.edu.cn [166.111.204.62]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4212D8E1 for ; Fri, 6 May 2016 02:26:38 -0700 (PDT) Received: from [127.0.0.1] (unknown [61.148.244.202]) by app4 (Coremail) with SMTP id DcxvpgAXHWUvYyxXK2osAA--.26S3; Fri, 06 May 2016 17:26:15 +0800 (CST) Message-ID: <572C6332.9070009@cernet.edu.cn> Date: Fri, 06 May 2016 17:26:10 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tore Anderson References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> <5727E39A.70005@cernet.edu.cn> <20160503025435.5b8f4ef1@envy.e5.y.home> In-Reply-To: <20160503025435.5b8f4ef1@envy.e5.y.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: DcxvpgAXHWUvYyxXK2osAA--.26S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjDUYxBIdaVFxhVjvjDU0xZFpf9x0UUjRNX1TBtD = X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 09:26:44 -0000 Hi, Tore, Tore Anderson 写é“: > * Xing Li > > >> The RFC6219 just documents an example of IVI of using >> 2001:da8:ff00::/40, any prefixes defined in >> RFC6052 can be used. >> > > Hi Xing, > > That's interesting. I've always considered IVI to be fundamentally > different from RFC6052 (and by extension RFC6145), as it seems to me > that RFC6219 sections 3/3.1 prescribes an IVI address format that > differs from RFC6052's in at least two respects: > I believe that the confusion is due to the RFC numbers. For the version 00s of RFC6052, RFC6145 and RFC6219, the pulication dates are RFC6219: Jul 2008 RFC6052: Oct 2008 RFC6145: Jul 2009 So the history of RFC6219 is longer than RFC6052 and RFC6145. Actually, RFC6052 and RFC6145 are more general versions of RFC6219 for address translation and header translation, respectively. The IESG at that time decided to publish proposed standards RFC6052 and RFC6145 first and then publish RFC6219 The RFC6219 says The IVI is an early design deployed in the CERNET for the stateless translation. The IETF standard IPv4-IPv6 stateless and stateful translation mechanisms are defined in [RFC6144], [RFC6052], [RFC6145], [RFC6146], and [RFC6147]. - [Page 5] of RFC6219. > - RFC6219 specifies that «bit 32 to bit 39 are all ones as the > identifier of the IVI addresses», while RFC6052 does not mandate > anything like that. > RFC6219 is a special NSP of /40 in RFC6052. +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix |v4(32) | u | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix |v4(24) | u |(8)| suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix |v4(16) | u | (16) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix |(8)| u | v4(24) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > - RFC6219 places bits 24-31 of the IPv4 address in bits 64-71 of the > resulting IPv6 address, while RFC6052 places the same bits in 72-79 > of the resulting IPv6 address (assuming a 40-bit prefix). > This is the u-oct issue when RFC6052 is published. However, the RFC7136 updates [RFC4291] which allows the use of unicast addresses without u-bit, as long as they're not derived from an IEEE MAC-layer address. Therefore, the u-oct defined in RFC6052 is not required, which is the RFC6219s format. > Especially the second difference seems to me to create an > unreconcilable incompatibility between the two algorithms. > > That is, if an IVI translator configured with the prefix > 2001:db8:ff00::/40 attempts to translate the IPv4 address > 198.51.100.123 to IPv6, it will per RFC6219 be translated to > 2001:db8:ffc6:3364:7b00::. A RFC6052 translator using the same prefix > would on the other hand translate the exact same IPv4 address to > 2001:db8:ffc6:3364:007b:: instead. > > > It seems to me, therefore, that in order to use stateless translation > you'll need to use either IVI (per RFC6219) or SIIT (per > RFC6052/RFC6145), and that if you attempt to mix the two in the same > network it simply can't work very well. > For the XLAT we are using (software and cisco), there is a configuration function for turning on u-oct (or not). So, as long as keep the address format consistent in the same XLAT domain, it should be no problem. > >> We have configurations in CERNET2 using multiple /48s and >> multiple /64s for different XLATs in production. >> > > In any case, "using multiple /48s .. for different XLATs" might be > prohibitive for other operators regardless of which exact address > mapping algorithm they're using, as the standard assignment size is a > single /48 (or even smaller). While it might be possible to request a > larger assignment, doing so will often involve a fair amount of LIR/RIR > bureaucracy. The I-D would allow them to skip that and go straight to > using locally significant prefixes drawn from 64::/16 instead. > If the prefixes for the IPv4-translatable and IPv4-converted addresses are the same, which is the default behavior defined in RFC6052, different /48s for different IPv4-translatables are perfectly fine. If different prefixes are used for IPv4-translatable and IPv4-converted addresses, it is also no problem. Regards, xing > Tore > > From nobody Fri May 6 02:54:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4BC12D561 for ; Fri, 6 May 2016 02:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W-q5YWrJBE4 for ; Fri, 6 May 2016 02:54:06 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C4C12B057 for ; Fri, 6 May 2016 02:54:05 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=46946 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aycSN-0006Zw-Jv; Fri, 06 May 2016 11:53:59 +0200 Date: Fri, 6 May 2016 11:53:59 +0200 From: Tore Anderson To: Xing Li Message-ID: <20160506115359.04d83fa1@echo.ms.redpill-linpro.com> In-Reply-To: <572C6332.9070009@cernet.edu.cn> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> <5727E39A.70005@cernet.edu.cn> <20160503025435.5b8f4ef1@envy.e5.y.home> <572C6332.9070009@cernet.edu.cn> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 09:54:07 -0000 * Xing Li > > That's interesting. I've always considered IVI to be fundamentally > > different from RFC6052 (and by extension RFC6145), as it seems to me > > that RFC6219 sections 3/3.1 prescribes an IVI address format that > > differs from RFC6052's in at least two respects:=20 >=20 > I believe that the confusion is due to the RFC numbers. For the version > 00s of RFC6052, RFC6145 and RFC6219, the pulication dates are > RFC6219: Jul 2008 > RFC6052: Oct 2008 > RFC6145: Jul 2009 >=20 > So the history of RFC6219 is longer than RFC6052 and RFC6145. Hi Xing, You're spot on - as IVI (RFC6219) was published later than RFC6052/RFC6145, coupled with the fact that neither RFC6052 nor RFC6145 makes no mention of =C2=ABIVI=C2=BB anywhere, has led me to believe that wh= en designing IVI it was decided not to use the RFC6052 algorithm, instead coming up with a slightly different and incompatible mapping. (The reason why has always puzzled me!) Thank you for explaining the history behind it. > > In any case, "using multiple /48s .. for different XLATs" might be > > prohibitive for other operators regardless of which exact address > > mapping algorithm they're using, as the standard assignment size is > > a single /48 (or even smaller). While it might be possible to > > request a larger assignment, doing so will often involve a fair > > amount of LIR/RIR bureaucracy. The I-D would allow them to skip > > that and go straight to using locally significant prefixes drawn > > from 64::/16 instead.=20 >=20 > If the prefixes for the IPv4-translatable and IPv4-converted > addresses are the same, which is the default behavior defined in > RFC6052, different /48s for different IPv4-translatables are > perfectly fine. Absolutely, but my point was that access to =C2=ABdifferent /48s=C2=BB is a= luxury that not everyone is likely to have. Most business-class ISPs I'm aware of will assign their customers only one /48, which will need to hold all the customer's deployed native IPv6 plus all his deployed translation technologies. So dedicating even a single /48 to a translation system might be impossible. Allowing such operators to assign locally significant /48s (or /40s or /32s or whatever their chosen technology needs) out of 64::/16 instead of restricting it to just 64:ff9b::/96 would help with that. Tore From nobody Fri May 6 04:23:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15C012D5DC for ; Fri, 6 May 2016 04:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Ltv0dZGwty for ; Fri, 6 May 2016 04:23:40 -0700 (PDT) Received: from tsinghua.edu.cn (smtp39.tsinghua.edu.cn [166.111.204.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6140512D5D2 for ; Fri, 6 May 2016 04:23:38 -0700 (PDT) Received: from [127.0.0.1] (unknown [58.200.235.32]) by app4 (Coremail) with SMTP id DcxvpgB3rtarfixXH7UsAA--.1027S3; Fri, 06 May 2016 19:23:24 +0800 (CST) Message-ID: <572C7EAD.9070704@cernet.edu.cn> Date: Fri, 06 May 2016 19:23:25 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tore Anderson References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <20160501200054.4dfa5a9d@envy.e5.y.home> <17BD8D5C-1619-41F3-B8CD-F26C28DFDE6A@cisco.com> <20160502122148.0e3bc19b@echo.ms.redpill-linpro.com> <5727E39A.70005@cernet.edu.cn> <20160503025435.5b8f4ef1@envy.e5.y.home> <572C6332.9070009@cernet.edu.cn> <20160506115359.04d83fa1@echo.ms.redpill-linpro.com> In-Reply-To: <20160506115359.04d83fa1@echo.ms.redpill-linpro.com> Content-Type: multipart/alternative; boundary="------------060205030203050806070106" X-CM-TRANSID: DcxvpgB3rtarfixXH7UsAA--.1027S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjDUYxBIdaVFxhVjvjDU0xZFpf9x0UUjRMn2TetD = X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 11:23:44 -0000 This is a multi-part message in MIME format. --------------060205030203050806070106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Toru, Tore Anderson 写é“: > * Xing Li > > >>> That's interesting. I've always considered IVI to be fundamentally >>> different from RFC6052 (and by extension RFC6145), as it seems to me >>> that RFC6219 sections 3/3.1 prescribes an IVI address format that >>> differs from RFC6052's in at least two respects: >>> >> I believe that the confusion is due to the RFC numbers. For the version >> 00s of RFC6052, RFC6145 and RFC6219, the pulication dates are >> RFC6219: Jul 2008 >> RFC6052: Oct 2008 >> RFC6145: Jul 2009 >> >> So the history of RFC6219 is longer than RFC6052 and RFC6145. >> > > Hi Xing, > > You're spot on - as IVI (RFC6219) was published later than > RFC6052/RFC6145, coupled with the fact that neither RFC6052 nor RFC6145 > makes no mention of «IVI» anywhere, has led me to believe that when > designing IVI it was decided not to use the RFC6052 algorithm, instead > coming up with a slightly different and incompatible mapping. (The > reason why has always puzzled me!) > > Thank you for explaining the history behind it. > You are welcome. > >>> In any case, "using multiple /48s .. for different XLATs" might be >>> prohibitive for other operators regardless of which exact address >>> mapping algorithm they're using, as the standard assignment size is >>> a single /48 (or even smaller). While it might be possible to >>> request a larger assignment, doing so will often involve a fair >>> amount of LIR/RIR bureaucracy. The I-D would allow them to skip >>> that and go straight to using locally significant prefixes drawn >>> from 64::/16 instead. >>> >> If the prefixes for the IPv4-translatable and IPv4-converted >> addresses are the same, which is the default behavior defined in >> RFC6052, different /48s for different IPv4-translatables are >> perfectly fine. >> > > Absolutely, but my point was that access to «different /48s» is a luxury > that not everyone is likely to have. Most business-class ISPs I'm aware > of will assign their customers only one /48, which will need to hold > all the customer's deployed native IPv6 plus all his deployed > translation technologies. So dedicating even a single /48 to a > translation system might be impossible. > I see what you mean now. For your information, at CERNET2 we also have production cases for using multiple /64s (NSP), as defined in RFC6052. +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Best regards, xing > Allowing such operators to assign locally significant /48s (or /40s > or /32s or whatever their chosen technology needs) out of 64::/16 > instead of restricting it to just 64:ff9b::/96 would help with that. > > Tore > > --------------060205030203050806070106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, Toru,

Tore Anderson 写é“: 
* Xing Li <xing@cernet.edu.cn>

  
That's interesting. I've always considered IVI to be fundamentally
different from RFC6052 (and by extension RFC6145), as it seems to me
that RFC6219 sections 3/3.1 prescribes an IVI address format that
differs from RFC6052's in at least two respects: 
      
I believe that the confusion is due to the RFC numbers. For the version
00s of RFC6052, RFC6145 and RFC6219, the pulication dates are
RFC6219: Jul 2008
RFC6052: Oct 2008
RFC6145: Jul 2009

So the history of RFC6219 is longer than RFC6052 and RFC6145.
    

Hi Xing,

You're spot on - as IVI (RFC6219) was published later than
RFC6052/RFC6145, coupled with the fact that neither RFC6052 nor RFC6145
makes no mention of «IVI» anywhere, has led me to believe that when
designing IVI it was decided not to use the RFC6052 algorithm, instead
coming up with a slightly different and incompatible mapping. (The
reason why has always puzzled me!)

Thank you for explaining the history behind it.

You are welcome.
  
In any case, "using multiple /48s .. for different XLATs" might be
prohibitive for other operators regardless of which exact address
mapping algorithm they're using, as the standard assignment size is
a single /48 (or even smaller). While it might be possible to
request a larger assignment, doing so will often involve a fair
amount of LIR/RIR bureaucracy. The I-D would allow them to skip
that and go straight to using locally significant prefixes drawn
from 64::/16 instead. 
      
If the prefixes for the IPv4-translatable and IPv4-converted
addresses are the same, which is the default behavior defined in
RFC6052, different /48s for different IPv4-translatables are
perfectly fine.
    

Absolutely, but my point was that access to «different /48s» is a luxury
that not everyone is likely to have. Most business-class ISPs I'm aware
of will assign their customers only one /48, which will need to hold
all the customer's deployed native IPv6 plus all his deployed
translation technologies. So dedicating even a single /48 to a
translation system might be impossible.

I see what you mean now. For your information, at CERNET2 we also have production
cases for using multiple /64s (NSP), as defined in RFC6052.
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |64|     prefix                    | u |   v4(32)      | suffix    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Best regards,

xing

Allowing such operators to assign locally significant /48s (or /40s
or /32s or whatever their chosen technology needs) out of 64::/16
instead of restricting it to just 64:ff9b::/96 would help with that.
  

Tore

--------------060205030203050806070106-- From nobody Sun May 8 10:12:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68B12D16F; Sun, 8 May 2016 10:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAyUYba2BTNX; Sun, 8 May 2016 10:12:17 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE08212D16D; Sun, 8 May 2016 10:12:16 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id m188so42479271vka.1; Sun, 08 May 2016 10:12:16 -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; bh=1UR6aUy5P5iual5LXWt5t6se46nYzgGXgPcBItPi8os=; b=trLNMsovLNer0IlRVlBBABxHj2mq9foZIA5MJd9LpSlu4ZBSOgRPXpLrANdomPP/KS Cq9bTKHghKYkBoPihi6hLWE2QxrpQKfI5Uj6Vv0KECnCfiRqLUwkj06tcb7NKvw9o+JS 3ulyRIPPZIHx6HLntZ+a3u5I/4nNbzOnLDJILKM2WTFepkkGwG1/M8998d6XLi2eF119 XjOigwtfvyDxZgzRkvengQ1SYMKcfVLpsC6CS3pqotOaL67jip5nj7Q+V7KQZUFVKfZd 4s44l2MFbCmEpaFggHqJ/RRE6rBiCaguTTKLr1E0ftwshf9pqvFZIX+nrLUkkRWcx3mN /MOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1UR6aUy5P5iual5LXWt5t6se46nYzgGXgPcBItPi8os=; b=lSK6kMD8VlBwCdZ/hjnZT2qdhRRR7PgbinkJKH3nZDPsx+B5KZvX2MTniAx/ij2jEZ fxbTk5K0GkuKu7yoPpwHhNshsQa6OuWOg2yoy2BP/HdWSNmO6Gg6JFhUtbqTx+GCY8nJ kMs1/XumYW+NavIP7J636QDngwO70uIDJy3zTDGCt9bw9fgD/Z35FJd0xRr72QPk5Tqt 8OkZJFgRhkWFXj3NmXBTuGo0FTwrqT0JQxB8AyVjoGETJuBxp3ZNclDeFlfDk88SxACQ LCh8ZBJk86oZcbOx79SGJ9jxVBngxUfBfMcLCi9cBxJLHoUkc84c84sYd+gy2g4wJrD4 VFtw== X-Gm-Message-State: AOPr4FXZx9NyYy5n7KJLlio4S+biWC+bb3708+4w3tx5PZREEhO0OafH9kB65/XVs6VKk6gNDCP+B54ZHbpEXA== MIME-Version: 1.0 X-Received: by 10.176.65.99 with SMTP id j90mr18352118uad.112.1462727535892; Sun, 08 May 2016 10:12:15 -0700 (PDT) Received: by 10.176.6.6 with HTTP; Sun, 8 May 2016 10:12:15 -0700 (PDT) In-Reply-To: <20160503213743.8288.33797.idtracker@ietfa.amsl.com> References: <20160503213743.8288.33797.idtracker@ietfa.amsl.com> Date: Sun, 8 May 2016 21:12:15 +0400 Message-ID: From: Musa Stephen Honlue To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=94eb2c12309a2e21f8053257cba9 Archived-At: Cc: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Kathleen Moriarty's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 17:12:19 -0000 --94eb2c12309a2e21f8053257cba9 Content-Type: text/plain; charset=UTF-8 Non objection. The terms of the document a clear enough and the reasons well convincing for the purpose defended here. 2016-05-04 1:37 GMT+04:00 Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com>: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-v6ops-host-addr-availability-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think the Complexity mentioned in section 4 should be a security > consideration since there are more opportunities for mistakes that lead > to data leakage. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c12309a2e21f8053257cba9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Non objection.

The terms of the documen= t a clear enough and the reasons well convincing for the purpose defended h= ere.

2= 016-05-04 1:37 GMT+04:00 Kathleen Moriarty <Kathleen.Moriar= ty.ietf@gmail.com>:
Kathlee= n Moriarty has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.or= g/doc/draft-ietf-v6ops-host-addr-availability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think the Complexity mentioned in section 4 should be a security
consideration since there are more opportunities for mistakes that lead
to data leakage.


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

--94eb2c12309a2e21f8053257cba9-- From nobody Tue May 10 23:49:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB77F12B02D for ; Tue, 10 May 2016 23:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AB515ydqtMh for ; Tue, 10 May 2016 23:49:45 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5456E12B01D for ; Tue, 10 May 2016 23:49:43 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 May 2016 08:49:41 +0200 X-IronPort-AV: E=Sophos;i="5.24,608,1454972400"; d="scan'208";a="453565352" Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 11 May 2016 08:49:31 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 11 May 2016 08:49:30 +0200 From: To: , Date: Wed, 11 May 2016 08:49:29 +0200 Thread-Topic: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix Thread-Index: AdGjn0Cc2wWCuOknSEGkdYwIdHdDDAHDkukw Message-ID: <88CAA5385EB5404392BF93106C8C53F8D4303E8842@HE111507.emea1.cds.t-internal.com> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> In-Reply-To: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: draft-anderson-v6ops-v4v6-xlat-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 06:49:49 -0000 Hello *, interesting draft, can something like this be added? "End hosts and end applications must not handle this address range speciall= y or make any assumptions on the handling of this address range within the = network they are connected to." Rationale: There are a lot of applications that assumed that they were behi= nd a NAT when they discovered an RFC1918 address and activated some kind of= NAT traversal. When the 100.64.0.0/10 prefix came for addressing clients (= shared address space, RFC6598), those applications failed because they were= still behind NAT but did not activate their NAT traversal option. Holger From nobody Wed May 11 05:16:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C9712DA61 for ; Wed, 11 May 2016 05:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG0nBO7RtESP for ; Wed, 11 May 2016 05:16:51 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35EB12D669 for ; Wed, 11 May 2016 05:16:51 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id m188so54174926vka.1 for ; Wed, 11 May 2016 05:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=czaqaJSC/p6/rQEMtfd8GQbnLXn9TxdssbYhLhYJrVE=; b=iWMFQ17rska05PTDYQrrMwMSUJcgKEL4IocHUYRitYiaI1gaCS+2IZLrTMIbCenOtN O4tho2NTwA74yk2m2bPoBHuv5F6ZgvupgR51DaHPNIe2A7tl9bSCPI7gZf3NqvffCSuM WBElMWSaHbirdQrEsnGMcT6EKWDQzmTP+dvBDeTzYK7qdJsJq48v5UKg9F2s7ooIKOxP ZbmJmsnOcNthf/VX1LDCr/H63FMAKawyNfrLcaCthAyXOpAm9rZRCfsIycsPveMmQXec ovU9ZaFoJKFj9kuk13yz6DHnFwNKCe8eGSf1e8GGyH0QD/0hikdcotyEWRl3zkDbHujc 2qMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=czaqaJSC/p6/rQEMtfd8GQbnLXn9TxdssbYhLhYJrVE=; b=TxWQ9SUPME+So1QhRte6nBhQ6PhqjspwIFGXzdIQi048WOkti3NInmpKli/7iYdPDZ MOWzpqLoJw7MV2Z2Qh7ox99Bu65/j8CSgtvSh9+InQqi9G0vOAwvwgjSRZ1TasS2DI7Z B3Wxikpp62cqQswJBXQLIiIA8lhV66s+TbwUAfUWsp1Rc48azw718V7UdCwsR7P31iHY eQdHlmrWzjYINwVw49+KNhvMmQpeoWTYZktQx8+jwhupRAm3o2nvwe2O0a8YMNywQjrf 4gt7PLxLfobaf1bwIEjlM/cwkkmXztyh7wnIn8Ba1c3IEWKZgZ5sXZcBA+In6Nq1ora6 XoXw== X-Gm-Message-State: AOPr4FWWo6oatOrorJEUJji933zwDwaeUzKKoCeKjJB5Ggq/mzlCQKJ5KtNQcaHCiHirZg== X-Received: by 10.31.81.199 with SMTP id f190mr1279232vkb.139.1462969010787; Wed, 11 May 2016 05:16:50 -0700 (PDT) Received: from [192.168.1.18] ([186.188.83.77]) by smtp.googlemail.com with ESMTPSA id o199sm1229212vkd.25.2016.05.11.05.16.49 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 05:16:49 -0700 (PDT) To: v6ops@ietf.org References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <88CAA5385EB5404392BF93106C8C53F8D4303E8842@HE111507.emea1.cds.t-internal.com> From: Alejandro Acosta Message-ID: <11fea2f3-7d54-3408-28d8-218fa93c9420@gmail.com> Date: Wed, 11 May 2016 08:16:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <88CAA5385EB5404392BF93106C8C53F8D4303E8842@HE111507.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 12:16:54 -0000 Agree El 5/11/2016 a las 2:49 AM, holger.metschulat@telekom.de escribió: > Hello *, > > interesting draft, can something like this be added? > > "End hosts and end applications must not handle this address range specially or make any assumptions on the handling of this address range within the network they are connected to." > > Rationale: There are a lot of applications that assumed that they were behind a NAT when they discovered an RFC1918 address and activated some kind of NAT traversal. When the 100.64.0.0/10 prefix came for addressing clients (shared address space, RFC6598), those applications failed because they were still behind NAT but did not activate their NAT traversal option. > > Holger > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 12 00:08:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB7112D782 for ; Thu, 12 May 2016 00:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WktE35IinhV for ; Thu, 12 May 2016 00:08:06 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6A412D87E for ; Thu, 12 May 2016 00:08:05 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=41888 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1b0kj0-00018d-IN; Thu, 12 May 2016 09:07:58 +0200 Date: Thu, 12 May 2016 09:07:58 +0200 From: Tore Anderson To: Message-ID: <20160512090758.77fb06dc@echo.ms.redpill-linpro.com> In-Reply-To: <88CAA5385EB5404392BF93106C8C53F8D4303E8842@HE111507.emea1.cds.t-internal.com> References: <201605011147.u41Bl2f8021724@irp-lnx1.cisco.com> <88CAA5385EB5404392BF93106C8C53F8D4303E8842@HE111507.emea1.cds.t-internal.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, draft-anderson-v6ops-v4v6-xlat-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 07:08:08 -0000 * > interesting draft, can something like this be added? > > "End hosts and end applications must not handle this address range > specially or make any assumptions on the handling of this address > range within the network they are connected to." > > Rationale: There are a lot of applications that assumed that they > were behind a NAT when they discovered an RFC1918 address and > activated some kind of NAT traversal. When the 100.64.0.0/10 prefix > came for addressing clients (shared address space, RFC6598), those > applications failed because they were still behind NAT but did not > activate their NAT traversal option. Yes, I can add something like that. Thank you for the suggestion. Tore From nobody Tue May 17 06:48:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6641912D5DC; Tue, 17 May 2016 06:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tobbBEhO2hPU; Tue, 17 May 2016 06:47:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC2E12D169; Tue, 17 May 2016 06:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SKJT+sUKGm/DVAWcnoi/PLc22/doeS8psKuZaqlTc6I=; b=aoLEFvnL7V/DJe+V08EPF1BaYVncmCoGFGSLFCxfCtnNfO/N7BdHGdFwasmdKFEgUwfWd7rRPJhVE7n8edSuqQMvzcmwOnvt3R19glvJZAyQF282hvtei4kIfVJav4GCtCrGSHcPRt3xQWHIgyR1tmAeGCuEtGxNmbH6NUduHvM= Received: from BLUPR0501MB1044.namprd05.prod.outlook.com (10.160.35.143) by BLUPR0501MB1043.namprd05.prod.outlook.com (10.160.35.142) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 17 May 2016 13:47:54 +0000 Received: from BLUPR0501MB1044.namprd05.prod.outlook.com ([10.160.35.143]) by BLUPR0501MB1044.namprd05.prod.outlook.com ([10.160.35.143]) with mapi id 15.01.0492.020; Tue, 17 May 2016 13:47:55 +0000 From: Chris Bowers To: "rtgwg@ietf.org" Thread-Topic: RTGWG Virtual Interim Meeting: May 31, 2016 Thread-Index: AdGlkFH1140hKmcyTVCsepgcooS0TwKsQqqw Date: Tue, 17 May 2016 13:47:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.14] x-ms-office365-filtering-correlation-id: 23ab07d1-cafa-481f-09d4-08d37e59d92b x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1043; 5:nXIRB9BTFZDS+r/5/fDdiR+nVEEQKhHHe254UPyqsAXlJ+t4h5Dixw/tFM5wU+/Gcvo0RWjEiqNlzOQ73xAshxQKrW78OGcsXQlNL7Nt2skx1qLsrYB4+LsLm4Qc85kDylLBQ/tWU6Cyh99LdqwXqQ==; 24:FhlCPYQMSg7sEpfyC7yTsAVhLkfdulmM1gzq6I0OLzJYybnBqgrwhnphNaM6hUYwnIQvDJGT7ReEb1WXDHMDSo+oBKanx28JNR13+9+A3pY=; 7:dTtGTAztlnKuVUeXVTybAbE4GrGvtuPq+QV/0WzMIZbCzgiWRMLiJcwGoYVkTW2xW1QIT8yt94Ijy8chpBCKlxvF8z5ZjbObf6LqbVH0sp+b51rIB0KsJKamM51HxCUGnIpKxJ5iSvIq1g5PT3sQMIdahmKen64FoafItOPz5B8IJumOE+CcHoPgME5X67Qu x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1043; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB1043; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1043; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(243025005)(13464003)(377454003)(54356999)(87936001)(10400500002)(92566002)(76176999)(76576001)(2501003)(50986999)(5003600100002)(122556002)(586003)(102836003)(2906002)(2950100001)(77096005)(2900100001)(3846002)(8936002)(19580405001)(33656002)(19580395003)(66066001)(1220700001)(86362001)(5002640100001)(3480700004)(4326007)(15975445007)(6116002)(5004730100002)(189998001)(5008740100001)(110136002)(3660700001)(1730700003)(16799955002)(551544002)(5640700001)(2351001)(99286002)(9686002)(74316001)(3280700002)(81166006)(8676002)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1043; H:BLUPR0501MB1044.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 13:47:54.8945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1043 Archived-At: Cc: "homenet@ietf.org" , "rtgwg-chairs@ietf.org" , "rtgwg-ads@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] RTGWG Virtual Interim Meeting: May 31, 2016 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 13:47:58 -0000 RTGWG, We have posted the tentative agenda for the RTGWG Virtual Interim=20 on Tuesday, May 31. It can be found at: https://www.ietf.org/proceedings/interim/2016/05/31/rtgwg/agenda/agenda-int= erim-2016-rtgwg-1 Thanks to everyone who volunteered to present. We should have a very=20 interesting set of presentations and discussions. Here is the iCalendar invite as well: https://ietf.webex.com/ietf/j.php?MTID=3Dm4ab707a77ed821f6978b2614f15cff96 Thanks, Chris and Jeff -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net]=20 Sent: Wednesday, May 04, 2016 10:11 AM To: rtgwg@ietf.org; v6ops@ietf.org; homenet@ietf.org; ipv6@ietf.org; routin= g-discussion@ietf.org Cc: rtgwg-chairs@ietf.org; rtgwg-ads@ietf.org Subject: RTGWG Virtual Interim Meeting: May 31, 2016 RTGWG,=20 RTGWG will hold a virtual interim meeting on Tuesday May 31, 2016 from=20 10:00-12:00 Eastern Daylight Time (14:00-16:00 UTC).=20 The virtual interim will focus on the problem of ipv6 multi-homing with=20 provider-assigned addressing without NAT, and a proposed solution for=20 this problem, destination/source routing.=20 We have contacted several potential presenters based on the discussion=20 of this topic in Buenos Aires and on the RTGWG list and in v6ops. If you=20 are interested in presenting at this virtual interim and we have not=20 already contacted you, please contact us at rtgwg-chairs@ietf.org. We=20 are particularly interested in hearing from enterprises and service=20 providers, who are the ones affected by this problem and would need to=20 deploy and operate any solution we come up with.=20 A detailed agenda will be posted to the rtgwg mailing list at least a=20 week before the meeting. This initial announcement is being posted to rtgwg, v6ops, homenet,=20 6man, and routing-discussion mailing lists. We only plan to post=20 follow-up email related to this virtual interim to the rtgwg list, so=20 please subscribe to the rtgwg mailing list if you are interested in=20 following this. The WebEx details are as follows: RTGWG Virtual Interim Meeting=20 Tuesday, May 31, 2016=20 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs=20 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dma9394d256b2331260bd5416dc08fb5bd Meeting number: 648 728 108=20 Meeting password:interim1 Join by phone (US/Canada): 1-650-479-3208 International dial-in (PDF):=20 Thanks, Chris and Jeff From nobody Mon May 23 08:25:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6D12D095 for ; Mon, 23 May 2016 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqYaCTjzFOm3 for ; Mon, 23 May 2016 08:25:23 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5732912B030 for ; Mon, 23 May 2016 08:25:23 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id z87so7997230wmh.1 for ; Mon, 23 May 2016 08:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=JbN74ibk1wXdOWuNclEY1sKsUdRN/qXVnrUhYDfADeA=; b=PvHIi+AA1W6XECVy6E6/TpE+th2Cw8wwBtZHwdryksho9HRWygcHQ5ZdLJjOj1ovXs 0ZM/dRmEPnCKKKajjN7Ac++f4/x32sn8GjftygPUOWzkTai/tMIIh5ptmnpkw0tTiaGV mf5AnrBBHgm4Dw9LtZLjb07aGlPjioZp0liLrVZb/pWIszQ9yJ8D/3I3hfmFObn2pS6e df1DIS0oXi9SkQdNGE1eVTSMfKIB0XPpSG+5wSzEVNhniHoFvkCDHC+D8iIHm4lC88QX 4btKUJbJUY8VqW244l/HB/5WDlnP6ZCVYSiQc45TYxDPWvNaHHaB78fI0eC8sUCP4YnS 9zWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JbN74ibk1wXdOWuNclEY1sKsUdRN/qXVnrUhYDfADeA=; b=CXZCeFQDCQ1VsuWm/Tx3XQeksyXRJR1vrlIPIVKA0S3cXR+debGv9wJ0PcW7YpaDMK CGjL9s23Y4BeYo5pIz9f5hHlwn4OD/xESsWyWYPj1uSYglm9SDk7RewCwGGwNBP/ig14 ZNkxlvyhGClFAU0jYtBk+xQZl2vXf8X0Uk3mf0JQd2QgqP3CQ49IE6osVePKuVFriymS aiZTRBzDZMgthsYXH6S9SDlUUqwGqxRCbEmCOsClWuG1x6wzPjba6iK4Jgtd4b9zoej2 rJRN8rg6zUpNDJYvhKGDAbJUTrLhWOTd9R8w3NybFRdcUaBHFXRyLjm7bT8r+sl4Ohfe yRNQ== X-Gm-Message-State: ALyK8tJS+dsrtBd6qSz1GP5k7aX55FBRKZgfY+2CcdcO0Zgcmm6m/Lx+K9m8Od7T9ks3XAZppY9/GhW3Nh6OXg== X-Received: by 10.194.169.37 with SMTP id ab5mr5546553wjc.141.1464017121803; Mon, 23 May 2016 08:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.153.205 with HTTP; Mon, 23 May 2016 08:24:52 -0700 (PDT) From: Edwin Cordeiro Date: Mon, 23 May 2016 12:24:52 -0300 Message-ID: To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e012284c87d83320533840c1f Archived-At: Subject: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:25:25 -0000 --089e012284c87d83320533840c1f Content-Type: text/plain; charset=UTF-8 Hello all, Below is the first review from the Internet Draft Review Team that I'm mentoring. Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-00 Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro Review Date: May 23th 2016 Summary: It is a good suggestion for a BCP, but it needs to add DHCP-PD to it Comments: The draft proposes the use of an unique /64 for each user equipment connected to a WLAN gateway. The proposal highlights the benefit of such approach but fails to analyse possible consequences. I would support this draft to move forward if these issues are addressed. Major Issues: - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and later at the "Future Work" session. From my understanding DHCPv6-PD is capable of implementing the network as desired in this BCP. Considering the intended status is BCP, I think that DCHPv6-PD should be added as valid implementation alternative. - The draft doesn't mention possible issues of giving one /64 for each UE, for example, a public WIFI with support for 512 users will need a /55 instead of a single /64. Minor Issues and Nits: The document has some Nits problems as detailed in: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt Questions: - Should this document address the best way to logging the prefix assign to the UE/subscriber? - Assigning the same unique prefix if the UE/subscriber reconnect to the same AP, is something that should be considered or avoided? Best regards, Edwin Cordeiro --089e012284c87d83320533840c1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Hello all,

Below is the first re= view from the=C2=A0Internet Draft Review Team that I'm mentoring.

=

Reviewer= s:=C2=A0Ricardo Pelaez-Negro,=C2=A0Edwin Cordeiro

Review Date: May 23th 2016
=

=
Summa= ry: It is a good suggestion for a BCP, but it needs to add DHCP-PD to it
<= br>
Comments: The draft proposes the use of an unique /64 for each user eq= uipment connected to a WLAN gateway. The proposal highlights the benefit of= such approach but fails to analyse possible consequences. I would support = this draft to move forward if these issues are addressed.

Major Issu= es:=C2=A0
- The DHCPv6-PD is mentioned for the first time only in section = 4.3.1 and later at the "Future Work" session. From my understandi= ng DHCPv6-PD is capable of implementing the network as desired in this BCP.= Considering the intended status is BCP, I think that DCHPv6-PD should be a= dded as valid implementation alternative.
- The draft doesn't mention = possible issues of giving one /64 for each UE, for example, a public WIFI w= ith support for 512 users will need a /55 instead of a single /64.

M= inor Issues and Nits:=C2=A0
The document has some Nits problems as detaile= d in:=C2=A0https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-jj= mb-v6ops-unique-ipv6-prefix-per-host-00.txt

Questions:
- Should this document address the best way to logging the pref= ix assign to the UE/subscriber?
- Assigni= ng the same unique prefix if the UE/subscriber reconnect to the same AP, is= something that should be considered or avoided?

Best r= egards,

Edwin Cordeiro
--089e012284c87d83320533840c1f-- From nobody Mon May 23 09:40:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BA12DA1A for ; Mon, 23 May 2016 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoWsd1aTTKHU for ; Mon, 23 May 2016 09:40:08 -0700 (PDT) Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id C468412DA1F for ; Mon, 23 May 2016 09:40:07 -0700 (PDT) Received: (qmail 41032 messnum 20992151 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 23 May 2016 16:40:06 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mta05.svc.cra.dublin.eircom.net (qp 41032) with SMTP; 23 May 2016 16:40:06 -0000 Received: from [192.168.1.2] ([159.134.196.33]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id xsg51s00U0jionT01sg67w; Mon, 23 May 2016 17:40:06 +0100 X-CNFS-Analysis: v=2.1 cv=Xe90t9N5 c=1 sm=1 tr=0 a=Jfy3IYKxuyUpgs8iKr8Vjg==:117 a=Jfy3IYKxuyUpgs8iKr8Vjg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=TYfwxKbqJHIUADyyqXgA:9 a=C4mHJTMmS1eKByMm:21 a=9SNPrdfZHhWIYuVu:21 a=QEXdDO2ut3YA:10 a=VX4HAHguTWNB9qAMHpkA:9 a=QVrsRZ_-gYNy0cfn:21 a=nDRqsUY9n8sVGmOy:21 a=jD-i3_5Qi2bb-hgs:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 Content-Type: multipart/alternative; boundary="Apple-Mail=_80C06540-42AE-4A43-9F3B-DEB3EB247BF9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ross Chandler In-Reply-To: Date: Mon, 23 May 2016 17:40:11 +0100 Message-Id: References: To: Edwin Cordeiro X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:40:10 -0000 --Apple-Mail=_80C06540-42AE-4A43-9F3B-DEB3EB247BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 May 2016, at 16:24, Edwin Cordeiro wrote: >=20 > Major Issues:=20 > - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 = and later at the "Future Work" session. =46rom my understanding = DHCPv6-PD is capable of implementing the network as desired in this BCP. = Considering the intended status is BCP, I think that DCHPv6-PD should be = added as valid implementation alternative. > - The draft doesn=E2=80=99t mention possible issues of giving one /64 = for each UE, for example, a public WIFI with support for 512 users will = need a /55 instead of a single /64. Edwin, Some comments on those comments as we=E2=80=99re planning on deploying = WLAN-GWs that give out /64 per UE. /55 is probably unnecessarily parimonious and it isn=E2=80=99t on a = nibble boundary to make the address plan easy to understand.=20 I=E2=80=99d suggest a minimum of /48 for a pool giving out /64s. A = larger pool size will help avoid bringing the IPv4 pool exhaustion = problem seen in BNGs into an average WLAN-GW. =20 Regards Ross >=20 > Minor Issues and Nits:=20 > The document has some Nits problems as detailed in: = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-jjmb-v= 6ops-unique-ipv6-prefix-per-host-00.txt = >=20 > Questions: > - Should this document address the best way to logging the prefix = assign to the UE/subscriber? > - Assigning the same unique prefix if the UE/subscriber reconnect to = the same AP, is something that should be considered or avoided? >=20 > Best regards, >=20 > Edwin Cordeiro > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_80C06540-42AE-4A43-9F3B-DEB3EB247BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 May 2016, at 16:24, Edwin Cordeiro <edwinsc@gmail.com> = wrote:

Major Issues: 
- = The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and = later at the "Future Work" session. =46rom my understanding DHCPv6-PD is = capable of implementing the network as desired in this BCP. Considering = the intended status is BCP, I think that DCHPv6-PD should be added as = valid implementation alternative.
- = The draft doesn=E2=80=99t mention possible issues of giving one /64 for = each UE, for example, a public WIFI with support for 512 users will need = a /55 instead of a single = /64.

Edwin,

Some = comments on those comments as we=E2=80=99re planning on deploying = WLAN-GWs that give out /64 per UE.

/55 is = probably unnecessarily parimonious and it isn=E2=80=99t on a nibble = boundary to make the address plan easy to = understand. 
I=E2=80=99d suggest a minimum of /48 for a = pool giving out /64s. A larger pool size will help avoid bringing the = IPv4 pool exhaustion problem seen in BNGs into an average = WLAN-GW.
 
Regards
Ross




Minor Issues and Nits: 
The = document has some Nits problems as detailed in: https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/d= raft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

Questions:
- = Should this document address the best way to logging the prefix assign = to the UE/subscriber?
- Assigning the = same unique prefix if the UE/subscriber reconnect to the same AP, is = something that should be considered or avoided?

Best = regards,

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

= --Apple-Mail=_80C06540-42AE-4A43-9F3B-DEB3EB247BF9-- From nobody Mon May 23 10:35:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62E12D107 for ; Mon, 23 May 2016 10:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AYA_f7ZUlfG for ; Mon, 23 May 2016 10:35:20 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE3C12D11A for ; Mon, 23 May 2016 10:35:20 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id z87so57385458wmh.0 for ; Mon, 23 May 2016 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4G16BLwogo3c1IxluJiwDEOX3EBTrwfox8CRXwD57FQ=; b=MZiDTo/dP9HBtMUB3ej+i7p3WPoyjNXXgEmkg3BjkWtjumoYu0qklTJzvziY3BTA3M /rgU8+VQ9hX4loWcqDe96Oj1TVTQvzofkHB2ycpzCPkwUAHT/W7VfdrnTWZVRM6B4jp9 ekuex/qQYnmy5rUeIgd1Di5HZ+2qwDKM80/1u9sX0XJPvrzdj2JZXq4qey4/ML4R/t/K uzpy4gCx2aTiADb+9Ox4i/OtTGOcDuH6NdUIiehjcnFmQwzz1dNZHuLnz9VG5Gv9AzTB WviwVOUHM1tlBzmoH2CzEB7a7LQ+VyehpQz2GSWzu63AbT3ecCsfu9ROJ722ijEzFNgn h3jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4G16BLwogo3c1IxluJiwDEOX3EBTrwfox8CRXwD57FQ=; b=gFL0s3V3OneuDxDD9OpEUbm1WXOzjAYBmFqLcjp7rhMDuuY8kGVHfysjH7lGiyqso4 eX/+7KSooM5Hc0kZCcC0w4vN8cHAZjwoFhjnO694G3aIqkWDrqiT9x7+zw9QqgT36TJx TwCZGBqK8QFLs63oG4Un7ZVIejiAQUCQyiwWhbjLtugf19vISPEejZ20HyC9OzyLkpWC jwal5/7Ok8EF8JYJUmuqKZlsbZc8pcGE15ao65WlFEr07m9Ukm3jUVrFmupDik37Z7K9 Nyc3H40+1GIx6qFX2niZKCUucVSossExz8z06XOYG5qsZ3Vy7Hd1AJMk9sgZ84G5+x/N n7tQ== X-Gm-Message-State: AOPr4FWIQj7CH2uMmUQOqwpuY1whUO6EjmUJ8JOGI/zYq2DoseYvuInxcWaOilisvmB8wiRWEIWOv4ksGChj6A== X-Received: by 10.194.69.106 with SMTP id d10mr18019922wju.165.1464024918850; Mon, 23 May 2016 10:35:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.153.205 with HTTP; Mon, 23 May 2016 10:34:49 -0700 (PDT) In-Reply-To: References: From: Edwin Cordeiro Date: Mon, 23 May 2016 14:34:49 -0300 Message-ID: To: Ross Chandler Content-Type: multipart/alternative; boundary=047d7bfcf5a03b04b3053385dddd Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:35:23 -0000 --047d7bfcf5a03b04b3053385dddd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Our comment was that using a unique /64 per UE would considerably increase the amount of wasted addresses. It could be a problem in some deployments, but the document doesn't address this potential issue. I agree that using /48 makes planning easier, but this is also the standard size of an enterprise allocation, so a company with this standard allocation might have problems in following this recommendation. Edwin Cordeiro On Mon, May 23, 2016 at 1:40 PM, Ross Chandler wrote: > > On 23 May 2016, at 16:24, Edwin Cordeiro wrote: > > Major Issues: > - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and > later at the "Future Work" session. From my understanding DHCPv6-PD is > capable of implementing the network as desired in this BCP. Considering t= he > intended status is BCP, I think that DCHPv6-PD should be added as valid > implementation alternative. > - The draft doesn=E2=80=99t mention possible issues of giving one /64 for= each UE, > for example, a public WIFI with support for 512 users will need a /55 > instead of a single /64. > > > Edwin, > > Some comments on those comments as we=E2=80=99re planning on deploying WL= AN-GWs > that give out /64 per UE. > > /55 is probably unnecessarily parimonious and it isn=E2=80=99t on a nibbl= e > boundary to make the address plan easy to understand. > I=E2=80=99d suggest a minimum of /48 for a pool giving out /64s. A larger= pool > size will help avoid bringing the IPv4 pool exhaustion problem seen in BN= Gs > into an average WLAN-GW. > > Regards > Ross > > > > > Minor Issues and Nits: > The document has some Nits problems as detailed in: > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-jjmb-= v6ops-unique-ipv6-prefix-per-host-00.txt > > Questions: > - Should this document address the best way to logging the prefix assign > to the UE/subscriber? > - Assigning the same unique prefix if the UE/subscriber reconnect to the > same AP, is something that should be considered or avoided? > > Best regards, > > Edwin Cordeiro > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > --047d7bfcf5a03b04b3053385dddd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our comment was that using a unique /64 per UE = would considerably increase the amount of wasted addresses. It could be a p= roblem in some deployments, but the document doesn't address this poten= tial issue.=C2=A0

I agree that using /= 48 makes planning easier, but this is also the standard size of an enterpri= se allocation, so a company with this standard allocation might have proble= ms in following this recommendation.=C2=A0

Edwin Cordeiro
=

On Mon, May 23, 2016 at 1:40 PM, Ross Chandl= er <ross@eircom.net> wrote:
=

On 23 May 2016, at 16:24, Edwin Cordeiro <edwinsc@gmail.com> wrote:=

Major Issues:=C2=A0
= - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and l= ater at the "Future Work" session. From my understanding DHCPv6-P= D is capable of implementing the network as desired in this BCP. Considerin= g the intended status is BCP, I think that DCHPv6-PD should be added as val= id implementation alternative.
- The draft doesn=E2=80=99t mention possibl= e issues of giving one /64 for each UE, for example, a public WIFI with sup= port for 512 users will need a /55 instead of a single /64.

Edwin,
Some comments on those comments as we=E2=80=99re planning on de= ploying WLAN-GWs that give out /64 per UE.

/55 is proba= bly unnecessarily parimonious and it isn=E2=80=99t on a nibble boundary to = make the address plan easy to understand.=C2=A0
I=E2=80=99d sugge= st a minimum of /48 for a pool giving out /64s. A larger pool size will hel= p avoid bringing the IPv4 pool exhaustion problem seen in BNGs into an aver= age WLAN-GW.
=C2=A0
Regards
Ross




Minor Issues and Nits:=C2=A0
<= div class=3D"gmail_default">The document= has some Nits problems as detailed in:=C2=A0https://tools.ietf.org/idnits?url=3D= https://tools.ietf.org/id/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.t= xt

Questions:
- Should this document addres= s the best way to logging the prefix assign to the UE/subscriber?
- Assigning the same unique prefix if the UE/subsc= riber reconnect to the same AP, is something that should be considered or a= voided?

Best regards,

Edwin Cordei= ro
_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops


--047d7bfcf5a03b04b3053385dddd-- From nobody Mon May 23 10:48:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9E012DA26 for ; Mon, 23 May 2016 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.946 X-Spam-Level: X-Spam-Status: No, score=-115.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUdl9T62tcqz for ; Mon, 23 May 2016 10:48:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120F412D8D8 for ; Mon, 23 May 2016 10:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5043; q=dns/txt; s=iport; t=1464025696; x=1465235296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X15c6vRfpwGtGL1NuRA3vwVHHujdi7mX9HVQMGYgnMU=; b=A76H1rHkLPn/vdTjwwXKNwJ60eXjHAqHfot5YtnlmMeeIo5n7vJF9QAA jjNqH+AHQ4qzEaF1amdW2879+KIW37bMUs7AY/0MgY6lX/kYfFp9+MQB6 EMfR/Awylt1wsF5skeq3tGS13p2atc2chBd8eBREAyW3Pg2Q3teWNjT5z M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AgCxQUNX/4cNJK1cgzdWfQauDIZ2h?= =?us-ascii?q?HkOgXcihW8CgTM4FAEBAQEBAQFlJ4RCAQEBAwF5BQsCAQgEDgYuIREXDgIEDgU?= =?us-ascii?q?OiAcDDwgOwAkNhCYBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWIHYJXgkOFKIIuB?= =?us-ascii?q?ZgEMwGDKoFobYYngXmPHIdkh2cBHgFDggYcgUtuAQGIUH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,356,1459814400"; d="asc'?scan'208,217";a="276249187" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 17:48:15 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4NHmFKc009530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 17:48:15 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 12:48:14 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 23 May 2016 12:48:14 -0500 From: "Fred Baker (fred)" To: Edwin Cordeiro Thread-Topic: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRtRtHejGeUakNykKrAqaTiM4HfA== Date: Mon, 23 May 2016 17:48:14 +0000 Message-ID: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_815A6F50-0D3A-459B-A514-3F2797B90DAB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:48:17 -0000 --Apple-Mail=_815A6F50-0D3A-459B-A514-3F2797B90DAB Content-Type: multipart/alternative; boundary="Apple-Mail=_27F71ECB-03A3-401C-A901-62AD9E334429" --Apple-Mail=_27F71ECB-03A3-401C-A901-62AD9E334429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii First, thanks for your comments. > On May 23, 2016, at 10:34 AM, Edwin Cordeiro = wrote: >=20 > Our comment was that using a unique /64 per UE would considerably = increase the amount of wasted addresses. It could be a problem in some = deployments, but the document doesn't address this potential issue. However, it is consistent with SLAAC and general deployment scenarios. A = LAN, and in some cases a chassis, is assigned a /64. Yes, that creates a = vast number of potential IIDs. That is intentional in the addressing = architecture, and is viewed as a security feature. For example, although = we have decided to not continue recommending this, = https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC = address in the IID, and RFC 7217 essentially provides for a random = number that is difficult for an attacker to guess. My local ISP (which has not yet deployed IPv6, shame on them, but = expects to this year) tells me that they expect to deploy a /64, /60, or = /56 to a UE depending on what it asks for in DHCP-PD. I would expect = that is more common than not in residential broadband networks. --Apple-Mail=_27F71ECB-03A3-401C-A901-62AD9E334429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii First, thanks for your comments.

On = May 23, 2016, at 10:34 AM, Edwin Cordeiro <edwinsc@gmail.com> = wrote:

Our comment was = that using a unique /64 per UE would considerably increase the amount of = wasted addresses. It could be a problem in some deployments, but the = document doesn't address this potential = issue. 

However, it is consistent with SLAAC and general deployment = scenarios. A LAN, and in some cases a chassis, is assigned a /64. Yes, = that creates a vast number of potential IIDs. That is intentional in the = addressing architecture, and is viewed as a security feature. For = example, although we have decided to not continue recommending = this, https://tools.ietf.org/html/rfc4291#section-2.5.1 = includes the MAC address in the IID, and RFC 7217 essentially provides = for a random number that is difficult for an attacker to = guess.

My = local ISP (which has not yet deployed IPv6, shame on them, but expects = to this year) tells me that they expect to deploy a /64, /60, or /56 to = a UE depending on what it asks for in DHCP-PD. I would expect that is = more common than not in residential broadband = networks.
= --Apple-Mail=_27F71ECB-03A3-401C-A901-62AD9E334429-- --Apple-Mail=_815A6F50-0D3A-459B-A514-3F2797B90DAB 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----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV0NCXEayAOS/EQ8MAQKrLw//fzpTqSWf4NTJ6osGEt1uCiuhZHzq4lud adfbgBkGwiUXkerX/FdF71mCV50fLBiMM4rFm20avlgR4/U9+P1REBzLf5QGAcuV 28kHUoCZjirkI78m3EkdHZbtCGISapfm55wsogGamDw19mZ7wCn6RsAPqJk8XELA Hy6WNGDuMJYKiCGMYPiVye++2LtuduXeGkVJPzMw87In1ybVTZIQJs8AK7GB2ex9 wPAiXZlOCzXTkXAGkXREYUWV8pOLAlmJyqk38Ub1f1WeFko3xpLpSqbSR2A/gkjg 8+bbzPMS3RA+4QwkVANSrEJEJE1w62MkKumPy8vSV+tsxkirFu5+NMuTODsRSmq4 h14AGm65dWJpT9kXLofg7TEjQgIgVFuCzBYUD/P+OWGPPRPBG4/IWcEQTdSO9Wl6 Q7gjv4uxSkpulJb2too1ODMzY3RfNIpILhfi91oQx3DcWX9ZUQ5uepoHFUxOJAPi GfzUyWnm7JiSXbIZHn3SVjUxnT6T6foOjjtsEPOumI8pNPlPvWB6YShbjGxSgNHj /LmnBnNiX7YY6cj2LoTKUXiPKTj37L8IAFGiNB4wedQDTx2CmVo38pkewvMgGz50 7FvQTLZ40Q5HRnkky1WLAKfUFrek8Syajt4XRZzxMayLSGP0nnUGoU9I8/fVEtjT yu6KeiBecyc= =/3rs -----END PGP SIGNATURE----- --Apple-Mail=_815A6F50-0D3A-459B-A514-3F2797B90DAB-- From nobody Mon May 23 11:16:11 2016 Return-Path: <11beeasadiq@seecs.edu.pk> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9512DA35 for ; Mon, 23 May 2016 11:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seecs.edu.pk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJy-obzO7zmQ for ; Mon, 23 May 2016 11:16:07 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB70712D0DE for ; Mon, 23 May 2016 11:16:07 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id x189so178765535ywe.3 for ; Mon, 23 May 2016 11:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seecs.edu.pk; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aq5pC49m9oZIJRqbtAgCoYdjh4lErXQdmq/UhrhkkcU=; b=M7d++fH5Y6iRJ20JqkGQrdAi0C58dzNyvu9XlfUssnGTpN0hL7mLc9n/H9iCjppOxT nOOBXJiuk3n1ufbeNTX8j5pYeIFNix5gQz4aJZzK3JJsKOgug6DQKCRk9OQ6+cI+efMH IU+BWeMV1PIwAwolXbI1m/YKTsork6/+Y3utU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aq5pC49m9oZIJRqbtAgCoYdjh4lErXQdmq/UhrhkkcU=; b=MjX6urfjXaSMV0GQ31bbAM0kyvhjX/BhBG6a5BMPmRvA36waHNH2XBd3TENLYHtdrD jni/dSKG7BDBNaUlnuW5Izx70MYuX5gUf0impTJPQN0gkYuGD4Wpnt7D6kbIvrTqxILp AmGgqEnbtnYIR4Ofrvhajc7IJ0PUZezcp+8HNuFDrmmDbnwH9Uo4ErF8RFHXYuVMztDo vyf7Z9ZAHeoBz56WbE8FUgFg1vv/PInUGXUNjGEZNg/HI2gU8Y4MHBoPngs3/dpPrEFW 7cBrzA4X9tqBIGG+uPFUJda2CLccliXhiqvLYjTTYnEX1xckubCM/4Re01LF+5lkF6mp WFCA== X-Gm-Message-State: ALyK8tKHXNbTyPT2VFL/Ireia4P2Pjw9yBuuVKRMO8TUsvtApp+YiuNBu3qpY8qvioAgQCpGXgwfVOq5U8SlIdJq X-Received: by 10.37.230.87 with SMTP id d84mr104351ybh.63.1464027366852; Mon, 23 May 2016 11:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.56.2 with HTTP; Mon, 23 May 2016 11:15:47 -0700 (PDT) In-Reply-To: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> References: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> From: Adeel Sadiq <11beeasadiq@seecs.edu.pk> Date: Mon, 23 May 2016 23:15:47 +0500 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=94eb2c0b0e1024d75a0533866f4c Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 18:16:10 -0000 --94eb2c0b0e1024d75a0533866f4c Content-Type: text/plain; charset=UTF-8 Using a /55 does not make it easy at all to understand the address plan. So why not go for the best of both worlds. Like /56 instead of /64 or /48. Regards Adeel Sadiq On Mon, May 23, 2016 at 10:48 PM, Fred Baker (fred) wrote: > First, thanks for your comments. > > On May 23, 2016, at 10:34 AM, Edwin Cordeiro wrote: > > Our comment was that using a unique /64 per UE would considerably increase > the amount of wasted addresses. It could be a problem in some deployments, > but the document doesn't address this potential issue. > > > However, it is consistent with SLAAC and general deployment scenarios. A > LAN, and in some cases a chassis, is assigned a /64. Yes, that creates a > vast number of potential IIDs. That is intentional in the addressing > architecture, and is viewed as a security feature. For example, although we > have decided to not continue recommending this, > https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC > address in the IID, and RFC 7217 essentially provides for a random number > that is difficult for an attacker to guess. > > My local ISP (which has not yet deployed IPv6, shame on them, but expects > to this year) tells me that they expect to deploy a /64, /60, or /56 to a > UE depending on what it asks for in DHCP-PD. I would expect that is more > common than not in residential broadband networks. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --94eb2c0b0e1024d75a0533866f4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Using a /55 does not make it easy at all to understand the= address plan. So why not go for the best of both worlds. Like /56 instead = of /64 or /48.

Regards

Adeel Sa= diq

On= Mon, May 23, 2016 at 10:48 PM, Fred Baker (fred) <fred@cisco.com> wrote:
First, thanks for your comments.

On May 23, 2016, at 10:34 AM, Edwin Cordeiro <edwinsc@gmail.com> wrote:
=
Our comment was that using a unique /64 per UE would cons= iderably increase the amount of wasted addresses. It could be a problem in = some deployments, but the document doesn't address this potential issue= .=C2=A0

However, it is consistent wi= th SLAAC and general deployment scenarios. A LAN, and in some cases a chass= is, is assigned a /64. Yes, that creates a vast number of potential IIDs. T= hat is intentional in the addressing architecture, and is viewed as a secur= ity feature. For example, although we have decided to not continue recommen= ding this,=C2=A0https://tools.ietf.org/html/rfc4291#section-2.5.1 = includes the MAC address in the IID, and RFC 7217 essentially provides for = a random number that is difficult for an attacker to guess.

<= /div>
My local ISP (which has not yet deployed IPv6, shame on them, but= expects to this year) tells me that they expect to deploy a /64, /60, or /= 56 to a UE depending on what it asks for in DHCP-PD. I would expect that is= more common than not in residential broadband networks.
<= br>_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--94eb2c0b0e1024d75a0533866f4c-- From nobody Mon May 23 13:27:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA212DB29 for ; Mon, 23 May 2016 13:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akQrkzWfi-EN for ; Mon, 23 May 2016 13:27:13 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE3612DB70 for ; Mon, 23 May 2016 13:27:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 70C9D909 for ; Mon, 23 May 2016 20:27:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyVVHERfJm5z for ; Mon, 23 May 2016 15:27:12 -0500 (CDT) Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 2CEEF558 for ; Mon, 23 May 2016 15:27:12 -0500 (CDT) Received: by mail-wm0-f72.google.com with SMTP id a136so16763550wme.1 for ; Mon, 23 May 2016 13:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xMOZtVsSOQmp0JLTw2wB4yoDd3mwHej3vIcAcAtEJxg=; b=gknSHU41xTkB7G9iJpFBlmU3XQo3gp7RhHxDySsNeZfa7Tmt7b9sZ6xiAYGNor6vRx VwB5fIVVeb4Zf3blYEMXM7/xGyIsyhScxk6YWj+DCdPIhRkfFuUkYHuk5hvlOtef6eu+ e8EY2q+ibtPijy96weaAoakjBDsQLQOgdnsjo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xMOZtVsSOQmp0JLTw2wB4yoDd3mwHej3vIcAcAtEJxg=; b=Dl0Ll956tMuavqxM1+3+6ez3Pxuut1zlQufvFx+EB8T6YJmvPStrsT5teoGVTMag+i lEsHSzrIcjLWAMwv/BC1D7hWakmWG1V2p0z/BRkAdFs8YANWBYcu0MAJ7ufjAmaH4rDt dexLkwE8zKYHxoT82SfK/1WYNlu5BzyCLh5nXnSjRYTtrVyaE+YiB9oohQcVVHebnkgC 2FEaMM7/UsCq8FR5+jiT88CXKd+eqwyXnMVFpqJfRiO4Cac4RGaz+dBrANTVyFSq9ahp 2vyaO9q+j36auzk7XHbNRqkhnYiB2n+GuF4ITikZO4ofCi8ZF2wOLpNjONTtwWQxYWG1 4BJw== X-Gm-Message-State: AOPr4FVXJg4AG8vWeTejMNY1bXPhYRi1f0Z9zWg0gwsEobP0AOebsIsI9axuRVB7FFZmCI3No2QTnRm6QJN7btEb2Rb7FXuHBspg2OO7cgy/oM02U7Ycg9QSaEbH+uad4mg5UF/AvmZlR3ku3QPc X-Received: by 10.112.62.165 with SMTP id z5mr5744129lbr.89.1464035231111; Mon, 23 May 2016 13:27:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.62.165 with SMTP id z5mr5744126lbr.89.1464035230839; Mon, 23 May 2016 13:27:10 -0700 (PDT) Received: by 10.25.152.194 with HTTP; Mon, 23 May 2016 13:27:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2016 15:27:10 -0500 Message-ID: From: David Farmer To: Edwin Cordeiro Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:27:15 -0000 On Mon, May 23, 2016 at 10:24 AM, Edwin Cordeiro wrote: > Comments: The draft proposes the use of an unique /64 for each user > equipment connected to a WLAN gateway. The proposal highlights the benefit > of such approach but fails to analyse possible consequences. I would support > this draft to move forward if these issues are addressed. That is not the primary recommendation of this Draft. The primary recommendation of this Draft is simply to not limit the number of address provided to a host. Providing a unique /64 for each user is really just one of many ways that can be used to provide multiple addresses per users, it is only brought up as a solution to some potential issues. The Draft envision the primary way for this to be done is through the use of traditional SLAAC. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From nobody Mon May 23 17:56:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310212DBB7 for ; Mon, 23 May 2016 17:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdvFFo0TRnPw for ; Mon, 23 May 2016 17:56:16 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E507912DB53 for ; Mon, 23 May 2016 17:56:15 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c189so806489pfb.3 for ; Mon, 23 May 2016 17:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1Oh+s/NvwIobb1RWIql2rLk2Qw4mK8lnae+9NL7wEP0=; b=i5IGSzUntjuUcvN+7YCKsFwSWzdyxEw+za18CCwCso3RUAmMLBoizZn4ORwjv2AVLd UPImH7vJ4WCdH6BNZxR5qfeJ6lSHa18Svo2GW3kN+fekjHXW95hqha4AdxsD7cyj1KV7 XZHws+63dD3xQxYfU3YEtZu7/3vMt940Zg4elSP5Q4UPMz1A1myJEeLqlFtK1O+SlOMH h5GKAUEf0+rYiPEQXb2ilMha67b3rqTdth/EGEn7ziHRQ+LYiDa8Bk6gBzMWtJBgTah7 uQjC1CRpjQ555eCKbXnnVpTMkB+HKw+kSRyJOmFPhGYoPb5LCtHyDPkeQBSEBYi/1LdI xaCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1Oh+s/NvwIobb1RWIql2rLk2Qw4mK8lnae+9NL7wEP0=; b=AroTECV2Wk/YjyrEEq6EWjG9PysyEasyNE5usZQ2r4/vYHhx2gZFVmOyl7jXvzggGA 34dMHEAANITVYg2ZZk1IxmMHXUa1Pf9UNPRcpfLOOfjOLGtQWtYrBRWvhMXcHsIbmy2+ FN2758olP+bMq4ZtBHkLdgq9to/uaEl1Rtr2SCPaqig6of6HJHCXbMSMidO+a4lXzxBs 5OkLAnpafpa82/BRDJglOxAbVR41siINp8fbuJ/c4vnQTTZmyGx3YOMGc61HLXUpHaP6 4A92pCuL+T4/Yzh8n+yz9Sbg16+bfmRuhs6XePLI9/oIbU7PnlZm6RuG7nG02xWANIr+ FqEw== X-Gm-Message-State: ALyK8tJ9OeJWdHS7vV29VP4lBCJJiSuVkAIVay+IwQY2DvF+d6SwET0SghorWOEZzXFM/g== X-Received: by 10.98.22.141 with SMTP id 135mr2504778pfw.116.1464051375491; Mon, 23 May 2016 17:56:15 -0700 (PDT) Received: from ?IPv6:2406:e007:5038:1:f5ae:d4d3:96f9:5820? ([2406:e007:5038:1:f5ae:d4d3:96f9:5820]) by smtp.gmail.com with ESMTPSA id z63sm49378116pfb.47.2016.05.23.17.56.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 17:56:14 -0700 (PDT) To: "Fred Baker (fred)" , Edwin Cordeiro References: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1e7570f2-6d4c-e78d-4140-ae937f30391f@gmail.com> Date: Tue, 24 May 2016 12:56:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 00:56:17 -0000 On 24/05/2016 05:48, Fred Baker (fred) wrote: > First, thanks for your comments. > >> On May 23, 2016, at 10:34 AM, Edwin Cordeiro wrote: >> >> Our comment was that using a unique /64 per UE would considerably increase the amount of wasted addresses. It could be a problem in some deployments, but the document doesn't address this potential issue. > > However, it is consistent with SLAAC and general deployment scenarios. A LAN, and in some cases a chassis, is assigned a /64. Yes, that creates a vast number of potential IIDs. That is intentional in the addressing architecture, and is viewed as a security feature. For example, although we have decided to not continue recommending this, https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC address in the IID, and RFC 7217 essentially provides for a random number that is difficult for an attacker to guess. > > My local ISP (which has not yet deployed IPv6, shame on them, but expects to this year) tells me that they expect to deploy a /64, /60, or /56 to a UE depending on what it asks for in DHCP-PD. I would expect that is more common than not in residential broadband networks. Whereas my ISP gives me a /48, having noticed that IPv6 prefixes are not scarce. Also, they give me a different /48 each time I reboot the UE, which is good for privacy. BTW what is the WG status of this draft? It hasn't been updated for a while and is technically expired. Brian From nobody Mon May 23 18:01:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F212D539 for ; Mon, 23 May 2016 18:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h03TnsbbzMfL for ; Mon, 23 May 2016 18:01:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4BD12D140 for ; Mon, 23 May 2016 18:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1724; q=dns/txt; s=iport; t=1464051675; x=1465261275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/84OKq1ctTUS8ofKUMJQmScz4xUudB91Q0jeN40X4Ok=; b=WqJ0fCnZV5vQ4uot4Ue1frF/Xw07imXAR6amARNQ/IZ48pMNV7iP8tba Y7U/6ffU+Casn1idEtPkcS3nV5AKWTeixxQYb/hEuQ5MggBDLETvVgCY4 co0LtknNMxUTzaEWd76oXMf6RkHW7pwqq2d36l5Mqx+fykt6+DwQ1o1Oo I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AwC3pkNX/49dJa1cgzeBUwauD4tvD?= =?us-ascii?q?oF2hhECgTc4FAEBAQEBAQFlJ4RCAQEBAwF5BQsCAQgYLiERJQIEDgUOiAcDDwi?= =?us-ascii?q?/Tw2EJgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OiB0Igk+CQ4Uogi4FiACHF4htM?= =?us-ascii?q?wGDKoFohxSBeYFTAY1Ih2SHZwEeAUODbW4BiFF/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,358,1459814400"; d="asc'?scan'208";a="111046723" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 01:01:13 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4O11Daf027030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2016 01:01:13 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 20:01:12 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 23 May 2016 20:01:13 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRtRtHejGeUakNykKrAqaTiM4HfA== Date: Tue, 24 May 2016 01:01:13 +0000 Message-ID: <6751792B-4271-4A8C-A33B-E7781D0E01E3@cisco.com> References: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> <1e7570f2-6d4c-e78d-4140-ae937f30391f@gmail.com> In-Reply-To: <1e7570f2-6d4c-e78d-4140-ae937f30391f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_F976D1C4-CFAB-403B-BA1C-FDCE7780FB6A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 01:01:16 -0000 --Apple-Mail=_F976D1C4-CFAB-403B-BA1C-FDCE7780FB6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 23, 2016, at 5:56 PM, Brian E Carpenter = wrote: >=20 > what is the WG status of this draft? It hasn't been updated for a = while > and is technically expired. The author tells me that there is Comcast-specific content and more = general content in the draft as posted. He plans to divide the draft = into two parts, posting both before IETF 96. --Apple-Mail=_F976D1C4-CFAB-403B-BA1C-FDCE7780FB6A 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----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV0On2EayAOS/EQ8MAQL7WQ//Z/askjSqIdoK5GLVcY/ywU2R3xAllzPW 9BV937syzoC1uDBGHUzgTwQn6kQpmmdbykHBBS8fQVe/nGki4K7MH9pKWpHA1Vtp 7pZSzdiWjSqbJxFwuEnAv/NoGumxZHXEny4qISRJ50KY6SRJirHUdEVHyIBZ/ZvR hWTR812F5By5CB4KNBgLGSgVYr3jOpbSt+xPXPE23gEKPbBszASsez1sSUbutM3m RrO9ck7E97JNmNFrvPIkAfQvljE+U0sYn9pzRsiw5lFJf5iL9Yu1clYiAOj1Zhsn /fjZ9GQOJnOnwKJWhYEuWAIrQSx0J02qPd6Tfi1G/obzZFi9Po4+9517E++JwnE/ IxJ3X3e+IOlBqDSyTBFypJXm/QSg3yTXQlCAOm6KbpOqqKQSpaspAhrmqGH1aFi0 2Ss6l/DgThOWaKsvbo8YgvUQM5PbGeDzSOqV8t0xmjp00ko2B3Y7z8keyL+gKetQ 0CGuN/5dvz4jWmlMRBG1fs3vdSVozvGCJt590wXvKsbx8+HnpBoECgZnt6iedXt2 EUenJ4tWy6ZSVYq7e+oGjaE3gO6ev4M8Qxuo8ikY+0QMH/wqXfjCVME5ZYQx8SQK kXol/AXK4JM86c16f5OIQ5i+B6ljF2CkCNzdZR6Czi0eFlHgKEvLn8fNNt+wDOHa k2NLpQO2oLc= =eqVf -----END PGP SIGNATURE----- --Apple-Mail=_F976D1C4-CFAB-403B-BA1C-FDCE7780FB6A-- From nobody Wed May 25 05:44:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072CC12D115 for ; Wed, 25 May 2016 05:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT7nMgjpG28o for ; Wed, 25 May 2016 05:44:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995A912D106 for ; Wed, 25 May 2016 05:44:50 -0700 (PDT) Received: from mb-2.local (host210-131-static.6-79-b.business.telecomitalia.it [79.6.131.210]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u4PCii8c046855 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 25 May 2016 12:44:46 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host host210-131-static.6-79-b.business.telecomitalia.it [79.6.131.210] claimed to be mb-2.local To: "Fred Baker (fred)" , Edwin Cordeiro References: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> From: joel jaeggli Message-ID: Date: Wed, 25 May 2016 14:44:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1 MIME-Version: 1.0 In-Reply-To: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2muq1R4GoRaCarWtgWOMQVU8leAK7JaxE" Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 12:44:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2muq1R4GoRaCarWtgWOMQVU8leAK7JaxE Content-Type: multipart/mixed; boundary="p7eVAGagkCTBcROUC4bcTPFnBP131Bnjv" From: joel jaeggli To: "Fred Baker (fred)" , Edwin Cordeiro Cc: IPv6 Ops WG Message-ID: Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host References: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> In-Reply-To: <71729B39-E545-44A7-AF25-62F16661703D@cisco.com> --p7eVAGagkCTBcROUC4bcTPFnBP131Bnjv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/23/16 7:48 PM, Fred Baker (fred) wrote: > First, thanks for your comments. >=20 >> On May 23, 2016, at 10:34 AM, Edwin Cordeiro > > wrote: >> >> Our comment was that using a unique /64 per UE would considerably >> increase the amount of wasted addresses. It could be a problem in some= >> deployments, but the document doesn't address this potential issue.=20 what's the difference between a router which required a prefix >=3D 64 when doing PD and a UE doing it. Do we know a priori if a device doing so is doing so in it's capacity as a host our a router. > However, it is consistent with SLAAC and general deployment scenarios. = A > LAN, and in some cases a chassis, is assigned a /64. a device could practicaly decide to answer for all them save for the router which will likely defend it's own via dad. appart from the vast number of nd entries that might create it is superficially similar to delegating the /64 (save for it being a connected rather than nexthop pinned rute). > Yes, that creates a > vast number of potential IIDs. That is intentional in the addressing > architecture, and is viewed as a security feature. For example, althoug= h > we have decided to not continue recommending > this, https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MA= C > address in the IID, and RFC 7217 essentially provides for a random > number that is difficult for an attacker to guess. >=20 > My local ISP (which has not yet deployed IPv6, shame on them, but > expects to this year) tells me that they expect to deploy a /64, /60, o= r > /56 to a UE depending on what it asks for in DHCP-PD. I would expect > that is more common than not in residential broadband networks. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --p7eVAGagkCTBcROUC4bcTPFnBP131Bnjv-- --2muq1R4GoRaCarWtgWOMQVU8leAK7JaxE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldFnjQACgkQ8AA1q7Z/VrIMZwCaAnXLIoEglLcudxSIwU6EgZlY 7iYAoIN7UYDIj1jnI/HlpX/T29jJKomm =qNUC -----END PGP SIGNATURE----- --2muq1R4GoRaCarWtgWOMQVU8leAK7JaxE-- From nobody Wed May 25 08:16:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0312DBD0 for ; Wed, 25 May 2016 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8McZRLWGui7 for ; Wed, 25 May 2016 08:16:19 -0700 (PDT) Received: from smtpauth1.wiscmail.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EED12B055 for ; Wed, 25 May 2016 08:14:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) id <0O7Q00H00NHCZP00@smtpauth1.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 25 May 2016 10:14:27 -0500 (CDT) X-Spam-PmxInfo: Server=avs-1, Version=6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.25.150316, SenderIP=0.0.0.0 Received: from DOIT-2NW1MRFY-X.doit.wisc.edu (brie.doit.wisc.edu [144.92.67.198]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0O7Q00AVCNO18J00@smtpauth1.wiscmail.wisc.edu>; Wed, 25 May 2016 10:14:26 -0500 (CDT) Date: Wed, 25 May 2016 10:14:33 -0500 From: "Dale W. Carder" To: Edwin Cordeiro Message-id: <20160525151433.GA11811@DOIT-2NW1MRFY-X.doit.wisc.edu> References: In-reply-to: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Review: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:16:21 -0000 Hi Edwin, I appreciate your review, especially the summary you provided. Thus spake Edwin Cordeiro (edwinsc@gmail.com) on Mon, May 23, 2016 at 02:34:49PM -0300: > Our comment was that using a unique /64 per UE would considerably increase > the amount of wasted addresses. Well, for just one of our sites we would probably need a /44, so might as well go with /40 to stay comfortable. At our other sites, /48 would work well. But we have a /28 plus a handful of /32's, so really this isn't a concern at all now. > It could be a problem in some deployments, but the document doesn't address this potential issue. Those deployments probably should go back to their RIR or upstream provider based on an updated deployment plan. Now is the time! > > On 23 May 2016, at 16:24, Edwin Cordeiro wrote: > > > > Major Issues: > > - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and > > later at the "Future Work" session. From my understanding DHCPv6-PD is > > capable of implementing the network as desired in this BCP. Considering the > > intended status is BCP, I think that DCHPv6-PD should be added as valid > > implementation alternative. My thought is that there does not exist enough experience (for now) with PD in this role to be comfortable for calling it a BCP. But, as both you and the current document point out it is a logical next step. Dale From nobody Wed May 25 21:02:48 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7147012D0B6; Wed, 25 May 2016 21:02:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526040247.2907.93657.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 21:02:47 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:02:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Host address availability recommendations Authors : Lorenzo Colitti Vint Cerf Stuart Cheshire David Schinazi Filename : draft-ietf-v6ops-host-addr-availability-07.txt Pages : 14 Date : 2016-05-25 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 25 21:03:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B9012D0B6 for ; Wed, 25 May 2016 21:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfcLqmkfxjEt for ; Wed, 25 May 2016 21:03:47 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB0712D589 for ; Wed, 25 May 2016 21:03:47 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x189so65814828ywe.3 for ; Wed, 25 May 2016 21:03:47 -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; bh=QukRk500Jx5dJlSkx53lr0+ptAgf8TC1LwTQln/6Rg4=; b=oLn8hAeyBOVqiQDuL93dsGEN9FcmN0u9z3gfCnOidTMHbOd5o7e0SIDsUJym59vxE3 kQRDibxBKXcl/O5v7gmJ94cMvug8lSgbJ+fykyfooGlTez1mrcCc3wfq63DxrnDsYbhW OgWTOsNIwHr84+4Z/vUFA61ggWbwUK26XFyewJvkCPsDsHbU/9FMNn6EqpATETMWUyyM 8k+Vx1mW3iuUpiMIfj320l91z0GpsUw/dMCPPjHoXjTMA/G1SqCfb7YDFuBNmr94Jm2i d2SfT6gAbWnq6sKydMcb4tMtk9Kzsgam5MV2iG57a27jFQ5dqAXtHHalO/mcz3y/nhFM TeMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QukRk500Jx5dJlSkx53lr0+ptAgf8TC1LwTQln/6Rg4=; b=SsgHOX3sh3b8w1d0DxWpd5aPQ1Wan7bIHYsnDd6z2VrSAXBrlrkPfojodKTaqFtKX3 iUZXjj6iLaK9QXA/oyYGW8C6nnvHWSaJ5xuE8AfrjiZxEsKg//ADK8n/TJCSTCM1UcVW 82ebCD6atKPu4/czPlAT1y1IvkDzYejo19rJWvAATJ3SF6LN22EN9CXlouCbwFQVabI8 qdkAo62LLJOoJLR2ZYOUfSG4trognwdh7zaq4uoB6ST5UWrzZhXdRy1rCW4lPzC5IFhs l8/lzkF7FGOrcn1FoIEundEOpwQ7HF9cqG6cVajKOs6NEIOzQ3e3QGmo+fEz7yGMWUMO Ibnw== X-Gm-Message-State: ALyK8tJTfxVt4gidpNFtzRH+AM63F2KUwhvb3T77ZkjJQMly48kZnsCsmLBNW6vENqOuHN+n6Q3EEF+oyyqOjMIl X-Received: by 10.129.166.214 with SMTP id d205mr4451137ywh.323.1464235426288; Wed, 25 May 2016 21:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.68 with HTTP; Wed, 25 May 2016 21:03:26 -0700 (PDT) In-Reply-To: <20160503162731.8335.21186.idtracker@ietfa.amsl.com> References: <20160503162731.8335.21186.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 26 May 2016 13:03:26 +0900 Message-ID: To: Alissa Cooper Content-Type: multipart/alternative; boundary=94eb2c128e5474088b0533b6e0d7 Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Alissa Cooper's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:03:49 -0000 --94eb2c128e5474088b0533b6e0d7 Content-Type: text/plain; charset=UTF-8 Alissa, thanks for the comments. We've made changes in -07 to address them. On Wed, May 4, 2016 at 1:27 AM, Alissa Cooper wrote: > Section 3: s/which is only available in 3GPP release 10/which has been > made available as of 3GPP release 10/ > Changed to "3GPP release 10 or above". > Section 9.1: > - May be better not to presume that operators do things "to avoid > liability" - I don't think that particular sentence is necessary here. > Er, oops. Changed to "attribute liability", which is what we meant. - I was surprised not to see a note here about interaction between this > kind of host tracking and MAC address randomization, which I assume makes > tracking harder independently of the whether the recommendations in this > document are followed. But is it not discussed because operators who feel > they need these kind of logs also prohibit MAC randomization? > Agreed. Added a mention of MAC address randomization just after "ongoing efforts to improve the privacy of DHCPv6 (RFC7844)". That's the most obvious place, since MAC address randomization is discussed in depth in RFC 7844. Cheers, Lorenzo --94eb2c128e5474088b0533b6e0d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alis= sa,

th= anks for the comments. We've made changes in -07 to address them.
=

On Wed, May= 4, 2016 at 1:27 AM, Alissa Cooper <alissa@cooperw.in> wrote= :
Section 3: s/which is only available in 3GPP release = 10/which has been
made available as of 3GPP release 10/

C= hanged to "3GPP release 10 or above".
=C2=A0
Section 9.1:
- May be better not to presume that operators do things "to avoid
liability" - I don't think that particular sentence is necessary h= ere.

Er, oops. Changed to "attribu= te liability", which is what we meant.

- I was surprised not to see a note here about interaction between this
kind of host tracking and MAC address randomization, which I assume makes tracking harder independently of the whether the recommendations in this document are followed. But is it not discussed because operators who feel they need these kind of logs also prohibit MAC randomization?

Agreed. Added a mention of MAC address randomization= just after "ongoing efforts to improve the privacy of DHCPv6 (RFC7844= )". That's the most obvious place, since MAC address randomization= is discussed in depth in RFC 7844.

Cheers,
<= div>Lorenzo
--94eb2c128e5474088b0533b6e0d7-- From nobody Wed May 25 21:04:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EFD12D5E5 for ; Wed, 25 May 2016 21:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjPs7U8meKv0 for ; Wed, 25 May 2016 21:04:38 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A521212D5F5 for ; Wed, 25 May 2016 21:04:28 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x189so65825615ywe.3 for ; Wed, 25 May 2016 21:04:28 -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; bh=go28tcIGtlHXS+G/jZnCQgSm1YkbKmuN0MMQsSGauBo=; b=GlqhXfHILyTdDa0Q8GhUnI8r9nY2DVSN03FE78yrJUqMlhoSQysDN+ZpBbevGOQBQo 2ObJwqXMeENmNiacs4kU6RUPbizLCsaiMCldWds3IaP0oAgUQaJLqqKHyWfW9AlayNSo AfBdzZBVX5xAw5CuL0Y+BDk7jFLpI0r50qGNJZ0i63MAF0HEuuOvXKUBGpQzlHFTE2Ry wrAx7yEB1WBtitlNkVGALuEZf9QHKr4t7P/ulGhX8X8a8E0FGgo43DR9/eWJL108nEAv /kZ/bE/guD4r6emILed2SsMcZQfE4xEnHnQL2J0KxU5m/1mdlk/Cd8BuqS9EtsC5yHcr 0MPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=go28tcIGtlHXS+G/jZnCQgSm1YkbKmuN0MMQsSGauBo=; b=atcczetWWG8NugvlX7c9Q6RqpVH6c9wqgYDOgMkwV989SHPN+GBQ+v36nya2H6BRJF 9/0cc0HZkNUOvqfORhsJKQ0vhS8pelj5LmW9+XVK0RMX3XJSGF1iLCX24BKv1vDNg0kN ZXPMc0IZ5PIjvyoCzGPNW2tvtSxOjlmYG3F+r1QmAQq58wpJaxPklYgtc21oo89X/CGs PItCRVtOuuIijY0oNs0IWHc7t3W055okHQ/Mqe0oSXjwVEoH6SrieqsFPzJXzyONyBc4 MQ9q6JbQCRVEjUrWNVmDldb7wIeXOjyOhcxhvVErQC01jjJGDdQ0e9YJ7rZmueBwHGE8 b5Pw== X-Gm-Message-State: ALyK8tLuJYXtstuQUGxgVWp/0uyob1YJwoq6c02h2QQOuPKBv9t2PQlEdKpaWzdb6SVvmafH5DVxyrbFIoLcSxzc X-Received: by 10.37.13.214 with SMTP id 205mr4446786ybn.44.1464235467650; Wed, 25 May 2016 21:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.68 with HTTP; Wed, 25 May 2016 21:04:08 -0700 (PDT) In-Reply-To: <20160504031415.8354.72069.idtracker@ietfa.amsl.com> References: <20160504031415.8354.72069.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 26 May 2016 13:04:08 +0900 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a11c07972eb63e40533b6e2a8 Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:04:39 -0000 --001a11c07972eb63e40533b6e2a8 Content-Type: text/plain; charset=UTF-8 Suresh, thanks for the comments. We've addressed them in -07. On Wed, May 4, 2016 at 12:14 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > * What is the term ePDG being used here? Can you please add a reference? > The well known term in mobile networks is Evolved Packet Data Gateway > that is used for IPsec tunnel termination. That does not seem to make > sense here. > Good catch. Clarified to: particularly for technologies like I-WLAN [TS.24327] where the two processors share the Wi-Fi network connection. Better? * Maybe worth adding a reference to RFC7278 (64share) here as an example > for "Extending the network (e.g., "tethering")." > We do cite RFC7278 elsewhere. Not sure a reference is needed here, since it's not the only way of doing tethering. > s/which is only available in 3GPP release 10/which is only available in > 3GPP release 10 onwards/ > Done. > It is not clear what this bullet means. Can you clarify? > > " o Uncertainty, because it is not known in advance if a particular > operation function will be available." > Clarified to "Uncertainty, because it is not known if a particular operation function will be available until the provisioning operation succeeds or fails." Regards, Lorenzo --001a11c07972eb63e40533b6e2a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure= sh,

th= anks for the comments. We've addressed them in -07.

On Wed, May 4, 2016 at 12= :14 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
* What is the term ePDG being used here? C= an you please add a reference?
The well known term in mobile networks is Evolved Packet Data Gateway
that is used for IPsec tunnel termination. That does not seem to make
sense here.

Good catch. Clarified to:

=C2=A0 =C2=A0 =C2=A0 particularly for
=C2= =A0 =C2=A0 =C2=A0 technologies like I-WLAN [TS.24327] where the two process= ors share
=C2=A0 =C2=A0 =C2=A0 the Wi-Fi network connection.

Better?

* Maybe w= orth adding a reference to RFC7278 (64share) here as an example
for "Extending the network (e.g., "tethering")."

We do cite RFC7278 elsewhere. Not sure a refe= rence is needed here, since it's not the only way of doing tethering.
=C2=A0
s/which is only available in 3GPP release 10/which is only available in
3GPP release 10 onwards/

Done.
=C2=A0
It is not clear what this bullet means. Can = you clarify?

"=C2=A0 o=C2=A0 Uncertainty, because it is not known in advance if a p= articular
=C2=A0 =C2=A0 =C2=A0 operation function will be available."

Clarified to "Uncertainty, because it is not= known if a particular operation function will be available until the provi= sioning operation succeeds or fails."

Regards= ,
Lorenzo
--001a11c07972eb63e40533b6e2a8-- From nobody Wed May 25 21:05:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4180B12D093 for ; Wed, 25 May 2016 21:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAd3pS1OzQ11 for ; Wed, 25 May 2016 21:05:30 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F3712D583 for ; Wed, 25 May 2016 21:05:22 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id h19so66075107ywc.0 for ; Wed, 25 May 2016 21:05:22 -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; bh=wr5QyKvOYV7Z29lxsjt281dDrlQJ0TkCOLoQG5BN2rI=; b=hFJXRiKsZW8RyxN12Cna1mF5eN6MuCemL4Ftd5xNWNxQQYRt1Jm8NYWMGi3pXRwqMh 5TYi7++ocSBFw7nxAkSawGpfFoPv28cSCltIQ84ySxGbLIK3GUqhQypgXvt1dBBhTX4M 9mqdYFapeomfLYiCwUXuJ35G5+r7/k6CUflANPuo739UNM8P1YPgQWKYLjL50pf6EJ7i 4/PKh+DjcdEUdgkgXqpKvCDhCO8bjDL8nz6iR9JoTuoaISc2aaVl1td6ef+IdJHLX86U liCLoACgGG5HMeQavqxQCutus20Kt3vqoumj+xUyYAS1Dim1OaaQyRypGwX3KakBpr7b 3pTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wr5QyKvOYV7Z29lxsjt281dDrlQJ0TkCOLoQG5BN2rI=; b=dzJBBWAmITPuNsXtgeoOzUjfR2gevjWV6+hEQAzVDfZvUZjxzK2a5neTUt761f0IBO fuRNn9qTKG0yvRwD1gfx49CRn8zLL+CVzqK6zuST5337cSLFPDcOhMSraCb8aFcIOMF/ tdCpviQ5H0A9N1GJ7KNIM/KWyGlj6a5CINLQj3+rDc113Y5lgO2ywoa7QoScK3XH/5ND weHKHUvSai6SJMoaLNa7wcjlAIn3BBEwmHFsL2WwX6luGPOtgJUdMdl2o0tqOaDrlrlI ze5oQr1NxCsQXm4LO9uRZnAAd4ezjfDZFrCYp+3Qc/BWr4j6qbj3CwT+ZCw5A6Nn6G+2 AssQ== X-Gm-Message-State: ALyK8tIxVt5SmQxzUPLpakyOyyKP9dCtTL58s25pGwNwc7b+o0g0uO8csZ8fujo8k85AmKWQjVAe5Wk6yP7q0Jj6 X-Received: by 10.37.193.4 with SMTP id r4mr4195476ybf.185.1464235521872; Wed, 25 May 2016 21:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.68 with HTTP; Wed, 25 May 2016 21:05:02 -0700 (PDT) In-Reply-To: <20160503222244.8246.28466.idtracker@ietfa.amsl.com> References: <20160503222244.8246.28466.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 26 May 2016 13:05:02 +0900 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c05529c269dc10533b6e60f Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Ben Campbell's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:05:32 -0000 --94eb2c05529c269dc10533b6e60f Content-Type: text/plain; charset=UTF-8 Ben, we've addressed the comments in -07. On Wed, May 4, 2016 at 7:22 AM, Ben Campbell wrote: > Section 7: I _think_ the point of this section is to suggest that we > cannot reasonably estimate an upper limit. But if it says that > explicitly, I missed it. (I fear a careless reader will walk away > thinking "20" is a good limit) > We've attempted to to address this by adding the following sentence at the end of the section: Thus, in general is is not possible to estimate in advance how many addresses are required. Better? Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to > impose a hard limit/ > Updated. Regards, Lorenzo --94eb2c05529c269dc10533b6e60f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,=

we= 9;ve addressed the comments in -07.

On Wed, May 4, 2016 at 7:22 AM, Ben Campbell = <= ben@nostrum.com> wrote:
Section 7: I _thi= nk_ the point of this section is to suggest that we
cannot reasonably estimate an upper limit. But if it says that
explicitly, I missed it. (I fear a careless reader will walk away
thinking "20" is a good limit)

We've attempted to to address this by adding the following sentence a= t the end of the section:

=C2=A0 =C2=A0Thus, = in general is is not possible to estimate in advance
=C2=A0 =C2= =A0how many addresses are required.

Better?<= br>

Section 8: s/RECOMMENDED to not im= pose a hard limit/NOT RECOMMENDED to
impose a hard limit/

Updated.=C2=A0

Regards,
Lorenzo
--94eb2c05529c269dc10533b6e60f-- From nobody Wed May 25 21:06:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA212D5A6 for ; Wed, 25 May 2016 21:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q74QYQtmCsxb for ; Wed, 25 May 2016 21:06:46 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6961412D161 for ; Wed, 25 May 2016 21:06:46 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id o16so65955668ywd.2 for ; Wed, 25 May 2016 21:06:46 -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; bh=GccMEiq0cnuSUlUG5LyTW+FfhFuIPKFb0PE1ya6tyag=; b=P/UbnJzgcKAZfqHGQ2Pf2VpMrIAG4cQ5Hc4vAwM9/+1feg9CoQ9b1h81xhigqNHume gsLGKnNJ+VNlU7Z9l+giZ+RX/TGqPYH+Yz+VnONp/9Wxaqw5g5+s4vECUawCvfVyQJ87 qUcRegXOBtCK7XEHUG5YDy+GGdU+GCNq/CYKojkJLxBg7EDsIK04Ywx196rO4kCRmwQE XLHlZ+8KUS5RHRgfCjxwZFVdjZlE9LNN1WiBLY74vlzeDh0ep95Z8b1iQzqFZUnTLWH4 sQrfKKhspLhYiQqbDKwcLlU43oxTvwZ9HaG+aOrowZi0exHW9GKNj11VOoXqo0gE2G+X SKng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GccMEiq0cnuSUlUG5LyTW+FfhFuIPKFb0PE1ya6tyag=; b=fHiX0BN65uRemT4JLYGimeGvzAUxdgLpfRiKoW3Rgx9V+JMELi4QOJA1Jryb5Aa26j Gp9dGBmqzFA2rJhuAymFEhroygm/w16aG1+sBWmpZuEneya6pSJo9yP5Qg6HIZTKcImo OFy7dNhhfvgcIqGKD3cGmTn6Ev/COKRGB1ZWfCN4IJAY+oQGlb4gCL6KpWCE2ky7U+vv oXsEfyBlHpGFXV7SDjm4mhwbP02m8tLsPOuIM2t4//+iZddikJMvXZrQWYjS64jCk7Wj 5qnttmKcXK/SX778Vn040IiuOUVVih5GkQD1C9ynAoZ5VUsFYdkypdjGsJeC3mruX6hR YZvQ== X-Gm-Message-State: ALyK8tI06PMgRYHTgYI+rw5NhpXW6fJaBOabeaZr3PGVzoxsTxQ3/WQvVgtEncOtyufRDpKvh0bte8jhr/kx7O0o X-Received: by 10.13.220.69 with SMTP id f66mr5093571ywe.132.1464235605563; Wed, 25 May 2016 21:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.68 with HTTP; Wed, 25 May 2016 21:06:26 -0700 (PDT) In-Reply-To: <20160504082512.8358.20806.idtracker@ietfa.amsl.com> References: <20160504082512.8358.20806.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 26 May 2016 13:06:26 +0900 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c0815c823c5fd0533b6eb9e Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:06:49 -0000 --94eb2c0815c823c5fd0533b6eb9e Content-Type: text/plain; charset=UTF-8 On Wed, May 4, 2016 at 5:25 PM, Stephen Farrell wrote: > - I think you're missing one other reason why people > allocate /128's - in a hosting/VPS environment, the hoster > might want to avoid VPS's that originate spam using many > different source addresses over time so as to attempt to > avoid IP address based (bad) reputation accruing to their > outbound spam. Personally, I think associating such > reputation scores with IPv6 prefixes or addresses is a bit > dodgy, but this is I think something that is done in the > wild, (no idea how frequently) so would be worth a mention. > If you have good arguments as to why such a scheme is a bad > idea, that'd be good to include as well. > Implementing DoS protection or rate limiting based on /128s is highly inadvisable because any residential user with a /60 can create 2^68 state table entries. Some hosting providers and even tunnel broker providers offer /48s. That said, I think this is out of scope for this draft because a server is not a general purpose host, and this document only applies to general purpose hosts. - I was a bit surprised to not see any mention here of > ULAs. I've seen one DHCPv6 setup where my laptop was > assigned a ULA with a very long lease in the hope of always > having that connectivity to local systems that aren't all > on the link. But having that plus real global addresses > caused glitches as (I think) my OS (ubuntu) wasn't sure > which of the addresses to use as the source for what. > While I didn't explore what was going on there (I just > zapped the lease:-), do you need to say how to handle cases > where one has both real global and ULAs on an interface? > ULAs are different prefixes so they are covered by this text: it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts We already have guidance on how applications should work in the presence of ULAs - it's in RFC 6724. This does appear to work for me - I have a network that provides both ULA and global, and Ubuntu 14.04 just seems to do the right thing. - I would have liked if you had said that, other things > being equal, OSes SHOULD prefer to use privacy addresses as > the source address or as a default. Is there a reason to > not say that? (Just wondering, I'm not trying to strongly > argue that you do.) > While I agree, I think this is out of scope for this document and this working group. There is a lively debate going on in 6man around the topic of address stability and privacy, and I think that is the right place for this topic. Cheers, Lorenzo --94eb2c0815c823c5fd0533b6eb9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 4, 2016 at 5:25 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
- I think you're missi= ng one other reason why people
allocate /128's - in a hosting/VPS environment, the hoster
might want to avoid VPS's that originate spam using many
different source addresses over time so as to attempt to
avoid IP address based (bad) reputation accruing to their
outbound spam. Personally, I think associating such
reputation scores with IPv6 prefixes or addresses is a bit
dodgy, but this is I think something that is done in the
wild, (no idea how frequently) so would be worth a mention.
If you have good arguments as to why such a scheme is a bad
idea, that'd be good to include as well.

Implementing DoS protection or rate limiting based on /128s is highly= inadvisable because any residential user with a /60 can create 2^68 state = table entries. Some hosting providers and even tunnel broker providers offe= r /48s. That said, I think this is out of scope for this draft because a se= rver is not a general purpose host, and this document only applies to gener= al purpose hosts.

- I was a bit surpri= sed to not see any mention here of
ULAs. I've seen one DHCPv6 setup where my laptop was
assigned a ULA with a very long lease in the hope of always
having that connectivity to local systems that aren't all
on the link. But having that plus real global addresses
caused glitches as (I think) my OS (ubuntu) wasn't sure
which of the addresses to use as the source for what.
While I didn't explore what was going on there (I just
zapped the lease:-), do you need to say how to handle cases
where one has both real global and ULAs on an interface?

ULAs are different prefixes so they are covered by this t= ext:

=C2=A0 =C2=A0it is RECOMMENDED that IPv6= network deployments provide
=C2=A0 =C2=A0multiple IPv6 addresses= from each prefix to general-purpose hosts

W= e already have guidance on how applications should work in the presence of = ULAs - it's in RFC 6724. This does appear to work for me - I have a net= work that provides both ULA and global, and Ubuntu 14.04 just seems to do t= he right thing.

- I would have liked i= f you had said that, other things
being equal, OSes SHOULD prefer to use privacy addresses as
the source address or as a default. Is there a reason to
not say that? (Just wondering, I'm not trying to strongly
argue that you do.)

While I agree, I th= ink this is out of scope for this document and this working group. There is= a lively debate going on in 6man around the topic of address stability and= privacy, and I think that is the right place for this topic.
Cheers,
Lorenzo
--94eb2c0815c823c5fd0533b6eb9e-- From nobody Wed May 25 23:21:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5BF12B071; Wed, 25 May 2016 23:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSxpsXbdoIgM; Wed, 25 May 2016 23:20:57 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94D812D0A0; Wed, 25 May 2016 23:20:57 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id k1so34631298vka.3; Wed, 25 May 2016 23:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w0Ah5XtWjXL8+WLuyMO6ykCQAfcV/xXYi4lBUvjTYbo=; b=IkmmvEiB1WwCQYsT/1QBe6d6oEnBLQaoKTPOKgdnZTcpUcMkypye6WxxvtDW3K1NW/ nTVsP0Rc80Bhon5T6A+7+8gErwOcfbt5RclWN0g2deXOvScXbrvWgAEit6eDYJsQ6ba/ DigMJuR8wgp5G4ofVMjKVSC4SqK4ehyagZvL5LbgxefbZk1rslMfTW5qtqboLdCYJCtm 9ttc8Sub9F7KODlkK+FLHTD+HMZHNOGxyE8rv3FtbYLh4jxdPDRvBQJzwm3MPzNUD3RJ /jcqRzQIAAYpJJLlUvQ9ls90NScqNZfN6fqPqfJaEyQ/+9W67I8TYmO+4nXSF7h7QcMI ghqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w0Ah5XtWjXL8+WLuyMO6ykCQAfcV/xXYi4lBUvjTYbo=; b=MZlRl1Ciju+9018tdReDTkh0aqdEI4bUQxfLo9BEllZ5rNubnGF7QPYShzz10U4Oaq FiSPNlChtOcGBiVIG5ULIJsN5nMs1Y0s5KYaRZu9N+qgSL0w/cylPJjVxdNg6auwfY0h 9SsCGwO532XMcftTtqJVxfw3OYIK+Saoj+IJ+wIBrGN7vjZp4i5arhtGbYri1Me2bMQq AKRVWu9dBUaoLn2GqqXlPx4MZrErlaJyLtI3GXZNS7MWsLpzubeiJUk6LEmJyB0XaXwq Gm6RrdPHK5WlkTuTqvle5ee+SnatCQTiqhL0YQ4yjqil/5Obo0HV9MJLR2s1iSE243xN Pn9A== X-Gm-Message-State: ALyK8tKMcLpkoJOFBL1phIpNGXsNwmlUO/ug9EqT2zZ5AqAFi0f1fAGTbs9ajtKmso4BAYRdB0SyyiW3grNePA== X-Received: by 10.31.146.144 with SMTP id u138mr4603621vkd.2.1464243656808; Wed, 25 May 2016 23:20:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.168 with HTTP; Wed, 25 May 2016 23:20:27 -0700 (PDT) In-Reply-To: References: <20160504082512.8358.20806.idtracker@ietfa.amsl.com> From: Mark Smith Date: Thu, 26 May 2016 16:20:27 +1000 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, Stephen Farrell Subject: Re: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:21:00 -0000 On 26 May 2016 at 14:06, Lorenzo Colitti wrote: > On Wed, May 4, 2016 at 5:25 PM, Stephen Farrell > wrote: >> > >> - I would have liked if you had said that, other things >> being equal, OSes SHOULD prefer to use privacy addresses as >> the source address or as a default. Is there a reason to >> not say that? (Just wondering, I'm not trying to strongly >> argue that you do.) > > > While I agree, I think this is out of scope for this document and this > working group. I agree it is out of scope for this document. It is in scope for RFC6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)", and that is exactly what it says ;-) " 5. Changed the default recommendation for Source Address Selection Rule 7 to prefer temporary addresses rather than public addresses, while providing an administrative override (in addition to the application-specific override that was already specified). This change was made because of the increasing importance of privacy considerations, as well as the fact that widely deployed implementations have preferred temporary addresses for many years without major application issues." Regards, Mark. From nobody Thu May 26 12:24:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16E12D110 for ; Thu, 26 May 2016 12:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKBjoUdZngUy for ; Thu, 26 May 2016 12:24:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B18A12D8F1 for ; Thu, 26 May 2016 12:24:36 -0700 (PDT) Received: from [10.0.1.24] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4QJOYEs027744 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 May 2016 14:24:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.24] From: "Ben Campbell" To: "Lorenzo Colitti" Date: Thu, 26 May 2016 14:24:33 -0500 Message-ID: <969DEC5A-25DF-468D-BCE1-D61D44108768@nostrum.com> In-Reply-To: References: <20160503222244.8246.28466.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "v6ops@ietf.org WG" , fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Subject: Re: [v6ops] Ben Campbell's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 19:24:38 -0000 It all looks good, thanks! Ben. On 25 May 2016, at 23:05, Lorenzo Colitti wrote: > Ben, > > we've addressed the comments in -07. > > On Wed, May 4, 2016 at 7:22 AM, Ben Campbell wrote: > >> Section 7: I _think_ the point of this section is to suggest that we >> cannot reasonably estimate an upper limit. But if it says that >> explicitly, I missed it. (I fear a careless reader will walk away >> thinking "20" is a good limit) >> > > We've attempted to to address this by adding the following sentence at the > end of the section: > > Thus, in general is is not possible to estimate in advance > how many addresses are required. > > Better? > > Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to >> impose a hard limit/ >> > > Updated. > > Regards, > Lorenzo From nobody Thu May 26 20:51:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC512D170; Thu, 26 May 2016 20:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-MdRhxXFij5; Thu, 26 May 2016 20:51:35 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E371812D0F2; Thu, 26 May 2016 20:51:34 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-86-5747bb9dff59 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 09.03.09012.D9BB7475; Fri, 27 May 2016 05:14:37 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Thu, 26 May 2016 23:51:33 -0400 From: Suresh Krishnan To: Lorenzo Colitti Thread-Topic: Suresh Krishnan's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) Thread-Index: AQHRpbMNHlluDFoQ7UK3A3XUewKDaw== Date: Fri, 27 May 2016 03:51:32 +0000 Message-ID: References: <20160504031415.8354.72069.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXSPt+7c3e7hBs9vyVh8PbufyWLrpmYm i3XnXrJbzPgzkdli/el3jBZTH79nsjh9bC+zA7vHlN8bWT0WbCr1WLLkJ5PHl8uf2QJYorhs UlJzMstSi/TtErgyFv84zlJwj69i1bQzjA2Mi7m7GDk5JARMJJ6f/84CYYtJXLi3nq2LkYtD SOAoo8S0rb8YQRJCAssZJdYf8AKx2YAaNuz8zARiiwhoSDxYd5wJpIFZYAKzxLVdf8AahAWS JI7vnsAKUZQs8eP7R/YuRg4gW09i+lkHkDCLgKrElec32EFsXgFfiQkLTzJCLG5nlJi44TxY LyPQRd9PrQFbxiwgLnHryXwmiEsFJJbsOc8MYYtKvHz8jxXCVpL4+Hs+O0S9jsSC3Z/YIGxt iWULXzNDLBOUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjFylBYX5OSmGxlsYgTG1DEJNt0d jPenex5iFOBgVOLhXWDpHi7EmlhWXJl7iFGCg1lJhFfsMFCINyWxsiq1KD++qDQntfgQozQH i5I4r9gjxXAhgfTEktTs1NSC1CKYLBMHp1QD4xwD+4cqDetmnSyI+VXyvkGu72hw38nNCuwe 0myiPCL765ItKphKko1qFh1g8bzOWDb3kr3kitOv67ZFnNrrXqNQ8c2DJ/TCpIr9llvP7798 8Nj1Epm99i5eqrtldk7L+DFlo0v35ewNji4Br9W12OaIsmT32h6Xm+J+JKZ1zbbogJi/vmt1 lFiKMxINtZiLihMBoUNdCKUCAAA= Archived-At: Cc: "v6ops@ietf.org WG" , "fred.baker@cisco.com" , "draft-ietf-v6ops-host-addr-availability@ietf.org" , "v6ops-chairs@ietf.org" , The IESG , "draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org" Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 03:51:37 -0000 Hi Lorenzo,=0A= The changes look good. Thanks for taking care of these issues.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 05/26/2016 12:04 AM, Lorenzo Colitti wrote:=0A= > Suresh,=0A= > =0A= > thanks for the comments. We've addressed them in -07.=0A= > =0A= > On Wed, May 4, 2016 at 12:14 PM, Suresh Krishnan=0A= > > wrot= e:=0A= > =0A= > * What is the term ePDG being used here? Can you please add a referen= ce?=0A= > The well known term in mobile networks is Evolved Packet Data Gateway= =0A= > that is used for IPsec tunnel termination. That does not seem to make= =0A= > sense here.=0A= > =0A= > =0A= > Good catch. Clarified to:=0A= > =0A= > particularly for=0A= > technologies like I-WLAN [TS.24327] where the two processors share= =0A= > the Wi-Fi network connection.=0A= > =0A= > Better?=0A= > =0A= > * Maybe worth adding a reference to RFC7278 (64share) here as an exam= ple=0A= > for "Extending the network (e.g., "tethering")."=0A= > =0A= > =0A= > We do cite RFC7278 elsewhere. Not sure a reference is needed here, since = it's=0A= > not the only way of doing tethering.=0A= > =0A= > =0A= > s/which is only available in 3GPP release 10/which is only available = in=0A= > 3GPP release 10 onwards/=0A= > =0A= > =0A= > Done.=0A= > =0A= > =0A= > It is not clear what this bullet means. Can you clarify?=0A= > =0A= > " o Uncertainty, because it is not known in advance if a particular= =0A= > operation function will be available."=0A= > =0A= > =0A= > Clarified to "Uncertainty, because it is not known if a particular operat= ion=0A= > function will be available until the provisioning operation succeeds or f= ails."=0A= =0A= =0A= > =0A= > Regards,=0A= > Lorenzo=0A= =0A= From nobody Fri May 27 14:10:57 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1087C12D924; Fri, 27 May 2016 14:10:46 -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: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527211046.11166.25640.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 14:10:46 -0700 Archived-At: Cc: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, joelja@gmail.com, v6ops-chairs@ietf.org, The IESG , draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] Protocol Action: 'Host address availability recommendations' to Best Current Practice (draft-ietf-v6ops-host-addr-availability-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 21:10:46 -0000 The IESG has approved the following document: - 'Host address availability recommendations' (draft-ietf-v6ops-host-addr-availability-07.txt) as Best Current Practice This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ Technical Summary This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. Working Group Summary This particular draft has not been controversial; it borders on stating the obvious, and certainly states a consensus of IPv6 operators and designers in the IETF. It does, however, recommend a change from current general practice with DHCP/DHCPv6, a change that the author's companies are explicitly exploring and finding useful, which is to allocate a prefix to a host rather than a single address. Document Quality This is not a protocol, it is a proposal regarding IPv6 protocol deployment practice. That said, yes, there are multiple implementations. Windows, MacOSX, Linux, and other operating systems expect to use multiple addresses in the same prefix simultaneously, and common practice using SLAAC directly supports this. The issue has to do with DHCP/DHCPv6 address allocation, which a network operator might restrict to a single address unnecessarily. Personnel The Document Shepherd is Fred Baker. The AD is Joel Jaeggli. From nobody Tue May 31 03:08:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68FD12D6FB for ; Tue, 31 May 2016 03:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b27ybwOBvCgh for ; Tue, 31 May 2016 03:08:54 -0700 (PDT) Received: from mta00.svc.cra.dublin.eircom.net (mta00.svc.cra.dublin.eircom.net [159.134.118.55]) by ietfa.amsl.com (Postfix) with SMTP id B201C12D6E4 for ; Tue, 31 May 2016 03:08:53 -0700 (PDT) Received: (qmail 21700 messnum 5910944 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 31 May 2016 10:08:51 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (HELO avas00) (213.94.190.11) by mta00.svc.cra.dublin.eircom.net (qp 21700) with SMTP; 31 May 2016 10:08:51 -0000 Received: from [159.134.250.224] ([159.134.250.224]) by Cloudmark Gateway with SMTP id 7gbTbTXrZT74P7gbTbhpJW; Tue, 31 May 2016 11:08:51 +0100 X-CNFS-Analysis: v=2.1 cv=daMgpSje c=1 sm=1 tr=0 a=r1X+M5CiF9LD/oHFr0z0dw==:117 a=r1X+M5CiF9LD/oHFr0z0dw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=t-IPkPogAAAA:8 a=48vgC7mUAAAA:8 a=jqGG--jNLTTdw9G43W4A:9 a=QEXdDO2ut3YA:10 a=0gXKrx3AAncA:10 a=TlSEhoGMJ-46eavboIYA:9 a=MsuQN856Ask_DTIC:21 a=_W_S_7VecoQA:10 a=TwOW_m0CY6OjrxjWeTv9:22 a=w1C3t2QeGrPiZgrLijVG:22 Content-Type: multipart/alternative; boundary="Apple-Mail=_DCCC0BFE-959A-425C-B024-EB00227DCA44" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ross Chandler In-Reply-To: Date: Tue, 31 May 2016 11:07:09 +0100 Message-Id: <4C80D4B8-0230-4E1F-A577-93E63C9D053E@eircom.net> References: To: David Schinazi X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfBEw6JEkrPdBDWgf1G1RC/XN5ZgFWxxa7AcmOf/OyNjU0VW4kbg+y6P89TFGe7RrJKeqE6MOAkfb0+9Kllc7dObKUKHlpQSC2sFjgWmWvHD+9rAl/2ur EcmF03LVCNd54C3xoTImez//2fOpVUMrE1gpAbWaRwEdrnL5mEtvdoAqZmTXNW497pPeW79QasFtpf+jrJ6195A71cJcj/Vh6gY= Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6 - new NAT64 address synthesis API X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 10:08:57 -0000 --Apple-Mail=_DCCC0BFE-959A-425C-B024-EB00227DCA44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, Can I ask what Apple=E2=80=99s intentions are for supporting tethered = devices? In particular in the case where the iOS device only has = IPv6-only PDP/PDN connections or a shared handset & tethering IPv6-only = APN? If the tethering interface of the iOS device can only provide 64share = (RFC 7278) without support for IPv4 (e.g. via an RFC 6877 clat) then = tethered devices will be restricted to those supporting IPv6-only = connectivity using DNS64/NAT64. =20 Thanks Ross > On 30 Oct 2015, at 04:51, David Schinazi wrote: >=20 > Hi everyone, >=20 > This week Apple released the first betas of iOS 9.2 and OS X 10.11.2. > With it, we=E2=80=99ve introduced a new API to allow developers to = synthesize NAT64 IPv6 addresses from IPv4 literals. > We=E2=80=99re hoping that this will help more applications support = NAT64 networks correctly while they work on getting server support for = IPv6. > As usual, we=E2=80=99d love feedback from the IETF community. >=20 > The API is very simple: we ask developers to always ``resolve'=E2=80=99 = their IPv4 literals using getaddrinfo() by treating their IPv4 literal = as a hostname string (e.g. ``192.0.2.1''), and we will take care of = returning an IPv4 sockaddr on IPv4 networks and an appropriately = synthesized NAT64 IPv6 sockaddr when the network supports IPv6, NAT64 = and DNS64 but not IPv4. This is accomplished using RFC 6052 and RFC = 7050. >=20 > Our target audience is application developers that need to communicate = to an IPv4-only host for which they do not have a hostname. An example = is a P2P service transmitting IPv4 literals over the wire. We do agree = that the correct long-term solution is IPv6 support for all hosts and = protocols but this is an effort to ease the transition. We believe this = will help fix any remaining apps that do not support IPv6 before we = start rejecting them from the App Store in early 2016. >=20 > More details and a code sample can be found on the Apple documentation = website: >=20 > = https://developer.apple.com/library/prerelease/tvos/documentation/Networki= ngInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingforth= eIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple= _ref/doc/uid/TP40010220-CH213-DontLinkElementID_4 = >=20 > Thanks, > David Schinazi > Apple CoreOS Networking Engineer > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_DCCC0BFE-959A-425C-B024-EB00227DCA44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi David,

Can I ask what Apple=E2=80=99s intentions are for supporting = tethered devices? In particular in the case where the iOS device only = has IPv6-only PDP/PDN connections or a shared handset & tethering = IPv6-only APN?
If the tethering interface of the = iOS device can only provide 64share (RFC 7278) without support for IPv4 = (e.g. via an RFC 6877 clat) then tethered devices will be restricted to = those supporting IPv6-only connectivity using DNS64/NAT64. =  

Thanks
Ross



On = 30 Oct 2015, at 04:51, David Schinazi <dschinazi@apple.com>= wrote:

Hi everyone,

This week Apple released the first betas of iOS 9.2 and OS X = 10.11.2.
With it, we=E2=80=99ve introduced a new = API to allow developers to synthesize NAT64 IPv6 addresses from IPv4 = literals.
We=E2=80=99re hoping that this will help = more applications support NAT64 networks correctly while they work on = getting server support for IPv6.
As usual, we=E2=80=99= d love feedback from the IETF community.

The API is very simple: we ask = developers to always ``resolve'=E2=80=99 their IPv4 literals using = getaddrinfo() by treating their IPv4 literal as a hostname string (e.g. = ``192.0.2.1''), and we will take care of returning an IPv4 sockaddr on = IPv4 networks and an appropriately synthesized NAT64 IPv6 sockaddr when = the network supports IPv6, NAT64 and DNS64 but not IPv4. This is = accomplished using RFC 6052 and RFC 7050.

Our target audience is application = developers that need to communicate to an IPv4-only host for which they = do not have a hostname. An example is a P2P service transmitting IPv4 = literals over the wire. We do agree that the correct long-term solution = is IPv6 support for all hosts and protocols but this is an effort to = ease the transition. We believe this will help fix any remaining apps = that do not support IPv6 before we start rejecting them from the App = Store in early 2016.

More details and a code sample can be found on the Apple = documentation website:

https://developer.apple.com/library/prerelease/tvos/documentati= on/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPre= paringfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.h= tml#//apple_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4

Thanks,
David Schinazi
Apple CoreOS Networking = Engineer
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_DCCC0BFE-959A-425C-B024-EB00227DCA44--