On Wed, Oct= 5, 2016 at 2:26 PM, Lee Howard <Lee@asgard.org> wrote:

This draf= t generated a lot of discussion at our last meeting, in Berlin, but there h= as been very little discussion since it was updated a month ago.=C2=A0

Do people feel that this version addresses their conce= rns? Is this a good idea?

If there's interest,= this will be on the agenda for our next meeting, including whether we shou= ld adopt it as a working group item.

Lee

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

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Ce= ll: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

--001a1145711c23f2ec053e2792b0-- From nobody Thu Oct 6 00:02: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 E9F09129525 for ; Thu, 6 Oct 2016 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ukHxGaFx5FtN for ; Thu, 6 Oct 2016 00:02:43 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD4E1294C7 for ; Thu, 6 Oct 2016 00:02:42 -0700 (PDT) Received: from mfilter40-d.gandi.net (mfilter40-d.gandi.net [217.70.178.171]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1FB2417209B; Thu, 6 Oct 2016 09:02:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter40-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter40-d.gandi.net (mfilter40-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qW6Phj4PpFRd; Thu, 6 Oct 2016 09:02:39 +0200 (CEST) X-Originating-IP: 188.15.31.14 Received: from [10.25.1.66] (host14-31-static.15-188-b.business.telecomitalia.it [188.15.31.14]) (Authenticated sender: federico@xylant.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9F0FD1720A9; Thu, 6 Oct 2016 09:02:38 +0200 (CEST) In-Reply-To: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> X-Referenced-Uid: 86 Thread-Topic: draft-anderson-v6ops-v4v6-xlat-prefix User-Agent: Type for Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GELSSRNX98B4YA02X2A8TXUCXFFLA5" Content-Transfer-Encoding: 8bit From: Federico Santandrea Date: Thu, 06 Oct 2016 09:02:36 +0200 To: Lee Howard Message-ID: <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] 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, 06 Oct 2016 07:02:47 -0000 ------GELSSRNX98B4YA02X2A8TXUCXFFLA5 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hello, I have a doubt about this sentence contained in the draft: "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are intended for very similar uses, it is prudent to allow them to be referred to using a single aggregate (64:ff9b::/47)." This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either range. Readers might be misled into thinking that they might just route for 64:ff9b::/47 and be done with it, but this would mean they are willing to forward packets that will be dropped afterwards anyway, since the addresses above are in a range which would not be allocated and therefore should not be routed. Additionally I can't see benefit in keeping the sentence in the draft (i.e.: I don't think it really adds to the explanation). Am I missing something here? Does anyone agree with this? -- Federico Santandrea Il giorno 5 ott 2016, 21:26, alle ore 21:26, Lee Howard ha scritto: >This draft generated a lot of discussion at our last meeting, in >Berlin, but there has been very little discussion since it was updated >a month ago. > >Do people feel that this version addresses their concerns? Is this a >good idea? > >If there's interest, this will be on the agenda for our next meeting, >including whether we should adopt it as a working group item. > >Lee > > > > >------------------------------------------------------------------------ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ------GELSSRNX98B4YA02X2A8TXUCXFFLA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

I have a doubt about this sentence contained in the draft:

"64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are intended for very similar uses, it is prudent to allow them to be referred to using a single aggregate (64:ff9b::/47)."

This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either range. Readers might be misled into thinking that they might just route for 64:ff9b::/47 and be done with it, but this would mean they are willing to forward packets that will be dropped afterwards anyway, since the addresses above are in a range which would not be allocated and therefore should not be routed.

Additionally I can't see benefit in keeping the sentence in the draft (i.e.: I don't think it really adds to the explanation).

Am I missing something here? Does anyone agree with this?

--
Federico Santandrea

Il giorno 5 ott 2016, alle ore 21:26, Lee Howard <Lee@asgard.org> ha scritto:

This draft generated a lot of discussion at our last meeting, in Berlin, but there has been very little discussion since it was updated a month ago.

Do people feel that this version addresses their concerns? Is this a good idea?

If there's interest, this will be on the agenda for our next meeting, including whether we should adopt it as a working group item.

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

------GELSSRNX98B4YA02X2A8TXUCXFFLA5-- From nobody Thu Oct 6 06:22: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 45ED412964F for ; Thu, 6 Oct 2016 06:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.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 yA0fve41b6mU for ; Thu, 6 Oct 2016 06:22:39 -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 C42CB129663 for ; Thu, 6 Oct 2016 06:21:36 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=37058 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 1bs8c8-000459-E3; Thu, 06 Oct 2016 15:21:32 +0200 Date: Thu, 6 Oct 2016 15:21:29 +0200 From: Tore Anderson To: Federico Santandrea Message-ID: <20161006152129.27e96d62@echo.ms.redpill-linpro.com> In-Reply-To: <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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] 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, 06 Oct 2016 13:22:44 -0000 * Federico Santandrea > I have a doubt about this sentence contained in the draft: > > "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are > intended for very similar uses, it is prudent to allow them to be > referred to using a single aggregate (64:ff9b::/47)." > > This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and > 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either > range. Readers might be misled into thinking that they might just > route for 64:ff9b::/47 and be done with it, but this would mean they > are willing to forward packets that will be dropped afterwards > anyway, since the addresses above are in a range which would not be > allocated and therefore should not be routed. > > Additionally I can't see benefit in keeping the sentence in the draft > (i.e.: I don't think it really adds to the explanation). Hi Federico, and thanks for your input. I can remove this sentence in the next version, or try to reformulate it. I do think there's still a valid reason to make sure the new prefix and the RFC6052 WKP can be aggregated in a as small prefix as possible (and if the new prefix is a /48 the smallest aggregate is obviously going to be a /47). This is for the simple reason that doing so will "taint" the least possible amount of unallocated address space; the draft could have set aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32 and 64:ff9b::/32 would be both end up "tainted". (Of course, should the WG consensus be to prefer 64::/48 or cafe::/48 or whatever instead, then it's fine by me and I'll be happy to update the draft accordingly.) Tore From nobody Thu Oct 6 07: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 217DE129686 for ; Thu, 6 Oct 2016 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 exSsh4vLjmuG for ; Thu, 6 Oct 2016 07:04:39 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B04129689 for ; Thu, 6 Oct 2016 07:04:33 -0700 (PDT) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C67C3172111; Thu, 6 Oct 2016 16:04:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IemM_zcLpUa6; Thu, 6 Oct 2016 16:03:59 +0200 (CEST) X-Originating-IP: 151.18.30.9 Received: from [10.31.52.180] (mi-18-30-9.service.infuturo.it [151.18.30.9]) (Authenticated sender: federico@xylant.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5C08E1720AC; Thu, 6 Oct 2016 16:03:57 +0200 (CEST) In-Reply-To: <20161006152129.27e96d62@echo.ms.redpill-linpro.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> X-Referenced-Uid: 92 Thread-Topic: Re: [v6ops] draft-anderson-v6ops-v4v6-xlat-prefix User-Agent: Type for Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----N1E6DGU24KKO8NK1PD0FDD0JRV9E90" Content-Transfer-Encoding: 8bit From: Federico Santandrea Date: Thu, 06 Oct 2016 16:03:55 +0200 To: Tore Anderson Message-ID: <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] 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, 06 Oct 2016 14:04:44 -0000 ------N1E6DGU24KKO8NK1PD0FDD0JRV9E90 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I agree with that reasoning. What about keeping that sentence, but changing the reservation request for Local-use IPv4/IPv6 Translation to actually be 64:ff9b::/47 (instead of 64:ff9b:1::/48)? This way it would be really true that the two can be aggregated, and the extra addresses that are not yet covered by neither RFC6052 or the draft could then be used in the future by similar translation techniques. If instead we have the 64:ff9b:1::/48 and 64:ff9b::/96 reservations, in theory smaller subnets in the middle of the two can be used in some other way, and then aggregating the two blocks wouldn't be as clean. -- Federico Santandrea Il giorno 6 ott 2016, 15:21, alle ore 15:21, Tore Anderson ha scritto: >* Federico Santandrea > >> I have a doubt about this sentence contained in the draft: >> >> "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are >> intended for very similar uses, it is prudent to allow them to be >> referred to using a single aggregate (64:ff9b::/47)." >> >> This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and >> 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either >> range. Readers might be misled into thinking that they might just >> route for 64:ff9b::/47 and be done with it, but this would mean they >> are willing to forward packets that will be dropped afterwards >> anyway, since the addresses above are in a range which would not be >> allocated and therefore should not be routed. >> >> Additionally I can't see benefit in keeping the sentence in the draft >> (i.e.: I don't think it really adds to the explanation). > >Hi Federico, and thanks for your input. > >I can remove this sentence in the next version, or try to reformulate >it. > >I do think there's still a valid reason to make sure the new prefix >and the RFC6052 WKP can be aggregated in a as small prefix as possible >(and if the new prefix is a /48 the smallest aggregate is obviously >going to be a /47). > >This is for the simple reason that doing so will "taint" the least >possible amount of unallocated address space; the draft could have set >aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32 >and 64:ff9b::/32 would be both end up "tainted". > >(Of course, should the WG consensus be to prefer 64::/48 or cafe::/48 >or >whatever instead, then it's fine by me and I'll be happy to update the >draft accordingly.) > >Tore ------N1E6DGU24KKO8NK1PD0FDD0JRV9E90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I agree with that reasoning.

What about keeping that sentence, but changing the reservation request for Local-use IPv4/IPv6 Translation to actually be 64:ff9b::/47 (instead of 64:ff9b:1::/48)? This way it would be really true that the two can be aggregated, and the extra addresses that are not yet covered by neither RFC6052 or the draft could then be used in the future by similar translation techniques.

If instead we have the 64:ff9b:1::/48 and 64:ff9b::/96 reservations, in theory smaller subnets in the middle of the two can be used in some other way, and then aggregating the two blocks wouldn't be as clean.

--
Federico Santandrea

Il giorno 6 ott 2016, alle ore 15:21, Tore Anderson <tore@fud.no> ha scritto:

Hi Federico, and thanks for your input.

I can remove this sentence in the next version, or try to reformulate
it.

I do think there's still a valid reason to make sure the new prefix
and the RFC6052 WKP can be aggregated in a as small prefix as possible
(and if the new prefix is a /48 the smallest aggregate is obviously
going to be a /47).

This is for the simple reason that doing so will "taint" the least
possible amount of unallocated address space; the draft could have set
aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32
and 64:ff9b::/32 would be both end up "tainted".

(Of course, should the WG consensus be to
prefer 64::/48 or cafe::/48 or
whatever instead, then it's fine by me and I'll be happy to update the
draft accordingly.)

Tore

------N1E6DGU24KKO8NK1PD0FDD0JRV9E90-- From nobody Thu Oct 6 07:15:36 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 EDBCD12968A for ; Thu, 6 Oct 2016 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.796 X-Spam-Level: X-Spam-Status: No, score=-6.796 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 c9lFwDsol2CV for ; Thu, 6 Oct 2016 07:15:30 -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 720DB12966F for ; Thu, 6 Oct 2016 07:15:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id D501F24E for ; Thu, 6 Oct 2016 14:15:29 +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 Q-covVjTwnvt for ; Thu, 6 Oct 2016 09:15:29 -0500 (CDT) Received: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) (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 9FBFFBB8 for ; Thu, 6 Oct 2016 09:15:29 -0500 (CDT) Received: by mail-qt0-f199.google.com with SMTP id g32so790957qta.2 for ; Thu, 06 Oct 2016 07:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6MQRQ9hHingBX2MCinnbG2HXS2cJwWasL8ZrgtxaCLU=; b=YxcUBu5mjLIRgUeHJlsLsFAscD1ZHdfrr/iG6jquuIb2L3yItwfk9Bk4fUWGcZyu/X nQ/BCYHF5SbVuNPs/XqRrBuBP/v2g3tA20QH6HFyyoMPvzA+lXsHzw4fqJYpSWSJTh0w +3Ew3Drt1peeXyGOH94q/JdCml/QsIhAQ0RLOFPYpei0MrUzUOZ33rpLW7Vo3PmByHaN kysuJn90ILTVP8jP7jUHI+5oZRrq6EoiKXvkJ4l7b5txLB72EYKL47lPJbVXHZ5/WKQ/ +uEn9WJltmZpdE2Pp2uSasTuk874U+floJZESvkrfHrsvHM+JAXVCjE2azWMFAieOXif Yqbg== 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=6MQRQ9hHingBX2MCinnbG2HXS2cJwWasL8ZrgtxaCLU=; b=J/JJH3fT7W/GFjmoZZ7xG5Xu54d2VwBKCFkKvK8CfD7jxyUhkO4gaBsCOTPDPugZc7 g5+FquJwlplB/EJVKP6UQv6aK5SWr/EcusqZ8SF7LqRHvBeQJkyGLlI44qbywDOcti2q Tf8nsCCaunvCAncYaIACcNizhHZhmBNfuzSa4PypOD/fCyn4AvaiUIyoBi7QgtuuOH8R OqT0wVqRynVoKpa8Ro95s95sImjuZKelNQMr82cX2hcrp4tWxN7vId2Y+hE6ct5PRJOP xQsdowzmWu7j9cnAWxuZJtXkgmHEDk6cNAi88EDNegJ3NkmZBk01ofSEr7fL5/YllgvT iD/g== X-Gm-Message-State: AA6/9RkUpAA6DZ4DyjimI0Oa9dYGHDboaq5uin801qhgteRIGXeak843MN/jsskmrNWypSoXXdAlqqWmrOl5ng8DArHf/5vw36jAwdQ6sXLdXlrVVkGrqQOLSHPzjLCAwP5dKX1P9LrSxk9HPKlY X-Received: by 10.55.209.207 with SMTP id o76mr13649847qkl.276.1475763329045; Thu, 06 Oct 2016 07:15:29 -0700 (PDT) X-Received: by 10.55.209.207 with SMTP id o76mr13649815qkl.276.1475763328769; Thu, 06 Oct 2016 07:15:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.58 with HTTP; Thu, 6 Oct 2016 07:15:28 -0700 (PDT) In-Reply-To: <20161006152129.27e96d62@echo.ms.redpill-linpro.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> From: David Farmer Date: Thu, 6 Oct 2016 09:15:28 -0500 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a1149993afbf5bb053e32ec36 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] 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, 06 Oct 2016 14:15:35 -0000 --001a1149993afbf5bb053e32ec36 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 6, 2016 at 8:21 AM, Tore Anderson wrote: > * Federico Santandrea > > > I have a doubt about this sentence contained in the draft: > > > > "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are > > intended for very similar uses, it is prudent to allow them to be > > referred to using a single aggregate (64:ff9b::/47)." > > > > This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and > > 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either > > range. Readers might be misled into thinking that they might just > > route for 64:ff9b::/47 and be done with it, but this would mean they > > are willing to forward packets that will be dropped afterwards > > anyway, since the addresses above are in a range which would not be > > allocated and therefore should not be routed. > > > > Additionally I can't see benefit in keeping the sentence in the draft > > (i.e.: I don't think it really adds to the explanation). > > Hi Federico, and thanks for your input. > > I can remove this sentence in the next version, or try to reformulate > it. > > I do think there's still a valid reason to make sure the new prefix > and the RFC6052 WKP can be aggregated in a as small prefix as possible > (and if the new prefix is a /48 the smallest aggregate is obviously > going to be a /47). > > This is for the simple reason that doing so will "taint" the least > possible amount of unallocated address space; the draft could have set > aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32 > and 64:ff9b::/32 would be both end up "tainted". > > (Of course, should the WG consensus be to prefer 64::/48 or cafe::/48 or > whatever instead, then it's fine by me and I'll be happy to update the > draft accordingly.) > > Tore > I'm fine with anything up to a /32 begin reserved for v4v6 xlate purposes in the most general sense, overall this purpose easily justifies at least the default allocation we make to an ISP. My recommendation is it keep what I view as the intent of the current text and simply reserve the whole /47, or larger, for generalized v4v6 xlate purposes, but further reserving the space beyond 64:ff9b:1::/48 for future designated purposes, such as additional WKPs, etc... Allowing the use of 64:ff9b:1::/48 as currently specified in detail, but allowing use of the aggregated /47 prefix, or larger, in a way similar to the current text. Thanks -- =============================================== 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 =============================================== --001a1149993afbf5bb053e32ec36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 6, 2016 at 8:21 AM, Tore Anderson <tore@fud.no> wr= ote:

* Federico Santan= drea <federico@xylant.net>=

> I have a doubt about this sentence contained in the draft:
>
> "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes ar= e
> intended for very similar uses, it is prudent to allow them to be
> referred to using a single aggregate (64:ff9b::/47)."
>
> This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and
> 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either<= br> > range. Readers might be misled into thinking that they might just
> route for 64:ff9b::/47 and be done with it, but this would mean they > are willing to forward packets that will be dropped afterwards
> anyway, since the addresses above are in a range which would not be > allocated and therefore should not be routed.
>
> Additionally I can't see benefit in keeping the sentence in the dr= aft
> (i.e.: I don't think it really adds to the explanation).

Hi Federico, and thanks for your input.

I can remove this sentence in the next version, or try to reformulate
it.

I do think there's still a valid reason to make sure the new prefix
and the RFC6052 WKP can be aggregated in a as small prefix as possible
(and if the new prefix is a /48 the smallest aggregate is obviously
going to be a /47).

This is for the simple reason that doing so will "taint" the leas= t
possible amount of unallocated address space; the draft could have set
aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32
and 64:ff9b::/32 would be both end up "tainted".

(Of course, should the WG consensus be to prefer 64::/48 or cafe::/48 or whatever instead, then it's fine by me and I'll be happy to update = the
draft accordingly.)

Tore

I'm fine with anything up to a= /32 begin reserved for v4v6 xlate purposes in the most general sense, over= all this purpose easily justifies at least the default allocation we make t= o an ISP.=C2=A0

My recommendation is it keep= what I view as the intent of the current text and simply reserve the whole= /47, or larger, for generalized v4v6 xlate purposes, but further reserving= the space beyond 64:ff9b:1::/48=C2=A0for future designated purposes, such = as additional WKPs, etc...=C2=A0 Allowing the use of 64:ff9b:1::/48 as curr= ently specified in detail, but allowing use of the aggregated /47 prefix, o= r larger, in a way similar to the current text.

Th= anks

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommun= ication Services
Office of Information Technology
University of Minne= sota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-995= 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a1149993afbf5bb053e32ec36-- From nobody Thu Oct 6 07:25:19 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 A71AC129678 for ; Thu, 6 Oct 2016 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.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 ZLKe4mzH9JJn for ; Thu, 6 Oct 2016 07:25:15 -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 479C6129638 for ; Thu, 6 Oct 2016 07:25:15 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=39518 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 1bs9bl-0005fj-E7; Thu, 06 Oct 2016 16:25:13 +0200 Date: Thu, 6 Oct 2016 16:25:12 +0200 From: Tore Anderson To: Federico Santandrea , tore@fud.no Message-ID: <20161006162512.5f3dd210@echo.ms.redpill-linpro.com> In-Reply-To: <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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] 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, 06 Oct 2016 14:25:18 -0000 Hi again, * Federico Santandrea > What about keeping that sentence, but changing the reservation > request for Local-use IPv4/IPv6 Translation to actually be > 64:ff9b::/47 (instead of 64:ff9b:1::/48)? I disagree. That the newly reserved prefix encompassed the RFC6052 WKP was actually one of the things I didn't like about the previous version of the draft. RFC6052 reserves 64:ff9b::/96 and defines how it may and may not be used. This draft reserves a prefix that may be used in some circumstances 64:ff9b::/96 may not. So by having this draft reserve a prefix that encompasses 64:ff9b::/96, the draft must make an exception out of 64:ff9b::/96 (or it would need to update RFC6052 so that the same rules apply for the entire /47). Neither of the options is particularly appealing. Thus I'd like to let the RFC6052 WKP stay as it is without having this draft attempt to enroach on RFC6052's turf, so to speak. > This way it would be really true that the two can be aggregated, and > the extra addresses that are not yet covered by neither RFC6052 or > the draft could then be used in the future by similar translation > techniques. Well, actually, it could not. If this draft grabbed all of 64:ff9b::/47, then any new translation technique that wants a dedicated WKP similar to RFC6052 would need to grab a prefix from outside of 64:ff9b::/47 (or it would need to update this draft and change the rules of how 64:ff9b::/47, or subsets of it, may and may not be used.) By leaving the space between 64:ff9b::/96 and 64:ff9b:1::/48 unallocated, a new draft that wants an WKP has the possibility to ask the IANA for a new prefix from that range (assuming it can fit, i.e., that the desired prefix is a /49 or smaller). That said, the reservation made in this draft is on purpose made generic enough so that an operator will be permitted to use 64:ff9b:1::/48 for any new translation technique that might show up in the future (assuming that doesn't come in conflict with something about the new technique itself of course). Tore From nobody Thu Oct 6 09:15:56 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 EAA8A1296FE for ; Thu, 6 Oct 2016 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 bt7eurmX2nFw for ; Thu, 6 Oct 2016 09:15:53 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F5B129493 for ; Thu, 6 Oct 2016 09:15:53 -0700 (PDT) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 432311720D3; Thu, 6 Oct 2016 18:15:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id J1xM2Y5TC3w0; Thu, 6 Oct 2016 18:15:50 +0200 (CEST) X-Originating-IP: 10.58.1.150 Received: from webmail.eu.com (webmail10-d.mgt.gandi.net [10.58.1.150]) (Authenticated sender: federico@xylant.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id ACCC01720A1; Thu, 6 Oct 2016 18:15:50 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Oct 2016 18:15:50 +0200 From: Federico Santandrea To: Tore Anderson In-Reply-To: <20161006162512.5f3dd210@echo.ms.redpill-linpro.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> <20161006162512.5f3dd210@echo.ms.redpill-linpro.com> Message-ID: X-Sender: federico@xylant.net User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] 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, 06 Oct 2016 16:15:55 -0000 On 2016-10-06 16:25, Tore Anderson wrote: > This draft reserves a prefix that may be used in some circumstances > 64:ff9b::/96 may not. > > So by having this draft reserve a prefix that encompasses 64:ff9b::/96, > the draft must make an exception out of 64:ff9b::/96 (or it would need > to update RFC6052 so that the same rules apply for the entire /47). > Neither of the options is particularly appealing. > > Thus I'd like to let the RFC6052 WKP stay as it is without having this > draft attempt to enroach on RFC6052's turf, so to speak. You are right, having two separate blocks is better than having to make modifications of that kind. I am convinced on this one. -- Federico From nobody Thu Oct 6 09:26:59 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 8AF971296F9 for ; Thu, 6 Oct 2016 09:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.317 X-Spam-Level: X-Spam-Status: No, score=-7.317 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 AlDKlYDYMTbu for ; Thu, 6 Oct 2016 09:26:56 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEBD1296CF for ; Thu, 6 Oct 2016 09:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1475771213; x=2339684813; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Rk01K69fhLoJ+krqVIXt1YwfssD0+fpGEBJ2jT8Fd6M=; b=T4CRY4DdSiILK7ti0KcFw1o220TxfRR/7RsB/opoRseiugzqm36i5+FVXciJzyxT lrYKZ8Cu/HSBUHvG0n6eaYGzS20Hl/r9Zfp9GNyvlzWRlLOfDYtUXX0TMcThC6aZ eYK7Z6CvcHtB9bc9N7dmQOoFSj3SZwuLI5d2NyKf7VDaOPtgKnSVhcjsVIkO87ow Pk6cXDHs915O7QL8k7Oy8Zs7+L1UJv9ePvUbbjsunpGBPsguxIFp2fNuW7Eyysjs YsCVN5z4GuHqVojQnsmeZTHYKHWAwQE8AnzK8977ZKV9WLx4Goff+RRqAp5F67MC fIc0zoYGJ6aNmBUDswTiFg==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id D8.37.09044.D4B76F75; Thu, 6 Oct 2016 17:26:53 +0100 (BST) X-AuditID: 1148940c-f798c6d000002354-c7-57f67b4d125a Received: from phonehome2 ( [17.72.133.82]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 48.16.22244.D4B76F75; Thu, 6 Oct 2016 17:26:53 +0100 (BST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from uklon5-asavpn-l2tp-17-78-211-180.euro.apple.com (uklon5-asavpn-l2tp-17-78-211-180.euro.apple.com [17.78.211.180]) by phonehome2.euro.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OEM00KTOWCMZ970@phonehome2.euro.apple.com> for v6ops@ietf.org; Thu, 06 Oct 2016 17:26:53 +0100 (IST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Thu, 06 Oct 2016 09:26:44 -0700 Message-id: <071EF91A-A265-4C72-A9AF-73F0F5851B6E@apple.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> <20161006162512.5f3dd210@echo.ms.redpill-linpro.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi6GTOo+tb/S3cYHGXqsXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WTTIfaC47wV3a0qDYyfuLoYOTkkBEwkVq74yQZhi0lcuLce yObiEBJYxyRxfPpvVpiidxe+skIkVjBKHL17hhEkwSsgKPFj8j2WLkYODmYBeYmD52VBwswC WhLfH7WyQNS/ZpJ4f/cjC0hCWEBaouvCXVYI20pi2Z2ljCC9bEANB9YYgYQ5gcIzNjSDHcQi oCpxrfs21CobiT/7pkDNPMok8eXPFbCEiICQxI5nTUwQh8pKPDm5CKxIQuArq8SHltWsExiF ZyG5dRbCrbOQ3LqAkXkVo3huYmaObmaekV5qaVG+XmJBQU6qXnJ+7iZGUDh7TOHZwXjxoOEh RgEORiUe3jO538KFWBPLiitzDzFKcDArifCerAQK8aYkVlalFuXHF5XmpBYfYpTmYFES541+ +TpcSCA9sSQ1OzW1ILUIJsvEwSnVwFiyduuU3xsOi6i2Lqv7pumUxmhgWJCaZvX8Y69nhU7w bmE79+a1FnPPrvZ/IhhfWhdev7v1+p3L+w0/Prf5U7LOfIevEHshz0I24eVvA74VMU7OZLGx 2eFedvb4xudz7FckPeZuDihf/P73uZQvgin/tvr4ez4w9Dv9X/KqVIZ0xF1fi4vpu5VYijMS DbWYi4oTAbq61ONjAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi6NEapOtb/S3coLldxuL0sb3MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeLLpEHvBcd6K7laVBsZPXF2MnBwSAiYS7y58ZYWwxSQu3FvP 1sXIxSEksIJR4ujdM4wgCV4BQYkfk++xdDFycDALyEscPC8LEmYW0JL4/qiVBaL+NZPE+7sf WUASwgLSEl0X7rJC2FYSy+4sZQTpZQNqOLDGCCTMCRSesaGZDcRmEVCVuNZ9G2qVjcSffVOg Zh5lkvjy5wpYQkRASGLHsyYmiENlJZ6cXMQygVFgFpLzZiGcNwvJeQsYmVcxihal5iRWGuml lhbl6yUWFOSk6iXn525iBIWfkznPDsZXBw0PMQpwMCrx8LbnfwsXYk0sK67MPcQowcGsJMJ7 shIoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNfvgHa4kEB6YklqdmpqQWoRTJaJg1OqgVHWNPmW uU1RTfi+5cIflyyTOHNklZTLwZ1Pbbs3lbHNO375hel+/dct8j17CgWqupl+6x1lCczrnl9g 8lTkk5Puh59Wbqt63Vf4z3T5KXvkzJ7tvHcsrl84+a5G4udz6/qYBfO7osz7thh0rpw9yeNF q8AWoYMqGXPTTvJ68wu//+nVvNJxabkSS3FGoqEWc1FxIgDUgw6tOwIAAA== Archived-At: Subject: Re: [v6ops] 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, 06 Oct 2016 16:26:58 -0000 Hi, I've read the updated draft (-02) and like it much more than the original. I think the discussion that happened in this thread about why the new prefix does not encompass the WKP is valuable and should be added to the document. I also have a question about the interaction between this and RFC 6052. It is my understanding that the rationale for not allowing the WKP to translate RFC1918 space was that the WKP is domain-specific. The new prefix is also domain-specific, and has similar rules to the WKP with regards to inter-domain routing. For this reason I think this document should discuss if translating RFC1918 addresses is allowed or not. If a NAT64 is configured with prefix 64:ff9b:1:fffe::/96, is it allowed to translate 10.0.0.1? Thanks, David > On Oct 6, 2016, at 09:15, Federico Santandrea wrote: > > On 2016-10-06 16:25, Tore Anderson wrote: >> This draft reserves a prefix that may be used in some circumstances >> 64:ff9b::/96 may not. >> So by having this draft reserve a prefix that encompasses 64:ff9b::/96, >> the draft must make an exception out of 64:ff9b::/96 (or it would need >> to update RFC6052 so that the same rules apply for the entire /47). >> Neither of the options is particularly appealing. >> Thus I'd like to let the RFC6052 WKP stay as it is without having this >> draft attempt to enroach on RFC6052's turf, so to speak. > > You are right, having two separate blocks is better than having to make > modifications of that kind. > > I am convinced on this one. > > -- > Federico > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 6 22:25:14 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 EE06A1296CB for ; Thu, 6 Oct 2016 22:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 T_2TdrWHH5rS for ; Thu, 6 Oct 2016 22:25:08 -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 9FC51127058 for ; Thu, 6 Oct 2016 22:19:00 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=44528 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 1bsNYg-0003LH-7H; Fri, 07 Oct 2016 07:18:58 +0200 Date: Fri, 7 Oct 2016 07:18:57 +0200 From: Tore Anderson To: David Farmer Message-ID: <20161007071857.363a99aa@echo.ms.redpill-linpro.com> In-Reply-To: References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] 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, 07 Oct 2016 05:25:11 -0000 * David Farmer > I'm fine with anything up to a /32 begin reserved for v4v6 xlate > purposes in the most general sense, overall this purpose easily > justifies at least the default allocation we make to an ISP. Noted. I suppose this I could simply poll the WG about this. Perfect bike-shedding opportunity! Some possible options: * 64::/32 - easiest for human eyes and memory * 64::/48 - as above, but sized more stingily * 64:ff9a::/32 - adjacent to RFC6052 WKP (would make 64:ff9a:: -- 64:ff9b::ffff:ffff a continuous range of IPv4/IPv6 translation addresses with no holes) and allows covering both prefixes (plus some unallocated space) by shortening the prefix by only 1 bit (64:ff9a::/31). * 64:ff9a:ffff::/48 - more stingy option adjacent to WKP (64:ff9a:ffff:: -- 64:ff9b::ffff:ffff would be a continous range) * 64:ff9b:1::/48 - more stingy option that is as adjacent to the RFC6052 WKP as possible while allowing for a covering aggregate by shortening prefix by only 1 bit (64:ff9b::/47). Also possibly slightly more recognisable than the others for human eyes due to it having the same 32 most significant bits as the WKP. I don't really have a strong opinion - I'd just like to have *a* prefix for this purpose, regardless of its actual value. But if I could choose freely I'd probably take 64::/32 for the sake of my colleauges who'd regularly encounter these addresses in logs and ACLs and so on. How about you - any preference? > My recommendation is it keep what I view as the intent of the current > text and simply reserve the whole /47, or larger, for generalized > v4v6 xlate purposes, but further reserving the space beyond > 64:ff9b:1::/48 for future designated purposes, such as additional > WKPs, etc... Allowing the use of 64:ff9b:1::/48 as currently > specified in detail, but allowing use of the aggregated /47 prefix, > or larger, in a way similar to the current text. Honestly I think this would complicate the draft needlessly. If I understand you correctly it would make the draft do three distinct things: 1) Reserve 64:ff9b:1::/48 for local use translation (as the draft currently does and is what I'm really trying to accomplish). 2) Reserve the range 64:ff9b::1:0:0 - 64:ff9b:ffff:ffff:ffff:ffff:ffff:ffff (or 64:ff9b::1:0:0/96, 64:ff9b::2:0:0/95, ..., 64:ff9b:8000::/49 if you prefer) for future standards track action regarding IPv4/IPv6 translation. 3) Start out by saying something about 64:ff9b::/96 but then do a 180 and clarify that it doesn't really say anything about 64:ff9b::/96 after all. I'd prefer for my drafts to avoid "feature bloat", and instead focus on doing just one thing and do that well. (That would be #1.) Second, is it really any point in reserving the range in #2 specifically? It is already marked =C2=ABReserved by IETF=C2=BB (RFC4291 se= ction 4) in the IANA registry. Point #2 would add that it's for IPv4/IPv6 translation, but is that really necessary? To me it seems extremely unlikely that some other IETF draft (not related to IPv4/IPv6 translation) will ask for a reservation from this specific range anyway. Tore From nobody Thu Oct 6 22:30:31 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 BC4F8129513 for ; Thu, 6 Oct 2016 22:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.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 nTvzr2wjMHi4 for ; Thu, 6 Oct 2016 22:30:28 -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 8E4D0127058 for ; Thu, 6 Oct 2016 22:30:28 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=44584 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 1bsNjm-0003eQ-LX; Fri, 07 Oct 2016 07:30:26 +0200 Date: Fri, 7 Oct 2016 07:30:26 +0200 From: Tore Anderson To: David Schinazi Message-ID: <20161007073026.36675479@echo.ms.redpill-linpro.com> In-Reply-To: <071EF91A-A265-4C72-A9AF-73F0F5851B6E@apple.com> References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> <0be8791a-6b93-4ddf-95c6-ffa3197a67e7@typeapp.com> <20161006162512.5f3dd210@echo.ms.redpill-linpro.com> <071EF91A-A265-4C72-A9AF-73F0F5851B6E@apple.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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] 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, 07 Oct 2016 05:30:30 -0000 Hi David, * David Schinazi > I've read the updated draft (-02) and like it much more than the > original. I think the discussion that happened in this thread about > why the new prefix does not encompass the WKP is valuable and should > be added to the document. Thanks, and noted. > I also have a question about the interaction between this and > RFC 6052. It is my understanding that the rationale for not allowing > the WKP to translate RFC1918 space was that the WKP is > domain-specific. The new prefix is also domain-specific, and has > similar rules to the WKP with regards to inter-domain routing. For > this reason I think this document should discuss if translating > RFC1918 addresses is allowed or not. If a NAT64 is configured with > prefix 64:ff9b:1:fffe::/96, is it allowed to translate 10.0.0.1? There is actually no interaction between this prefix and the RFC6052 WKP at all, beyond the fact that overcoming certain limitations of the RFC6052 WKP is a key motivation for this draft. One of those limitations is the limited size (the WKP only allows for a single translation system in a network), another is the inability to use the WKP in combination with RFC1918 space. Due to the ongoing IPv4 exhaustion and IPv6 deployment organisations might well find themselves in a situation where they have both some kind of RFC1918 IPv4-only services in their network, as well as some IPv6-only clients that need to access to those services. That can't be done using the RFC6052 WKP, while the prefix reserved by this draft would facilitate such communication. So to answer your question: yes, a NAT64 configured with 64:ff9b:1:fffe::/96 would indeed be allowed to translate 10.0.0.1. I will make sure to point this out explicitly in the next revision. Thanks again! Tore From nobody Fri Oct 7 02:56:05 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 25C61129546 for ; Fri, 7 Oct 2016 02:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.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 uTacVf7ceD3u for ; Fri, 7 Oct 2016 02:56:01 -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 540C312953D for ; Fri, 7 Oct 2016 02:56:00 -0700 (PDT) Received: (qmail 1299 messnum 8162672 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 7 Oct 2016 09:55:59 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (HELO avas01) (213.94.190.12) by mta00.svc.cra.dublin.eircom.net (qp 1299) with SMTP; 7 Oct 2016 09:55:59 -0000 Received: from hal.eng.eircom.net ([159.134.250.228]) by Cloudmark Gateway with SMTP id sRslb66BdEJD1sRslbDIpa; Fri, 07 Oct 2016 10:55:59 +0100 X-CNFS-Analysis: v=2.1 cv=MazMw8Lf c=1 sm=1 tr=0 a=iSt2eTQ4I4t0f/HYKsKvhw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=FwSwkvR64UxiUlSoA-QA:9 a=QEXdDO2ut3YA:10 a=chvjmp5bT-K0Np4W8Gpx:22 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 $3226$) From: Ross Chandler In-Reply-To: <20161007071857.363a99aa@echo.ms.redpill-linpro.com> Date: Fri, 7 Oct 2016 10:52:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D6D21CC-DFAC-4AF7-B9D9-388DEBFB5A5A@asgard.org> <1c151ee9-6919-4ec4-abd2-4129dd848065@typeapp.com> <20161006152129.27e96d62@echo.ms.redpill-linpro.com> <20161007071857.363a99aa@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.3226) X-CMAE-Envelope: MS4wfHjY3Zzb/bOTmT9Kk8MekezVttXpfnhTo5Kdq4nJGPlafcEs/mbmFpRRgsmBQ8DGq9XTAbL4ZPsozYUE2pUCqaEu2+tGv3wo0SJRICt4ikdUZZoxKVyu yTv/HqN5X0FrruJ07+wbQUOgkUt1wGEzq0op01CJ7vUcdZufEo1D7nBUg2o2icQWx7ZtRNVcEcp4zQ== Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] 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, 07 Oct 2016 09:56:03 -0000 > On 7 Oct 2016, at 06:18, Tore Anderson wrote: >=20 > Noted. I suppose this I could simply poll the WG about this. Perfect > bike-shedding opportunity! Some possible options: >=20 > * 64::/32 - easiest for human eyes and memory >=20 > * 64::/48 - as above, but sized more stingily >=20 etc. >=20 > 1) Reserve 64:ff9b:1::/48 for local use translation (as the draft > currently does and is what I=E2=80=99m really trying to accomplish). Maintaining the 64:ff9b base would make it more unambiguously = identifiable as a translation prefix when glancing at prefix lists. 64:ff9b:1::/48 seems like the best choice. Ross From nobody Fri Oct 14 12:22:11 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 3704C1298A1; Fri, 14 Oct 2016 12:22:10 -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.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 12:22:10 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.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, 14 Oct 2016 19:22:10 -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 : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-10.txt Pages : 22 Date : 2016-10-14 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-10 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 Fri Oct 14 12:27: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 2D4761298AA for ; Fri, 14 Oct 2016 12:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 fx3UvviugohR for ; Fri, 14 Oct 2016 12:26:57 -0700 (PDT) Received: from tor-smtp-01.primus.ca (smtp-auth2-92.primus.ca [209.183.31.92]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3912947B for ; Fri, 14 Oct 2016 12:26:57 -0700 (PDT) Received: from [24.114.81.7] (helo=[172.20.10.4]) by tor-smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bv888-0003KO-R7; Fri, 14 Oct 2016 15:26:57 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 15:26:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.81.7] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 14 Oct 2016 19:26:59 -0000 Folks: After a long delay due to demands of $DAYJOB, we are finally back to = working on this I-D. Here is a summary of the major changes: * Section 2.1 ("Addresses"). This section was very contentious in = Yokohama (yes, it was that long ago ...). We have been discussing what = to do with this, but have not come to any conclusions yet, so for now we = have removed the old contents and just put "TBD". * Section 2.3 ("IGPs"). Some significant changes here. First, we added = an IPv6-centric comparison of OSPF, IS-IS, and EIGRP. We just list = similarities and differences, without making recommendations. We think = this helps give better context before we discuss our survey of what = people have deployed. We also added more facts around single-topology = vs. multi-topology for IS-IS, and reworded the section discussing RIP = and RIPng. * Various minor changes: updated the year, affiliation, etc. We are still discussing what, if anything, we should say in the = addressing section. It is hard to say something here that is insightful = without causing some people to take offense. Comments welcome. - Philip and Victor On 2016-10-14, at 15:22 , Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-10.txt > Pages : 22 > Date : 2016-10-14 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-10 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Oct 16 15:15: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 395EE129428 for ; Sun, 16 Oct 2016 15:15:25 -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 4DISS29wGdIG for ; Sun, 16 Oct 2016 15:15:23 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 4E55B1279EB for ; Sun, 16 Oct 2016 15:15:23 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 128so71402199pfz.0 for ; Sun, 16 Oct 2016 15:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9JDAgTZ3RaGND56+1HGSXHnygR4GzxJCLtiRdgO/HZs=; b=KUrIJKwLgZ0uYliZsYAXL0/+cDR8NoA1+k/ovaCtwsO0a29EU559c7SAf8EKbQs1fi p/EbWcIEx7ay3A+1p9nYSuf5iFezwSip3Lta4glfiANt7dct5bz511URSi4CIkZGpIOH 8UZBnFK7U17eWQ9bimWjNzIaQYEUtFGjNrE69nfsNW28FGgNamp6JuGHP4HBuRfwmfTI 9lH8EUGcyupH2pp/up3aE4PVZ14wksIOsbuRyVjdajeVPi0Axu7ajrgbmRYw+ohIqYEh Z0fXQHQcWfi3lk3MMR8ZzSJgMHdzQRyPNG3a34W0r/KkvjPezXS+ZeAsIcNfaRUoM1p+ 8Hug== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9JDAgTZ3RaGND56+1HGSXHnygR4GzxJCLtiRdgO/HZs=; b=CAxLbGwa0TeQz5CM3/kpDHKSovB2uqPl0UFNq1cjBHuETp4O/vdROg6bE3SNq/xcf/ U6X5xEfgoP7eqT1jHXD9KF8/omj0c/O5cy68U+vuvAC9GVwR+c47JNHU2uySCN9nxtMl 4NhZ86sxP8KtwKuBY3R+Kt4snAzimod0cV3x4h4hOJN/B27HxHIQKIf9FfKndlL9ayRn ZXLLf4xaiMA6g29I0CjMoSNSpUWXonPDRAMI/Zbe7eMmlAvUz17R4PPnA+qTm2/QiISE qyxwCepPF+rw7xfD4IbRsU0O/MtOdaNMgK9i7xEE1tlJGH9TAfvmHarmmRqAvGWWXPsL Y9Ig== X-Gm-Message-State: AA6/9RljXWXWkLfudUO6nseCwtIi/RSanckwdxHddgYrH9K0Y4yxkFUUUv9cJaHlnQLX3w== X-Received: by 10.98.205.207 with SMTP id o198mr33085094pfg.114.1476656122818; Sun, 16 Oct 2016 15:15:22 -0700 (PDT) Received: from [192.168.178.23] (96.23.255.123.dynamic.snap.net.nz. [123.255.23.96]) by smtp.gmail.com with ESMTPSA id z11sm28552810pfd.49.2016.10.16.15.15.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Oct 2016 15:15:22 -0700 (PDT) To: Philip Matthews , v6ops list References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <678a45f0-cb10-1d50-2768-32f2fc2d813d@gmail.com> Date: Mon, 17 Oct 2016 11:15:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 16 Oct 2016 22:15:25 -0000 On 15/10/2016 08:26, Philip Matthews wrote: ... > We are still discussing what, if anything, we should say in the addressing section. It is hard to say something here that is insightful without causing some people to take offense. I think you have to aim for a very neutral tone in this section, presenting the options and their properties, but avoiding any kind of opinion and judgment calls such as the word "Works" or the phrases "likely a better option" or "poor option". In the Introduction you say " The design choices presented apply to both Service Provider and Enterprise network environments. Where choices have selection criteria which differ between the Service Provider and the Enterprise environment, this is noted." I think that approach is dubious for the addressing section. I suggest splitting it in three parts: overview, ISP, enterprise. (For enterprises, I stand by https://tools.ietf.org/html/rfc6883#section-5.1 ) It's also worth underlining that SOHO is not the same and will certainly not have the luxury of PI. Also go very carefully on the terminology. In particular - please make a very careful distinction between "global scope" (which applies to PA, PI and ULA) and "globally routed" (which applies to PA, PI but not ULA). I think it's a distraction to use the phrase "globally unique". - don't even mention RFC1918. It's confusing and irrelevant in an IPv6 document. IPv6 is *different*. - don't describe ULAs as "private". It's not even accurate to call them site-local, because they might be more local than that. Perhaps the best word is "local" actually, which is after all their name. All that said, I think the basic coverage of the previous addressing section was correct and necessary. Regards Brian From nobody Mon Oct 17 05:46: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 D114712964D for ; Mon, 17 Oct 2016 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 cntqxEC1VFaR for ; Mon, 17 Oct 2016 05:46:35 -0700 (PDT) Received: from tor-smtp-01.primus.ca (smtp-auth2-94.primus.ca [209.183.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5564B12964B for ; Mon, 17 Oct 2016 05:46:35 -0700 (PDT) Received: from rrcs-64-183-179-246.sw.biz.rr.com ([64.183.179.246] helo=[10.248.38.132]) by tor-smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bw7JK-0004i3-6v; Mon, 17 Oct 2016 08:46:34 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <678a45f0-cb10-1d50-2768-32f2fc2d813d@gmail.com> Date: Mon, 17 Oct 2016 08:46:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E5572C5-B4CF-40DE-888A-0ED645B7C89D@magma.ca> References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> <678a45f0-cb10-1d50-2768-32f2fc2d813d@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - rrcs-64-183-179-246.sw.biz.rr.com ([10.248.38.132]) [64.183.179.246] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 17 Oct 2016 12:46:37 -0000 Thanks for the suggestions. Victor and I agree that the previous = version of the section was not neutral enough in many places. To me, this document is about saying things that are not already covered = in lots of other RFCs. This is the part that I am struggling with when = it comes to the Address section. One idea we are considering is to just = put in a few pointers to other documents and leave it at that. Will keep your other suggestions in mind as we decide what to do. - Philip On 2016-10-16, at 18:15 , Brian E Carpenter wrote: > On 15/10/2016 08:26, Philip Matthews wrote: >=20 > ... >> We are still discussing what, if anything, we should say in the = addressing section. It is hard to say something here that is insightful = without causing some people to take offense. >=20 > I think you have to aim for a very neutral tone in this section, = presenting the > options and their properties, but avoiding any kind of opinion and = judgment calls > such as the word "Works" or the phrases "likely a better option" or = "poor option". >=20 > In the Introduction you say > " The design choices presented apply to both Service Provider and > Enterprise network environments. Where choices have selection > criteria which differ between the Service Provider and the = Enterprise > environment, this is noted." >=20 > I think that approach is dubious for the addressing section. I suggest = splitting > it in three parts: overview, ISP, enterprise. (For enterprises, I = stand by > https://tools.ietf.org/html/rfc6883#section-5.1 ) It's also worth = underlining > that SOHO is not the same and will certainly not have the luxury of = PI. >=20 > Also go very carefully on the terminology. In particular >=20 > - please make a very careful distinction between "global scope" (which = applies > to PA, PI and ULA) and "globally routed" (which applies to PA, PI but = not ULA). > I think it's a distraction to use the phrase "globally unique". >=20 > - don't even mention RFC1918. It's confusing and irrelevant in an IPv6 = document. > IPv6 is *different*. >=20 > - don't describe ULAs as "private". It's not even accurate to call = them site-local, > because they might be more local than that. Perhaps the best word is = "local" > actually, which is after all their name. >=20 > All that said, I think the basic coverage of the previous addressing = section was correct and > necessary. >=20 > Regards > Brian >=20 From nobody Mon Oct 17 13:34:59 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 351111295A5 for ; Mon, 17 Oct 2016 13:34:58 -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 (2048-bit key) header.d=monash.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 JL6fqPQaFIqJ for ; Mon, 17 Oct 2016 13:34:55 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 68FD212940F for ; Mon, 17 Oct 2016 13:34:55 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n189so257325233qke.0 for ; Mon, 17 Oct 2016 13:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monash.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iSV99H/U5HFTiBYn8a4DszWhEuv0k9BRF7n4vQY6LYQ=; b=YfyNYGkWZWrhLGUJxM3ol9F9UnRYSQL65J/YZuQpUucDTp5pRnVXljR9nuqE7limiu NfgZ51R+OPykuq3B4KcGl7GsA+KDYGCFXbwoFzNj2Fr3RjInjNi3cB7m4y9RbvJXyqRs 21GAU2P78DLpGJNNVD7Od424vzgSPTSE5sXYfXy3qO2FeWw/RA3yS1hzo4bTKKWhZHOg Ds1opJoQZfpz5maXf+GoeFm6eGxBXVJI8IefZ8OdkPwtXCzyLsT5zQp0i08/ZKgA4MxS jrKuMDX3gx52orQChKO16zbP3rNbKJserYNUd5nneXTE0LFuNiqVr1p3Rlg8EdNwHedK JE0A== 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=iSV99H/U5HFTiBYn8a4DszWhEuv0k9BRF7n4vQY6LYQ=; b=a1nxS3yyEjhzW9R74Ek3p8U0VAISOUY7yDs1hCSlqT0IxjRQjMZkPlsj5dcNEiA3yZ /heo5ChXm56g+M2uEMCwVZbiAMDU9V/kihWLo8R0Hsa1BloDp3XeJ80ZHmv2eV9eLnpy LrB8Y1RBC8COGgx1pxmSBa0A5/nZzY44UJZIOgWJF/xfPxFf+WQqu2bzbklWGJGYumQt bqsR4jlo1O7OKUw7dER63rsZCaEAcpIv6TjpmcVX5LEl+1KXYRxBqb6sQikHA8t4DSbY 1w1xhPp9KWB0Vc6xKMxsYNX5KY+qmU032SuohjR5bx0BCHxfhcNOeQSVLKGK/A8ZF218 e0pw== X-Gm-Message-State: AA6/9RnVw9SaeJM9ivpBT3pPbN1c5yq9aQZJjB5nctdZfXTS2lVe+LxG/xPalvacdIsP2Hfuc6AhVU44QtS1xXFq X-Received: by 10.55.100.150 with SMTP id y144mr24999259qkb.281.1476736494405; Mon, 17 Oct 2016 13:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.54.207 with HTTP; Mon, 17 Oct 2016 13:34:33 -0700 (PDT) In-Reply-To: <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> From: John Mann Date: Tue, 18 Oct 2016 07:34:33 +1100 Message-ID: To: Philip Matthews Content-Type: multipart/alternative; boundary=94eb2c05e6762d49db053f15824f Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 17 Oct 2016 20:34:58 -0000 --94eb2c05e6762d49db053f15824f Content-Type: text/plain; charset=UTF-8 Hi, On 15 October 2016 at 06:26, Philip Matthews wrote: > Folks: > > After a long delay due to demands of $DAYJOB, we are finally back to > working on this I-D. > > Here is a summary of the major changes: > * Section 2.1 ("Addresses"). This section was very contentious in > Yokohama (yes, it was that long ago ...). We have been discussing what to > do with this, but have not come to any conclusions yet, so for now we have > removed the old contents and just put "TBD". > * Section 2.3 ("IGPs"). Some significant changes here. First, we added an > IPv6-centric comparison of OSPF, IS-IS, and EIGRP. We just list > similarities and differences, without making recommendations. We think this > helps give better context before we discuss our survey of what people have > deployed. We also added more facts around single-topology vs. > multi-topology for IS-IS, and reworded the section discussing RIP and RIPng. > The discussion included, but the table excluded Use OSPFv3 running over IPv6 for routing both IPv4 and IPv6 Is it worthwhile referencing RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network as an example of the minimal amount of IPv6 interface configuration required to support an IGP? * Various minor changes: updated the year, affiliation, etc. > > ietf-v6ops-host-addr-availability > Cerf, D. (sic) Is now RFC 7934. s/draft-ietf-v6ops-ula-usage-recommendations/draft-ietf-v6ops-ula-usage-considerations/ Thanks, John We are still discussing what, if anything, we should say in the addressing > section. It is hard to say something here that is insightful without > causing some people to take offense. > > Comments welcome. > > - Philip and Victor > > > > On 2016-10-14, at 15:22 , Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations of the IETF. > > > > Title : Some Design Choices for IPv6 Networks > > Authors : Philip Matthews > > Victor Kuarsingh > > Filename : draft-ietf-v6ops-design-choices-10.txt > > Pages : 22 > > Date : 2016-10-14 > > > > Abstract: > > This document presents advice on certain routing-related design > > choices that arise when designing IPv6 networks (both dual-stack and > > IPv6-only). The intended audience is someone designing an IPv6 > > network who is knowledgeable about best current practices around IPv4 > > network design, and wishes to learn the corresponding practices for > > IPv6. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-10 > > > > > > 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/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- *John Mann* Network Architect, Infrastructure Automation & Delivery *Infrastructure Services, eSolutions* Monash University 738 Blackburn Road Clayton VIC 3168 Australia T: +61 3 9905 4774 M: +61 419 568 470 E: john.mann@monash.edu W: monash.edu --94eb2c05e6762d49db053f15824f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 15 October 2016 at 06:26, Philip Matthews <philip_matthews@ma= gma.ca> wrote:

Folks:

After a long delay due to demands of $DAYJOB, we are finally back to workin= g on this I-D.

Here is a summary of the major changes:
* Section 2.1 ("Addresses").=C2=A0 This section was very contenti= ous in Yokohama (yes, it was that long ago ...). We have been discussing wh= at to do with this, but have not come to any conclusions yet, so for now we= have removed the old contents and just put "TBD".
* Section 2.3 ("IGPs"). Some significant changes here. First, we = added an IPv6-centric comparison of OSPF, IS-IS, and EIGRP.=C2=A0 We just l= ist similarities and differences, without making recommendations. We think = this helps give better context before we discuss our survey of what people = have deployed.=C2=A0 We also added more facts around single-topology vs. mu= lti-topology for IS-IS, and reworded the section discussing RIP and RIPng.<= br>

The discussion included, but the table = excluded=C2=A0

=C2=A0 =C2=A0Use OSPFv3 running over IPv6 for rout= ing both IPv4 and IPv6

Is it worthwhile referencin= g RFC 7404

=C2=A0 Using Only Link-Local Addressing inside an IPv6= Network

as an example of the minimal amount of IPv6 interface co= nfiguration required to support an IGP?

* Various minor changes: updated the year, affiliation, etc.

>=C2=A0ietf-v6ops-host-addr-availabi= lity
> Cerf, D. (sic)

Is now RFC 7= 934.

s/draft-ietf-v6ops-ula-usage-recommendati= ons/draft-ietf-v6ops-ula-usage-considerations/

Tha= nks,
=C2=A0 =C2=A0 John

We are still discussing what, if anything, we should say in the addressing = section.=C2=A0 It is hard to say something here that is insightful without = causing some people to take offense.

Comments welcome.

- Philip and Victor

On 2016-10-14, at 15:22 , Inter= net-Drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Some Design Choices for IPv6 Networks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Philip Matthews
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Victor Kuarsingh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-v6ops-design-choices-10.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-10-14
>
> Abstract:
>=C2=A0 =C2=A0This document presents advice on certain routing-related d= esign
>=C2=A0 =C2=A0choices that arise when designing IPv6 networks (both dual= -stack and
>=C2=A0 =C2=A0IPv6-only).=C2=A0 The intended audience is someone designi= ng an IPv6
>=C2=A0 =C2=A0network who is knowledgeable about best current practices = around IPv4
>=C2=A0 =C2=A0network design, and wishes to learn the corresponding prac= tices for
>=C2=A0 =C2=A0IPv6.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/<= wbr>doc/draft-ietf-v6ops-design-choices/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/= draft-ietf-v6ops-design-choices-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-v6ops-design-choices-10
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
>

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

--
=

John Mann

Network Architect, Infrastructure Automation & Delivery

= Infrastructure Services, eSolutions
Monash University
738 Blackburn Road

Clayton VIC 3168

Australia

T: +61 3 9905 4774

M: +61 419 568 470

E: john.mann@monash.edu

W: monash.edu

--94eb2c05e6762d49db053f15824f-- From nobody Mon Oct 17 19:37:48 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 CB0B01294CC for ; Mon, 17 Oct 2016 19:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 MITRCe4YslAI for ; Mon, 17 Oct 2016 19:37:43 -0700 (PDT) Received: from tor-smtp-02.primus.ca (smtp-auth2-160.primus.ca [216.254.140.160]) by ietfa.amsl.com (Postfix) with ESMTP id 9604F129461 for ; Mon, 17 Oct 2016 19:37:43 -0700 (PDT) Received: from rrcs-64-183-179-246.sw.biz.rr.com ([64.183.179.246] helo=[10.248.38.12]) by tor-smtp-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bwKHd-0000aI-FA; Mon, 17 Oct 2016 22:37:42 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2-234776658 From: Philip Matthews In-Reply-To: Date: Mon, 17 Oct 2016 22:36:22 -0400 Message-Id: <112C765C-B9FB-4766-9EDD-5E462F7B8B61@magma.ca> References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> To: John Mann X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - rrcs-64-183-179-246.sw.biz.rr.com ([10.248.38.12]) [64.183.179.246] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 18 Oct 2016 02:37:46 -0000 --Apple-Mail-2-234776658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See inline. -Philip On 2016-10-17, at 16:34 , John Mann wrote: > Hi, >=20 > On 15 October 2016 at 06:26, Philip Matthews = wrote: > Folks: >=20 > After a long delay due to demands of $DAYJOB, we are finally back to = working on this I-D. >=20 > Here is a summary of the major changes: > * Section 2.1 ("Addresses"). This section was very contentious in = Yokohama (yes, it was that long ago ...). We have been discussing what = to do with this, but have not come to any conclusions yet, so for now we = have removed the old contents and just put "TBD". > * Section 2.3 ("IGPs"). Some significant changes here. First, we added = an IPv6-centric comparison of OSPF, IS-IS, and EIGRP. We just list = similarities and differences, without making recommendations. We think = this helps give better context before we discuss our survey of what = people have deployed. We also added more facts around single-topology = vs. multi-topology for IS-IS, and reworded the section discussing RIP = and RIPng. >=20 > The discussion included, but the table excluded=20 > Use OSPFv3 running over IPv6 for routing both IPv4 and IPv6 Good catch. Thought we had included this ... >=20 > Is it worthwhile referencing RFC 7404 > Using Only Link-Local Addressing inside an IPv6 Network > as an example of the minimal amount of IPv6 interface configuration = required to support an IGP? This is discussed, with a ref to 7404, in section 2.2.2. I am not totally happy with how we handle this discussion... it is a bit = confusing. >=20 > * Various minor changes: updated the year, affiliation, etc. >=20 > > ietf-v6ops-host-addr-availability > > Cerf, D. (sic) >=20 > Is now RFC 7934. >=20 > = s/draft-ietf-v6ops-ula-usage-recommendations/draft-ietf-v6ops-ula-usage-co= nsiderations/ Thanks. We need to update all our references. >=20 > Thanks, > John >=20 > We are still discussing what, if anything, we should say in the = addressing section. It is hard to say something here that is insightful = without causing some people to take offense. >=20 > Comments welcome. >=20 > - Philip and Victor >=20 >=20 >=20 > On 2016-10-14, at 15:22 , Internet-Drafts@ietf.org wrote: >=20 > > > > 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 : Some Design Choices for IPv6 Networks > > Authors : Philip Matthews > > Victor Kuarsingh > > Filename : draft-ietf-v6ops-design-choices-10.txt > > Pages : 22 > > Date : 2016-10-14 > > > > Abstract: > > This document presents advice on certain routing-related design > > choices that arise when designing IPv6 networks (both dual-stack = and > > IPv6-only). The intended audience is someone designing an IPv6 > > network who is knowledgeable about best current practices around = IPv4 > > network design, and wishes to learn the corresponding practices = for > > IPv6. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-10= > > > > > > 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/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > John Mann > Network Architect, Infrastructure Automation & Delivery >=20 > Infrastructure Services, eSolutions > Monash University > 738 Blackburn Road > Clayton VIC 3168 > Australia >=20 > T: +61 3 9905 4774 > M: +61 419 568 470 > E: john.mann@monash.edu > W: monash.edu --Apple-Mail-2-234776658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii See = inline.

-Philip

On 2016-10-17, at 16:34 , = John Mann wrote:

Hi,

On 15 October 2016 at 06:26, Philip Matthews <philip_matthews@magma.ca> = wrote:
Folks:

After a long delay due to demands of $DAYJOB, we are finally back to = working on this I-D.

Here is a summary of the major changes:
* Section 2.1 ("Addresses"). This section was very contentious in = Yokohama (yes, it was that long ago ...). We have been discussing what = to do with this, but have not come to any conclusions yet, so for now we = have removed the old contents and just put "TBD".
* Section 2.3 ("IGPs"). Some significant changes here. First, we added = an IPv6-centric comparison of OSPF, IS-IS, and EIGRP. We just list = similarities and differences, without making recommendations. We think = this helps give better context before we discuss our survey of what = people have deployed. We also added more facts around = single-topology vs. multi-topology for IS-IS, and reworded the section = discussing RIP and RIPng.

The = discussion included, but the table excluded
= Use OSPFv3 running over IPv6 for routing both IPv4 and = IPv6

Good catch. = Thought we had included this ...

Is it worthwhile referencing = RFC 7404
Using Only Link-Local Addressing inside an = IPv6 Network
as an example of the minimal amount of IPv6 = interface configuration required to support an = IGP?

This is = discussed, with a ref to 7404, in section 2.2.2.

I am not = totally happy with how we handle this discussion... it is a bit = confusing.

* Various minor changes: updated the year, affiliation, = etc.

> ietf-v6ops-host-addr-availability
> Cerf, D. (sic)

Is now = RFC 7934.

s/draft-ietf-v6ops-ula-usage-rec= ommendations/draft-ietf-v6ops-ula-usage-considerations/
<= /div>

Thanks. We need to update all our = references.

Thanks,
= John

We are still discussing what, if anything, we should say in the = addressing section. It is hard to say something here that is = insightful without causing some people to take offense.

Comments welcome.

- Philip and Victor

On 2016-10-14, at 15:22 , Internet-Drafts@ietf.org = wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the IPv6 Operations of the IETF.
>
> Title = : Some Design Choices for IPv6 Networks
> Authors = : Philip Matthews
> = Victor Kuarsingh
> Filename : = draft-ietf-v6ops-design-choices-10.txt
> Pages = : 22
> Date = : 2016-10-14
>
> Abstract:
> This document presents advice on certain = routing-related design
> choices that arise when designing IPv6 networks (both = dual-stack and
> IPv6-only). The intended audience is someone = designing an IPv6
> network who is knowledgeable about best current = practices around IPv4
> network design, and wishes to learn the corresponding = practices for
> IPv6.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-d= esign-choices/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-design= -choices-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6op= s-design-choices-10
>
>
> 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/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
= >

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

-- =
John Mann
Network Architect, = Infrastructure Automation & Delivery

Infrastructure = Services, eSolutions
Monash University
738 = Blackburn Road
Clayton VIC 3168
Australia

T: +61 3 9905 4774
M: +61 419 568 = 470
E: john.mann@monash.edu
W: monash.edu
=

= --Apple-Mail-2-234776658-- From nobody Mon Oct 17 21:09:31 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 DBB1A1294FA for ; Mon, 17 Oct 2016 21:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.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 cLK11UKnWtrR for ; Mon, 17 Oct 2016 21:09:29 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 92A2E1294F6 for ; Mon, 17 Oct 2016 21:09:29 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id k64so17600924itb.0 for ; Mon, 17 Oct 2016 21:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=RkSubWdAD0HUIHuZ29n45fLBVevIdo4NKCuumttCM1E=; b=kwLa1ZqHD7G6PCWxJF2/PUPcMqDOw8eNg5Byzi9heVHFimVKG6dVpyhKyTHYhTwGJH lTE6vw5gswvVm1Kk5LKhzRt9rWhpWnE+kjEG2ezH8hwZIzkeirRF4guWdLrPPs1GF59O Oc/xFFhoo0SynpLra8slUxXgX88DDlcS60yHuqbNgxd4HpqD4P2YiYen2SvM7ZCGHSOP ZrOtf2w1MrGq0AZxlWfsY4EjUxlwqELedpiA+V1vVNjv58keDAeoq+POfUVWiUFTw4FV MuQphWP6X4VdwMERgk2LBb47Sz1WeVA2oqWVinzQEKJRYDfyZwbyf9IyMzPRSzolsynq xhAg== 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:message-id:date :user-agent:mime-version:in-reply-to; bh=RkSubWdAD0HUIHuZ29n45fLBVevIdo4NKCuumttCM1E=; b=PvKFs99lGa5dhSoZKKB8by2lU4xk4d1a84xC5TmdPIuzVFndwqb1PB3v+FGw63hDRK pluJI+vD7YPFgRJlmuGesC0CNe085qoUUiXniPrK8UdcE9YOmEZst991IE/1l73sK94q Jy2j7GmDSJu4ViqXfDk2ObYOBlL5qv/AC96hK1PhYo9oN+QdXZpe9nqPm7IQWoiweUk8 Y+FGmAgeh2jn6yu+srqiUrnDm8CtlgaUw52QynF43cC4swSCcw1+rRkmkHXVhIIRBTAO 7AXNG9NJzUDAEBnuksmcehLv9jCH6M5i0SPEGm3Nv5CLr9WPSt4NJ+M49w1zxnktN5EW 23bA== X-Gm-Message-State: AA6/9RnsEZlwDCbAC0YQ83nulLS1DCHhcJ/9GxuMSy4LyEvTBuD5X48fWNuckP1T4rJPxA== X-Received: by 10.36.156.197 with SMTP id b188mr12467093ite.28.1476763768778; Mon, 17 Oct 2016 21:09:28 -0700 (PDT) Received: from [192.168.100.32] (CPE001319d6e9ab-CM84948c50c950.cpe.net.cable.rogers.com. [99.236.98.28]) by smtp.gmail.com with ESMTPSA id o144sm503141itc.8.2016.10.17.21.09.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 21:09:28 -0700 (PDT) To: Philip Matthews , John Mann References: <147647293021.18540.15349792079043351791.idtracker@ietfa.amsl.com> <5D21FF28-F280-4DB4-910D-9AC3ACD8E336@magma.ca> <112C765C-B9FB-4766-9EDD-5E462F7B8B61@magma.ca> From: Victor Kuarsingh Message-ID: Date: Tue, 18 Oct 2016 00:09:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <112C765C-B9FB-4766-9EDD-5E462F7B8B61@magma.ca> Content-Type: multipart/alternative; boundary="------------EBBE793C176FF58C450CE2EA" Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-10.txt 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, 18 Oct 2016 04:09:31 -0000 This is a multi-part message in MIME format. --------------EBBE793C176FF58C450CE2EA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Philip / John >> >> >> The discussion included, but the table excluded >> Use OSPFv3 running over IPv6 for routing both IPv4 and IPv6 > > Good catch. Thought we had included this ... > Interesting point. I went back over the data we collected when we polled the operator community on what IGP combinations were actually deployed into networks. That was a small sample size, and a over a year ago, however, at that time, no operator had reported that combination (i.e. running IPv4 and IPv6 over OSPFv3). However, I do agree that combination should be in the table as it's an option. I suspect as time goes on, an operator depending on IPv6 connectivity to ensure their IPv4 routing information being exchanged will become less of a concern (as is seemed to be a few years ago when operators were a bit more hesitant to make IPv4 rely on IPv6 for any reason). regards, Victor K --------------EBBE793C176FF58C450CE2EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Philip / John

The discussion included, but the table excluded�

� �Use OSPFv3 running over IPv6 for routing both IPv4 and IPv6

Good catch. Thought we had included this ...

Interesting point.

I went back over the data we collected when we polled the operator community on what IGP combinations were actually deployed into networks.� That was a small sample size, and a over a year ago, however, at that time, no operator had reported that combination (i.e. running IPv4 and IPv6 over OSPFv3).

However, I do agree that combination should be in the table as it's an option.� I suspect as time goes on, an operator depending on IPv6 connectivity to ensure their IPv4 routing information being exchanged will become less of a concern (as is seemed to be a few years ago when operators were a bit more hesitant to make IPv4 rely on IPv6 for any reason).

regards,

Victor K
--------------EBBE793C176FF58C450CE2EA-- From nobody Tue Oct 18 20:25: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 309F5129525 for ; Tue, 18 Oct 2016 20:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cht.com.tw 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 EMI_mSeiYb4Z for ; Tue, 18 Oct 2016 20:25:29 -0700 (PDT) Received: from scan13.cht.com.tw (scan13.cht.com.tw [202.39.160.143]) by ietfa.amsl.com (Postfix) with ESMTP id 02C77129499 for ; Tue, 18 Oct 2016 20:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=cht.com.tw; s=bill; c=relaxed/simple; q=dns/txt; i=@cht.com.tw; t=1476847517; x=1479439517; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Lj2eQAw53wISHdbaaAyEF/eIsqGeWp4il6d2aHT6nW4=; b=0Me13hYZ5I4WJ29MPmUMV/S122KRQYz6+nhcuNjiPlBs2w0J3xd0BP4e4f3XFvzc irMwDmhjE9MA9+w9ffA91NncafoNfig9esYgnJXoUC43Ps7GVqDW0dLtjybDRHjY Bj9ttZSYud6xab9V1uFPV0eYKnkLPuCghrZWhLIa6K0=; X-AuditID: 0aa00767-f79d86d000003301-5a-5806e79d3b77 Received: from scanrelay3.cht.com.tw ( [10.160.7.108]) by scan13.cht.com.tw (CHT Outgoing ESMTP Mail Server) with SMTP id 6B.3C.13057.D97E6085; Wed, 19 Oct 2016 11:25:17 +0800 (CST) Received: from email.cht.com.tw (unknown [10.172.18.168]) by scanrelay3.cht.com.tw (Symantec Mail Security) with ESMTP id B2AB4C000088 for ; Wed, 19 Oct 2016 11:25:17 +0800 (CST) Received: from MBS5.app.corp.cht.com.tw ([fe80::184b:2137:90a0:edaf]) by HUB4.app.corp.cht.com.tw ([fe80::f8db:4064:82dd:2fdb%12]) with mapi id 14.03.0266.001; Wed, 19 Oct 2016 11:24:59 +0800 From: =?big5?B?prar26Zw?= To: "v6ops@ietf.org" Thread-Topic: unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? Thread-Index: AdIpuCWjrD8RtLbwSDaRKG/n91S/IQ== Date: Wed, 19 Oct 2016 03:24:59 +0000 Message-ID: Accept-Language: zh-HK, zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.169.154] Content-Type: multipart/alternative; boundary="_000_FC3F3FB8661CA84586F51E0F5449356E0151E950F3mbs5appcorpch_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42LhWsCeozv3OVuEwaHVJhanj+1ldmD0WLLk J1MAY1QDo01iXl5+SWJJqkJKanGyrVJyRoluSmZxck5iZm5qkW5qXrqSQmaKrZKJkkJBTmJy am5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3VfIM9te1sDC11DVUsgvISU0sTlVI SlVITCnLLE5NUUjYIJPxueMxc8Ep2YrGBU1MDYwnpLoYOTkkBEwkVtzazAphi0lcuLeerYuR i0NIYDujxImf+1ghnGOMEq8vnWGCcA4DZX7/ZANpYRPQlfiwfRE7iC0ioCpx+ullZhBbWCBQ Yvm7vYwQ8TCJhWvb2CBsPYmu57/AalhA6i+vBIvzAtV/6v0OFmcUUJFYdnY1C4jNLCAuce5i KzvEeQISS/acZ4awRSVePv4HdbaSxINvnawQ9fkSpx4vYYaYKShxcuYTlgmMwrOQjJqFpGwW kjKIuIbEt86FTBC2osSU7odQ9eoSu580QNnaEssWvmZewMi+ilGwODkxz9BYDxidesn5uXol 5ZsYIWkhfQfj7vmOhxgFOBiVeHgZ3NkihFgTy4orcw8xSnAwK4nw/r4OFOJNSaysSi3Kjy8q zUktPsRoCgyVicxSosn5wJSVVxJvaGxpbGFoZGBmbG5hoSTOK96WGSIkkA5MR9mpqQWpRTB9 TBycUg2M0/a2uwRVz77yZ02L37u2aZZxU6U/2UrciDi6YO/1+pXPXpYFXZniZGM9tWvly01r PzD5G3572cd/Ocw23eKo88zFS+7G6nUqfvm9uUhQWc425Hik1Ntznw9sWfC4efL31KbcHdce C+w4V2Nrq9xhHi234pRij4242681yv6MFz/J3a5TW97Vp8RSnJFoqMVcVJwIAHI/O1IhAwAA Archived-At: Subject: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 19 Oct 2016 03:25:32 -0000 --_000_FC3F3FB8661CA84586F51E0F5449356E0151E950F3mbs5appcorpch_ Content-Type: text/plain; charset="big5" content-transfer-encoding: base64 SGk6DQogICBJIGFtIHdvbmRlcmluZyBpZiBVbnNvbGljaXRlZCBSQSBiZSBzZW50IGluIHRo aXMgbW9kZWw/DQoNCiAgIEJlY2F1c2UgYSB1bmlxdWUgSVB2NiBwcmVmaXggaXMgYXNzaWdu ZWQgdG8gZWFjaCBob3N0LCBpZiBtdWx0aWNhc3QgdW5zb2xpY2l0ZWQgUkEgaXMgc2VudCwg aXQgd2lsbCBzZW5kIHRoZSBwcmVmaXggZm9yIGhvc3QgQSB0byBvdGhlcnMgKHN1Y2ggYXMg QiwgQywgoUsuKQ0KICAgSWYgdW5pY2FzdCB1bnNvbGljaXRlZCBSQSBpcyBzZW50LCBHVyB3 aWxsIGhhcyB0byByZW1lbWJlciBlYWNoIGhvc3ShpnMgbXVsdGljYXN0IGFkZHJlc3OhSy4N Cg0KUmVnYXJkcw0KWWFubi1KdQ0KQ2h1bmdId2EgVGVsZWNvbS4gQ28uDQoNClBsZWFzZSBi ZSBhZHZpc2VkIHRoYXQgdGhpcyBlbWFpbCBtZXNzYWdlIChpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzKSBjb250YWlucyBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIG1heSBiZSBs ZWdhbGx5IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBkZXN0cm95IHRoaXMgbWVzc2FnZSBhbmQgYWxsIGF0dGFjaG1lbnRzIGZy b20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBmdXJ0aGVyIGNvbGxlY3QsIHByb2Nlc3MsIG9y IHVzZSB0aGVtLiBDaHVuZ2h3YSBUZWxlY29tIGFuZCBhbGwgaXRzIHN1YnNpZGlhcmllcyBh bmQgYXNzb2NpYXRlZCBjb21wYW5pZXMgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIGlt cHJvcGVyIG9yIGluY29tcGxldGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBlbWFpbCBub3IgZm9yIGFueSBkZWxheSBpbiBpdHMgcmVjZWlw dCBvciBkYW1hZ2UgdG8geW91ciBzeXN0ZW0uIElmIHlvdSBhcmUgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIHByb3RlY3QgdGhlIGNvbmZpZGVudGlhbCBhbmQvb3IgcGVyc29u YWwgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZW1haWwgd2l0aCBkdWUgY2FyZS4g QW55IHVuYXV0aG9yaXplZCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRo aXMgbWVzc2FnZSBpbiB3aG9sZSBvciBpbiBwYXJ0IGlzIHN0cmljdGx5IHByb2hpYml0ZWQu ICBBbHNvLCBwbGVhc2Ugc2VsZi1pbnNwZWN0IGF0dGFjaG1lbnRzIGFuZCBoeXBlcmxpbmtz IGNvbnRhaW5lZCBpbiB0aGlzIGVtYWlsIHRvIGVuc3VyZSB0aGUgaW5mb3JtYXRpb24gc2Vj dXJpdHkgYW5kIHRvIHByb3RlY3QgcGVyc29uYWwgaW5mb3JtYXRpb24uDQo= --_000_FC3F3FB8661CA84586F51E0F5449356E0151E950F3mbs5appcorpch_ Content-Type: text/html; charset="big5" content-transfer-encoding: quoted-printable

Hi:

I am wondering if U= nsolicited RA be sent in this model?

<= /p>

Because a uniq= ue IPv6 prefix is assigned to each host, if multicast unsolicited RA is sent= , it will send the prefix for host A to others (such as B, C, =A1K.)

If unicast unsolici= ted RA is sent, GW will has to remember each host=A1=A6s multicast address= =A1K.

Regards

Yann-Ju

ChungHwa Telecom. Co.=

本信件可能包= ;含中華電信股份有限= 0844;司機密資訊,非指定ߔ= 3;收件者,請勿蒐集、處&= #29702;或利用本信件內容,= 006;請銷毀此信件. 如為指定收件者,應確= 3526;保護郵件中本公司之= ;營業機密及個人資料,&#= 19981;得任意傳佈或揭露,È= 06;應自行確認本郵件之&= #38468;檔與超連結之安全ö= 15;,以共同善盡資訊安全= 與個資保護責任.
Please be advised that this email message (including any attachments) co= ntains confidential information and may be legally privileged. If you are no= t the intended recipient, please destroy this message and all attachments fr= om your system and do not further collect, process, or use them. Chunghwa Te= lecom and all its subsidiaries and associated companies shall not be liable= for the improper or incomplete transmission of the information contained in= this email nor for any delay in its receipt or damage to your system. If yo= u are the intended recipient, please protect the confidential and/or persona= l information contained in this email with due care. Any unauthorized use, d= isclosure or distribution of this message in whole or in part is strictly pr= ohibited. Also, please self-inspect attachments and hyperlinks contained in= this email to ensure the information security and to protect personal infor= mation. --_000_FC3F3FB8661CA84586F51E0F5449356E0151E950F3mbs5appcorpch_-- From nobody Tue Oct 18 23:10: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 9516D1293F4 for ; Tue, 18 Oct 2016 23:10:07 -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 9N3uC06_SgWS for ; Tue, 18 Oct 2016 23:10:04 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 AD3DD1293F0 for ; Tue, 18 Oct 2016 23:10:04 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id m72so19090068oik.3 for ; Tue, 18 Oct 2016 23:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wtvXHh6tMaL5yy+Z2Bgp7xgKNqC3b42+No3W2ympmoo=; b=PAMGXZAC80rAX+71e7Zh0Wj6gSbKB+/ltM4AR0W/A3xVGr1VQpQhel4htkVtSfMVzh xV5kOHin4Dme1oF2Uo3wLYFPNWZtVkkhcMDcoESGregBN5tm3Pwat0HVEFuhgKd9fDPQ YEFmTK+/vWCbPZ2xP2XZujsvs7RTCjYcVwuHmZSmT3FBGAbMylAOYkCv3PXf8Qb7KqCS Xlk+TkclGylHlpp9V8Vo6yBqoTrti4U9FKH+ILb+XMW2PfO7t9DR/17GNHPyBalBw/pT RyCWyPbe891zB86646MGoEe+6Ub8ThY4+uklkDBpI8cdEroKjTq/3m2z3fZ87gZOyXee /otw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wtvXHh6tMaL5yy+Z2Bgp7xgKNqC3b42+No3W2ympmoo=; b=JH1UA6XdlYu9x2lPxuR8AVPiJBkyCuGpL628Js9O7/k9IJspp6wa7DnYzYZm8YXNKC FKQrJgLe3q4x5w0XFCMCSmlR+wtQUSxXJdXnE7gq30mWs/RxdKgw59g1FB6pNF6h38u9 MCoV0nl27v5zouUSBDkWx9+hRevEixwUdYgnL4AGHSlVf1LHZJTelIRG8LP+mx/9NQ3A oFuFiKs840lvmT3oKXej+ja+XT0aqk9bX0gZbjLmcTy9YcXy7kTZdH55mmBdXkHArtWs ztpLFxMq6J+xq3+NHT2egXswASfqpYJIKpmYnpd95lop8aEca6pVJdfoxHVGLfnuZCyB L6ig== X-Gm-Message-State: AA6/9RmIZQYUtyNG2Jwt6xiPrCtYpbdhrPbPsHNKx3h1SZn9tNUq0MOSXbcPmhPbXxzMvg== X-Received: by 10.202.59.212 with SMTP id i203mr3490244oia.1.1476857404095; Tue, 18 Oct 2016 23:10:04 -0700 (PDT) Received: from [10.0.2.8] (wsip-184-191-158-196.sd.sd.cox.net. [184.191.158.196]) by smtp.gmail.com with ESMTPSA id q9sm13998651otq.22.2016.10.18.23.10.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Oct 2016 23:10:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 $3124$) From: Fred Baker In-Reply-To: Date: Tue, 18 Oct 2016 23:10:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> References: To: =?utf-8?B?5pyx5b2l5aaC?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 19 Oct 2016 06:10:07 -0000 Two important points: First, the draft only asks that =E2=80=9Cmultiple=E2=80=9D addresses be = available per host. This is in response to some enterprise environments = that uSE DHCP to assign addresses and lock the host down to one (or = maybe one =E2=80=9Cpermanent=E2=80=9D and one =E2=80=9Ctemporary=E2=80=9D)= . Multicast RA will happen in those environments, and means the same = thing it means in a SLAAC environment except for the fact of not using = SLAAC for the prefix. The second model that is discussed but not nailed down in the draft is = the assignment of a prefix, perhaps a /64, to a physical chassis to be = distributed on a virtual =E2=80=9CLAN=E2=80=9D inside the host - to = applications, containers, or whatever. In that case, the host OS = operates as a router between the physical and virtual LANs, and the = router that is its next hop (top-of-rack or whatever) learns the prefix = allocated to the host by some other means - a routing protocol, SDN, or = whatever. In such a case, there might be a prefix on the interconnect, = but addresses in that context might be strictly local - no prefix = necessary. I wouldn=E2=80=99t automatically assume that there is = anything to RA about beyond the existence of the router. > On Oct 18, 2016, at 8:24 PM, =E6=9C=B1=E5=BD=A5=E5=A6=82 = wrote: >=20 > Hi: > I am wondering if Unsolicited RA be sent in this model? > =20 > Because a unique IPv6 prefix is assigned to each host, if multicast = unsolicited RA is sent, it will send the prefix for host A to others = (such as B, C, =E2=80=A6.) > If unicast unsolicited RA is sent, GW will has to remember each = host=E2=80=99s multicast address=E2=80=A6. > =20 > Regards > Yann-Ju=20 > ChungHwa Telecom. Co. >=20 >=20 > = =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E4=B8=AD=E8= =8F=AF=E9=9B=BB=E4=BF=A1=E8=82=A1=E4=BB=BD=E6=9C=89=E9=99=90=E5=85=AC=E5=8F= =B8=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A,=E9=9D=9E=E6=8C=87=E5=AE=9A=E4=B9=8B= =E6=94=B6=E4=BB=B6=E8=80=85,=E8=AB=8B=E5=8B=BF=E8=92=90=E9=9B=86=E3=80=81=E8= =99=95=E7=90=86=E6=88=96=E5=88=A9=E7=94=A8=E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=85= =A7=E5=AE=B9,=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4=BF=A1=E4=BB=B6= . = =E5=A6=82=E7=82=BA=E6=8C=87=E5=AE=9A=E6=94=B6=E4=BB=B6=E8=80=85,=E6=87=89=E7= =A2=BA=E5=AF=A6=E4=BF=9D=E8=AD=B7=E9=83=B5=E4=BB=B6=E4=B8=AD=E6=9C=AC=E5=85= =AC=E5=8F=B8=E4=B9=8B=E7=87=9F=E6=A5=AD=E6=A9=9F=E5=AF=86=E5=8F=8A=E5=80=8B= =E4=BA=BA=E8=B3=87=E6=96=99,=E4=B8=8D=E5=BE=97=E4=BB=BB=E6=84=8F=E5=82=B3=E4= =BD=88=E6=88=96=E6=8F=AD=E9=9C=B2,=E4=B8=A6=E6=87=89=E8=87=AA=E8=A1=8C=E7=A2= =BA=E8=AA=8D=E6=9C=AC=E9=83=B5=E4=BB=B6=E4=B9=8B=E9=99=84=E6=AA=94=E8=88=87= =E8=B6=85=E9=80=A3=E7=B5=90=E4=B9=8B=E5=AE=89=E5=85=A8=E6=80=A7,=E4=BB=A5=E5= =85=B1=E5=90=8C=E5=96=84=E7=9B=A1=E8=B3=87=E8=A8=8A=E5=AE=89=E5=85=A8=E8=88= =87=E5=80=8B=E8=B3=87=E4=BF=9D=E8=AD=B7=E8=B2=AC=E4=BB=BB.=20 > Please be advised that this email message (including any attachments) = contains confidential information and may be legally privileged. If you = are not the intended recipient, please destroy this message and all = attachments from your system and do not further collect, process, or use = them. Chunghwa Telecom and all its subsidiaries and associated companies = shall not be liable for the improper or incomplete transmission of the = information contained in this email nor for any delay in its receipt or = damage to your system. If you are the intended recipient, please protect = the confidential and/or personal information contained in this email = with due care. Any unauthorized use, disclosure or distribution of this = message in whole or in part is strictly prohibited. Also, please = self-inspect attachments and hyperlinks contained in this email to = ensure the information security and to protect personal information. = _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 18 23:21:36 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 D5BD21293D8 for ; Tue, 18 Oct 2016 23:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, 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 jkG1t6JDOHX1 for ; Tue, 18 Oct 2016 23:21:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 85F07129440 for ; Tue, 18 Oct 2016 23:21:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 76813A2; Wed, 19 Oct 2016 08:21:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476858090; bh=MuUK4E0HKYIzgdLBuAWkSab1PgPdRPKSfBp15jEQau8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3mqgMlLfpQ+w/1JPjhsb4LmxXDbXwKFkFbdjQQIe92oBjf/OImty2GK+h5gY1c4sD 9Vw1HO4IbWchOcxDoU+HV9G2gTWyTQHULEj9uL3Vf69y+ZY4yspPeD5qGlrgoppGw+ eq12PaSbEwDKbboUhE4iiXhratR/mfMcRPe5g+lg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6ACC3A1; Wed, 19 Oct 2016 08:21:30 +0200 (CEST) Date: Wed, 19 Oct 2016 08:21:30 +0200 (CEST) From: Mikael Abrahamsson To: =?GB2312?B?1uyPqcjn?= In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1328975503-1476858090=:12036" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 19 Oct 2016 06:21:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1328975503-1476858090=:12036 Content-Type: TEXT/PLAIN; charset=big5; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 19 Oct 2016, ��ۦp wrote: > Hi: > I am wondering if Unsolicited RA be sent in this model? > > Because a unique IPv6 prefix is assigned to each host, if multicast unsolicited RA is sent, it will send the prefix for host A to others (such as B, C, �K.) > If unicast unsolicited RA is sent, GW will has to remember each host��s multicast address�K. Hi, there is a draft proposed in 6man: https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-00 It talks about some mechanisms needed that might be used in this context. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1328975503-1476858090=:12036-- From nobody Tue Oct 18 23:26: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 3DF161293E4 for ; Tue, 18 Oct 2016 23:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cht.com.tw 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 hW4Yqo8xQlmo for ; Tue, 18 Oct 2016 23:26:18 -0700 (PDT) Received: from scan15.cht.com.tw (scan15.cht.com.tw [202.39.160.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7A612943C for ; Tue, 18 Oct 2016 23:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=cht.com.tw; s=bill; c=relaxed/simple; q=dns/txt; i=@cht.com.tw; t=1476858369; x=1479450369; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZkL+M8ym98qJ5LaoyDA6IVZhqDiLJwmo8W7sRgMEc3E=; b=ZvyVytXPA6TTxLUrfjzspUCCkAxDjL6XGvtL9wufha2r9TwIgYnIh0XFBIPZogOW UMudLSUWb4ZBAxn7fwRhsi7D+PgAQnaOJPgOcyqSnsfsNubQVHu1sKEIX87bTbpy 8to2JYspi0tReIai4IM7bM/InIVzaLIMmDva6Dfgt9U=; X-AuditID: 0aa00769-f799a6d0000066f7-96-5807120118a0 Received: from scanrelay5.cht.com.tw ( [10.160.7.110]) by scan15.cht.com.tw (CHT Outgoing ESMTP Mail Server) with SMTP id B1.A2.26359.10217085; Wed, 19 Oct 2016 14:26:09 +0800 (CST) Received: from email.cht.com.tw (unknown [10.172.18.164]) by scanrelay5.cht.com.tw (Symantec Mail Security) with ESMTP id 03A76C000088; Wed, 19 Oct 2016 14:26:09 +0800 (CST) Received: from MBS5.app.corp.cht.com.tw ([fe80::184b:2137:90a0:edaf]) by HUB6.app.corp.cht.com.tw ([fe80::5411:3134:b4a:2940%12]) with mapi id 14.03.0266.001; Wed, 19 Oct 2016 14:26:08 +0800 From: =?utf-8?B?5pyx5b2l5aaC?= To: Fred Baker Thread-Topic: =?utf-8?B?W+WklumDqOmDteS7tl0gUmU6IFt2Nm9wc10gdW5pcXVlLWlwdjYtcHJlZml4?= =?utf-8?B?LXBlci1ob3N0IFdpbGwgVW5zb2xpY2l0ZWQgUkEgYmUgc2VudCBpbiB0aGlz?= =?utf-8?Q?_model=3F?= Thread-Index: AdIpuCWjrD8RtLbwSDaRKG/n91S/If//qHKA//94JZA= Date: Wed, 19 Oct 2016 06:26:08 +0000 Message-ID: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> In-Reply-To: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> Accept-Language: zh-HK, zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.169.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsXCtYA9T5dRiD3CoGEFt8Xtrw2sFqeP7WV2 YPLYOesuu8eSJT+ZApiiFG1SUnMyy1KL9O1skioLEouLdZPTFBJzcmyVSopKU5X07RIUM2Yd f8le8EOnYtKMkgbGJ9pdjJwcEgImEv2/JjFD2GISF+6tZ+ti5OIQEtjOKLH10FZmCGcjo8S3 vmWsEM4hRonzC9rBWtgEjCTuzv7BBmKLCGhK3F43jamLkYODWUBVYvYffpB6YYEdjBJ724+w gzgiAjsZJWbNvMECUiQiYCUx4wzYGSxA9RNOzmMHsXkFAiWa+84wQixrYZR4PP0BI0iCU8BW 4sCzv2BFjAIqEsvOrmYBsZkFxCXOXWxlh/hBQGLJnvNQ/4hKvHz8jxXCVpJ48K2TFeI4TYn1 u/QhWhUlpnQ/hNorKHFy5hOWCYzis5BMnYXQMQtJxywkHQsYWVYxChYnJ+YZmuolZ5ToJefn 6pWUb2KERF/mDsaD8x0PMQpwMCrx8DK4s0UIsSaWFVfmAgOSg1lJhDdVgD1CiDclsbIqtSg/ vqg0J7X4EGMyMFAmMkuJJucDE0NeSbyhsaWxiaWJuZG5makBacJK4rzibZkhQgLpiSWp2amp BalFMFuYODilGhj5bq9nj3M9U8v9Ys9K+TlCj/Y+Krz57LhBoQdLfbI6/3q9GV9eLJ9Yr2zZ KfTjmBJr8gf/gNM3pv8RWhXu0B7hI7n6u/HihkpTfY/aNzV6AX5y9tuM/zM/L5XTWbP205n1 4gu9j/JVdmtffh3luNg2YnaU6ZP9Pi15AZrMQhIaBWan27sesimxFGckGmoxFxUnAgDQQk2y AgMAAA== Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] =?utf-8?b?W+WklumDqOmDteS7tl0gUmU6ICB1bmlxdWUtaXB2Ni1w?= =?utf-8?q?refix-per-host_Will_Unsolicited_RA_be_sent_in_this_model=3F?= 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, 19 Oct 2016 06:26:21 -0000 U29ycnksIEkgYW0gYSBsaXR0bGUgY29uZnVzZWQuLi4uIE1heWJl77yMSSBkaWRuJ3QgZGVzY3Jp YmUgbXkgcHJvYmxlbSBjb3JyZWN0bHkuDQoNCkkgZ2l2ZSBhIHN1bW1hcnkgb2YgU2VjdGlvbiA0 ICgoSVB2NiBVbmlxdWUgUHJlZml4IEFzc2lnbm1lbnQpIGluIHRoaXMgZHJhZnQ6DQoxLiBXaGVu IGEgVUUgY29ubmVjdHMgdG8gdGhlIHNoYXJlZCBwcm92aWRlciBtYW5hZ2VkIG5ldHdvcmssIGl0 IHNlbmRzIGEgUlMgdG8gbGVhcm4gdGhlIGRlZmF1bHQgZ2F0ZXdheS4gDQoyLiBUaGUgRmlyc3Qg SG9wIFByb3ZpZGVyIFJvdXRlciB3aWxsIGFuc3dlciAgdXNpbmcgYSB1bmljYXN0IFJBIChSb3V0 ZXIgQWR2ZXJ0aXNlbWVudCkgdG8gdGhlIFVFL3N1YnNjcmliZXINCg0KQWNjb3JkaW5nIHRvIGFi b3ZlIGRlc2NyaXB0aW9ucywgdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIgc2hvdWxkIHNl bmQgIlVuaWNhc3QiIFNvbGljaXRlZCBSQSAoaW4gcmVwbHkgdG8gUlMpLg0KDQpNeSBxdWVzdGlv bnMgYXJlOiANCkluIGFkZGl0aW9uIHRvIHRoaXMgIlVuaWNhc3QiIFNvbGljaXRlZCBSQSwgd2ls bCB0aGUgRmlyc3QgSG9wIFByb3ZpZGVyIFJvdXRlciBzZW5kICJ1bi1zb2xpY2l0ZWQiIFJBPz8N CklmIHRoZSBhbnN3ZXIgaXMgeWVzLCBJcyB0aGlzIHBlcmlvZGljIHVuc29saWNpdGVkIFJBIFVu aWNhc3Qgb3IgTXVsdGljYXN0Pw0KSWYgaXQgaXMgTXVsdGljYXN0LCB0aGVuIHRoaXMgbXVsdGlj YXN0IFJBIHdpbGwgc2VuZCB0aGUgcHJlZml4IGZvciBob3N0IEEgdG8gb3RoZXJzIChzdWNoIGFz IEIsIEMsIOKApi4pDQoNClJlZ2FyZHMNCllhbm4tSnUNCiAgIA0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEZyZWQgQmFrZXIgW21haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5j b21dIA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE5LCAyMDE2IDI6MTAgUE0NClRvOiDmnLHl vaXlpoINCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogW+WklumDqOmDteS7tl0gUmU6IFt2 Nm9wc10gdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0IFdpbGwgVW5zb2xpY2l0ZWQgUkEgYmUg c2VudCBpbiB0aGlzIG1vZGVsPw0KDQo8L2NoYWlyPg0KDQpUd28gaW1wb3J0YW50IHBvaW50czoN Cg0KRmlyc3QsIHRoZSBkcmFmdCBvbmx5IGFza3MgdGhhdCDigJxtdWx0aXBsZeKAnSBhZGRyZXNz ZXMgYmUgYXZhaWxhYmxlIHBlciBob3N0LiBUaGlzIGlzIGluIHJlc3BvbnNlIHRvIHNvbWUgZW50 ZXJwcmlzZSBlbnZpcm9ubWVudHMgdGhhdCB1U0UgREhDUCB0byBhc3NpZ24gYWRkcmVzc2VzIGFu ZCBsb2NrIHRoZSBob3N0IGRvd24gdG8gb25lIChvciBtYXliZSBvbmUg4oCccGVybWFuZW504oCd IGFuZCBvbmUg4oCcdGVtcG9yYXJ54oCdKS4gTXVsdGljYXN0IFJBIHdpbGwgaGFwcGVuIGluIHRo b3NlIGVudmlyb25tZW50cywgYW5kIG1lYW5zIHRoZSBzYW1lIHRoaW5nIGl0IG1lYW5zIGluIGEg U0xBQUMgZW52aXJvbm1lbnQgZXhjZXB0IGZvciB0aGUgZmFjdCBvZiBub3QgdXNpbmcgU0xBQUMg Zm9yIHRoZSBwcmVmaXguDQoNClRoZSBzZWNvbmQgbW9kZWwgdGhhdCBpcyBkaXNjdXNzZWQgYnV0 IG5vdCBuYWlsZWQgZG93biBpbiB0aGUgZHJhZnQgaXMgdGhlIGFzc2lnbm1lbnQgb2YgYSBwcmVm aXgsIHBlcmhhcHMgYSAvNjQsIHRvIGEgcGh5c2ljYWwgY2hhc3NpcyB0byBiZSBkaXN0cmlidXRl ZCBvbiBhIHZpcnR1YWwg4oCcTEFO4oCdIGluc2lkZSB0aGUgaG9zdCAtIHRvIGFwcGxpY2F0aW9u cywgY29udGFpbmVycywgb3Igd2hhdGV2ZXIuIEluIHRoYXQgY2FzZSwgdGhlIGhvc3QgT1Mgb3Bl cmF0ZXMgYXMgYSByb3V0ZXIgYmV0d2VlbiB0aGUgcGh5c2ljYWwgYW5kIHZpcnR1YWwgTEFOcywg YW5kIHRoZSByb3V0ZXIgdGhhdCBpcyBpdHMgbmV4dCBob3AgKHRvcC1vZi1yYWNrIG9yIHdoYXRl dmVyKSBsZWFybnMgdGhlIHByZWZpeCBhbGxvY2F0ZWQgdG8gdGhlIGhvc3QgYnkgc29tZSBvdGhl ciBtZWFucyAtIGEgcm91dGluZyBwcm90b2NvbCwgU0ROLCBvciB3aGF0ZXZlci4gSW4gc3VjaCBh IGNhc2UsIHRoZXJlIG1pZ2h0IGJlIGEgcHJlZml4IG9uIHRoZSBpbnRlcmNvbm5lY3QsIGJ1dCBh ZGRyZXNzZXMgaW4gdGhhdCBjb250ZXh0IG1pZ2h0IGJlIHN0cmljdGx5IGxvY2FsIC0gbm8gcHJl Zml4IG5lY2Vzc2FyeS4gSSB3b3VsZG7igJl0IGF1dG9tYXRpY2FsbHkgYXNzdW1lIHRoYXQgdGhl cmUgaXMgYW55dGhpbmcgdG8gUkEgYWJvdXQgYmV5b25kIHRoZSBleGlzdGVuY2Ugb2YgdGhlIHJv dXRlci4NCg0KPiBPbiBPY3QgMTgsIDIwMTYsIGF0IDg6MjQgUE0sIOacseW9peWmgiA8eWpjaHVp QGNodC5jb20udHc+IHdyb3RlOg0KPiANCj4gSGk6DQo+ICAgIEkgYW0gd29uZGVyaW5nIGlmIFVu c29saWNpdGVkIFJBIGJlIHNlbnQgaW4gdGhpcyBtb2RlbD8NCj4gICAgDQo+ICAgIEJlY2F1c2Ug YSB1bmlxdWUgSVB2NiBwcmVmaXggaXMgYXNzaWduZWQgdG8gZWFjaCBob3N0LCBpZiBtdWx0aWNh c3QgdW5zb2xpY2l0ZWQgUkEgaXMgc2VudCwgaXQgd2lsbCBzZW5kIHRoZSBwcmVmaXggZm9yIGhv c3QgQSB0byBvdGhlcnMgKHN1Y2ggYXMgQiwgQywg4oCmLikNCj4gICAgSWYgdW5pY2FzdCB1bnNv bGljaXRlZCBSQSBpcyBzZW50LCBHVyB3aWxsIGhhcyB0byByZW1lbWJlciBlYWNoIGhvc3TigJlz IG11bHRpY2FzdCBhZGRyZXNz4oCmLg0KPiAgDQo+IFJlZ2FyZHMNCj4gWWFubi1KdSANCj4gQ2h1 bmdId2EgVGVsZWNvbS4gQ28uDQo+IA0KPiANCj4g5pys5L+h5Lu25Y+v6IO95YyF5ZCr5Lit6I+v 6Zu75L+h6IKh5Lu95pyJ6ZmQ5YWs5Y+45qmf5a+G6LOH6KiKLOmdnuaMh+WumuS5i+aUtuS7tuiA hSzoq4vli7/okpDpm4bjgIHomZXnkIbmiJbliKnnlKjmnKzkv6Hku7blhaflrrks5Lim6KuL6Yq3 5q+A5q2k5L+h5Lu2LiDlpoLngrrmjIflrprmlLbku7bogIUs5oeJ56K65a+m5L+d6K236YO15Lu2 5Lit5pys5YWs5Y+45LmL54ef5qWt5qmf5a+G5Y+K5YCL5Lq66LOH5paZLOS4jeW+l+S7u+aEj+WC s+S9iOaIluaPremcsizkuKbmh4noh6rooYznorroqo3mnKzpg7Xku7bkuYvpmYTmqpToiIfotoXp gKPntZDkuYvlronlhajmgKcs5Lul5YWx5ZCM5ZaE55uh6LOH6KiK5a6J5YWo6IiH5YCL6LOH5L+d 6K236LKs5Lu7LiANCj4gUGxlYXNlIGJlIGFkdmlzZWQgdGhhdCB0aGlzIGVtYWlsIG1lc3NhZ2Ug KGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGNvbnRhaW5zIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBhbmQgbWF5IGJlIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlc3Ryb3kgdGhpcyBtZXNzYWdlIGFuZCBhbGwgYXR0 YWNobWVudHMgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGZ1cnRoZXIgY29sbGVjdCwgcHJv Y2Vzcywgb3IgdXNlIHRoZW0uIENodW5naHdhIFRlbGVjb20gYW5kIGFsbCBpdHMgc3Vic2lkaWFy aWVzIGFuZCBhc3NvY2lhdGVkIGNvbXBhbmllcyBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUg aW1wcm9wZXIgb3IgaW5jb21wbGV0ZSB0cmFuc21pc3Npb24gb2YgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIGVtYWlsIG5vciBmb3IgYW55IGRlbGF5IGluIGl0cyByZWNlaXB0IG9y IGRhbWFnZSB0byB5b3VyIHN5c3RlbS4gSWYgeW91IGFyZSB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgcHJvdGVjdCB0aGUgY29uZmlkZW50aWFsIGFuZC9vciBwZXJzb25hbCBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBlbWFpbCB3aXRoIGR1ZSBjYXJlLiBBbnkgdW5hdXRob3Jp emVkIHVzZSwgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBtZXNzYWdlIGluIHdo b2xlIG9yIGluIHBhcnQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gQWxzbywgcGxlYXNlIHNlbGYt aW5zcGVjdCBhdHRhY2htZW50cyBhbmQgaHlwZXJsaW5rcyBjb250YWluZWQgaW4gdGhpcyBlbWFp bCB0byBlbnN1cmUgdGhlIGluZm9ybWF0aW9uIHNlY3VyaXR5IGFuZCB0byBwcm90ZWN0IHBlcnNv bmFsIGluZm9ybWF0aW9uLiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Tue Oct 18 23:31:55 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 32EDF129532 for ; Tue, 18 Oct 2016 23:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 ADq1QWOVUf3B for ; Tue, 18 Oct 2016 23:31:50 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 2BC091293F0 for ; Tue, 18 Oct 2016 23:31:50 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id z189so31631894wmb.1 for ; Tue, 18 Oct 2016 23:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iDde9C9MTePFNabWPO1LFXMUouVBXkM616Ubc50mtE8=; b=UhDpCqlEVHIg5XsGN2CciQ4YfoPxa/O25oVlWa/tDfE7HM/Bce8uSOnlz49scm+3ho eaLhYZXbs8tMtbsOgb3GPCVE8TxbCwZR+9KiTYMPuhJAJFsx0Iwb6Bn4nstsrpIP3EpP 7M2BD4yOw9Hnp1kudv0M6gf9DUfhO3QlK7eTp4ZO/1As215ELSJ7Vx/855JFiX4q6u1F LUCF2C7s7AhSd0zlM2WXQBsNhRbFh4AlYdMD55zoWobylTwAtcOr4OuNHmJHndJUwHuX I3X26TXonWLWP5GjiimyHgX5JzWbwAGHnJkSo5OGohL+iAQB0ozvlaJcujjdExLe0Fjj QnTw== 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:content-transfer-encoding; bh=iDde9C9MTePFNabWPO1LFXMUouVBXkM616Ubc50mtE8=; b=XZ64MQEmXC6n3YldbiMDdkdGAXluRrA9pW9IzIGXHadHwdBzz1qY50/pS/xMPD0gfF My8i5YKj9yPJ9uO2Z1gfO//dNLIVQF9/q2K+uI+TwWAP02QlZye6ARd43D6V7zU5OiL4 ieBEuT1EP6WMrBwADDZ2cEM0rydL6hZI+Ayf5sQFF7eD6sQ2Gau4uLz17t7cvCULHNpq xxUeoveEE/paFCddqVny0sMAmK4AG+WgAe+uudkZGZfeZpqlpXHGpTAgmII0D7dJcA8B cJA4TH6W14AHmMZOEZft4amMv80Zq1BxN0WiBkLPB1XhXG3oGTeACQdozDZ+fVGZEVws v/7g== X-Gm-Message-State: AA6/9Rlr0i+S4fXMPjk0SV2YH4ijMgZ8l0L3L6cE4dBRxV5mFf23Ul8ong2GtPjezvZwPAxzUARvM3DWki9llyPQ X-Received: by 10.194.148.162 with SMTP id tt2mr3031016wjb.147.1476858708513; Tue, 18 Oct 2016 23:31:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.168.5 with HTTP; Tue, 18 Oct 2016 23:31:27 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Erik Kline Date: Wed, 19 Oct 2016 15:31:27 +0900 Message-ID: To: =?UTF-8?B?5pyx5b2l5aaC?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] =?utf-8?b?W+WklumDqOmDteS7tl0gUmU6IHVuaXF1ZS1pcHY2LXBy?= =?utf-8?q?efix-per-host_Will_Unsolicited_RA_be_sent_in_this_model=3F?= 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, 19 Oct 2016 06:31:53 -0000 On 19 October 2016 at 15:26, =E6=9C=B1=E5=BD=A5=E5=A6=82 wrote: > Sorry, I am a little confused.... Maybe=EF=BC=8CI didn't describe my prob= lem correctly. > > I give a summary of Section 4 ((IPv6 Unique Prefix Assignment) in this dr= aft: > 1. When a UE connects to the shared provider managed network, it sends a = RS to learn the default gateway. > 2. The First Hop Provider Router will answer using a unicast RA (Router = Advertisement) to the UE/subscriber > > According to above descriptions, the First Hop Provider Router should sen= d "Unicast" Solicited RA (in reply to RS). > > My questions are: > In addition to this "Unicast" Solicited RA, will the First Hop Provider R= outer send "un-solicited" RA?? > If the answer is yes, Is this periodic unsolicited RA Unicast or Multicas= t? It depends on whether or not you have link-layer isolation. If you have link-layer isolation between clients then the router than unicast or multicast and RA with the client's PIO. Without link-layer isolation the only two options are: [1] unicast RA with client's PIO [2] multicast RA without any PIOs Clients receiving the latter should not automatically invalidate their previously received PIOs--they should just honor the timers they last received. However, this approach may be straying into "different clients behave differently" territory. > If it is Multicast, then this multicast RA will send the prefix for host = A to others (such as B, C, =E2=80=A6.) > > Regards > Yann-Ju > > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Wednesday, October 19, 2016 2:10 PM > To: =E6=9C=B1=E5=BD=A5=E5=A6=82 > Cc: v6ops@ietf.org > Subject: [=E5=A4=96=E9=83=A8=E9=83=B5=E4=BB=B6] Re: [v6ops] unique-ipv6-p= refix-per-host Will Unsolicited RA be sent in this model? > > > > Two important points: > > First, the draft only asks that =E2=80=9Cmultiple=E2=80=9D addresses be a= vailable per host. This is in response to some enterprise environments that= uSE DHCP to assign addresses and lock the host down to one (or maybe one = =E2=80=9Cpermanent=E2=80=9D and one =E2=80=9Ctemporary=E2=80=9D). Multicast= RA will happen in those environments, and means the same thing it means in= a SLAAC environment except for the fact of not using SLAAC for the prefix. > > The second model that is discussed but not nailed down in the draft is th= e assignment of a prefix, perhaps a /64, to a physical chassis to be distri= buted on a virtual =E2=80=9CLAN=E2=80=9D inside the host - to applications,= containers, or whatever. In that case, the host OS operates as a router be= tween the physical and virtual LANs, and the router that is its next hop (t= op-of-rack or whatever) learns the prefix allocated to the host by some oth= er means - a routing protocol, SDN, or whatever. In such a case, there migh= t be a prefix on the interconnect, but addresses in that context might be s= trictly local - no prefix necessary. I wouldn=E2=80=99t automatically assum= e that there is anything to RA about beyond the existence of the router. > >> On Oct 18, 2016, at 8:24 PM, =E6=9C=B1=E5=BD=A5=E5=A6=82 wrote: >> >> Hi: >> I am wondering if Unsolicited RA be sent in this model? >> >> Because a unique IPv6 prefix is assigned to each host, if multicast u= nsolicited RA is sent, it will send the prefix for host A to others (such a= s B, C, =E2=80=A6.) >> If unicast unsolicited RA is sent, GW will has to remember each host= =E2=80=99s multicast address=E2=80=A6. >> >> Regards >> Yann-Ju >> ChungHwa Telecom. Co. >> >> >> =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E4=B8=AD= =E8=8F=AF=E9=9B=BB=E4=BF=A1=E8=82=A1=E4=BB=BD=E6=9C=89=E9=99=90=E5=85=AC=E5= =8F=B8=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A,=E9=9D=9E=E6=8C=87=E5=AE=9A=E4= =B9=8B=E6=94=B6=E4=BB=B6=E8=80=85,=E8=AB=8B=E5=8B=BF=E8=92=90=E9=9B=86=E3= =80=81=E8=99=95=E7=90=86=E6=88=96=E5=88=A9=E7=94=A8=E6=9C=AC=E4=BF=A1=E4=BB= =B6=E5=85=A7=E5=AE=B9,=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4=BF= =A1=E4=BB=B6. =E5=A6=82=E7=82=BA=E6=8C=87=E5=AE=9A=E6=94=B6=E4=BB=B6=E8=80= =85,=E6=87=89=E7=A2=BA=E5=AF=A6=E4=BF=9D=E8=AD=B7=E9=83=B5=E4=BB=B6=E4=B8= =AD=E6=9C=AC=E5=85=AC=E5=8F=B8=E4=B9=8B=E7=87=9F=E6=A5=AD=E6=A9=9F=E5=AF=86= =E5=8F=8A=E5=80=8B=E4=BA=BA=E8=B3=87=E6=96=99,=E4=B8=8D=E5=BE=97=E4=BB=BB= =E6=84=8F=E5=82=B3=E4=BD=88=E6=88=96=E6=8F=AD=E9=9C=B2,=E4=B8=A6=E6=87=89= =E8=87=AA=E8=A1=8C=E7=A2=BA=E8=AA=8D=E6=9C=AC=E9=83=B5=E4=BB=B6=E4=B9=8B=E9= =99=84=E6=AA=94=E8=88=87=E8=B6=85=E9=80=A3=E7=B5=90=E4=B9=8B=E5=AE=89=E5=85= =A8=E6=80=A7,=E4=BB=A5=E5=85=B1=E5=90=8C=E5=96=84=E7=9B=A1=E8=B3=87=E8=A8= =8A=E5=AE=89=E5=85=A8=E8=88=87=E5=80=8B=E8=B3=87=E4=BF=9D=E8=AD=B7=E8=B2=AC= =E4=BB=BB. >> Please be advised that this email message (including any attachments) co= ntains confidential information and may be legally privileged. If you are n= ot the intended recipient, please destroy this message and all attachments = from your system and do not further collect, process, or use them. Chunghwa= Telecom and all its subsidiaries and associated companies shall not be lia= ble for the improper or incomplete transmission of the information containe= d in this email nor for any delay in its receipt or damage to your system. = If you are the intended recipient, please protect the confidential and/or p= ersonal information contained in this email with due care. Any unauthorized= use, disclosure or distribution of this message in whole or in part is str= ictly prohibited. Also, please self-inspect attachments and hyperlinks cont= ained in this email to ensure the information security and to protect perso= nal information. _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 18 23:50: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 C85FF1293D9 for ; Tue, 18 Oct 2016 23:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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, RP_MATCHES_RCVD=-0.431, 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 W8hchzuQYn23 for ; Tue, 18 Oct 2016 23:50:38 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 48444129458 for ; Tue, 18 Oct 2016 23:50:38 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id f5so22126396ioj.2 for ; Tue, 18 Oct 2016 23:50:38 -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=0lp8b4FfW70AiFEh3RUprdamEvqfEqiRBwHaAn0b00c=; b=Gta9q3ao1FHmWLMPMUG3PVXVQ0EuDsrsQE6Zolo8SPVi25EKQLKZWVWththpJPRGE2 GLvotLNaba4zsdCfOViihOdAD6ICNL0nmFyVcrdLOaBHVykZw6ZWS6i/sjRnyP5HzjAJ wm3a43Yli1pa8k+bg8SLHuQEoc3zS0GJFawK4cpEJxL0ZJDDhXlILXXj6ZNj+8CcI0z/ tuo5lPWz0dRjPX6H8lYvzcXkwzS2ku7wu2ZW35aIoWk43wlV6pX8Stk6Ze51MItMSKNa 6T/C0YYFTVDUtHrl8btllon2U60eJL7d+obUJFidoPAFauaXNDZekXbiA86BrHgsJTKy xDwg== 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=0lp8b4FfW70AiFEh3RUprdamEvqfEqiRBwHaAn0b00c=; b=c9ztc1jZ3r9FQ5wKm1VLw1O3YXp9xUoHqklOn4HWBl5zclysHNlcL8+iJLuNizogUn Pu4TrjNGYyjCCLrIvRzTy1r5/V3/nEpujvUaYFqxF7mei1WECuPXQGp8u2tSBt4uha/h 1LLdQMhN/vnGK/yFEBbgJ8dTIgPfxidj0TQ2DZUf8+PJ6LX9AEMr9PCQBUgTMvbgQHpJ 9mFrZTbBbu1htYPD0SmLQ9wCLyOVm2HHJewJJsk+KTyyvgIGOy0x6OMHSdL1257EarQz mn8q1P0hjAsmno53svo7TnX0AHpoRWgMe5fREUQwx5yw6SwaKXTXekwjNIJX7nyLYG9u IxJg== X-Gm-Message-State: AA6/9Rn9a1/rwt6URsCZgl5GzUpn7V62h6SL9ZKPeRJG46YLR4zPmzhY71Rcqsy+SakD2SppNWy6irSFxsNOaLP9 X-Received: by 10.107.128.205 with SMTP id k74mr5282776ioi.223.1476859837024; Tue, 18 Oct 2016 23:50:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.19.244 with HTTP; Tue, 18 Oct 2016 23:50:16 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com>

From: Lorenzo Colitti Date: Wed, 19 Oct 2016 15:50:16 +0900 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a113f9772f8715b053f3239e2 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] =?utf-8?b?W+WklumDqOmDteS7tl0gUmU6IHVuaXF1ZS1pcHY2LXBy?= =?utf-8?q?efix-per-host_Will_Unsolicited_RA_be_sent_in_this_model=3F?= 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:

--94eb2c095680d6be3c053f38cf5e-- From nobody Thu Oct 20 01:02: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 1FC3E129532 for ; Thu, 20 Oct 2016 01:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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=-0.431, 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 PVt1pVmPlh2t for ; Thu, 20 Oct 2016 01:02:36 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 D39E6129546 for ; Thu, 20 Oct 2016 01:02:32 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 4so158571426itv.0 for ; Thu, 20 Oct 2016 01:02:32 -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=GXmdkZ2v7OI6/KfAMPsYfOq6wFyyu/nwokdRyH5rgic=; b=d2XE6XUCmIT49oGH1oNGX5/BiN6i2dbq+31fJqu8U2XBZxgI9VgrJ0lqfGoHV2zrCs H+vzOfCAHRWlNJY2fKv7XRR51G839atpIDoDQ6b8ZvlPBxpnPq+ByzARtKfFdow3VthG 8DtC7LvjdW8L820t1bwes77ROuuR5BZVieC7eja2n4DJYUwFHhK8+2u7o4eMLB+d35s/ 0ZCbmtJOZoRRH4o3rYJ4vcmaeiXkJqL8RE1c/bG2vcb2P2RAXizuMQQaabNZffaIXAoH VQUFLcOeoBysjeR5W36S/kBFMSL9D3WYyAEQ3adj0YQDrIWVbSEfIS6rkS9hFzi2RUE5 ZbDg== 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=GXmdkZ2v7OI6/KfAMPsYfOq6wFyyu/nwokdRyH5rgic=; b=IN9y0YNBz70ySk7NncAQe6ELxQizzEgmI4q0P3KhSKoMnRvav+WPNU1ET/WPNc70Fa JJ1l63xzK24V0yRkVW2WxvqgNgHa9GCV0PU5lDjhqguC7NWxgFlQyIKrWpfFeAMEzwAB j9PWWZYwrax3jSLqPtWZnf1Q9m6o3C5mmSu9a0eYN1IygIQV+jE/iFS/zRvPa83MJTTN IUATHJabGXF9w4eLWFtpgbX6Xy8vkqJhBdrtU70g+y8fyDQ2X+hJcKqsOZMZVGOviMAs 7goHIQza1XkCTyDFCcJm3TeFQlb16i4A/xIdoVF9E4Wn93Fc2gdGM8DQwFZYVurWmlDB Ozrg== X-Gm-Message-State: AA6/9Rk8B8hWnL70tx+lSM7xH39fGry6AjZL97dp+m8qOZoS2dZubvN1rwHYfzoDT7uRcI7mert8VpIJPtlUfkEv X-Received: by 10.107.128.205 with SMTP id k74mr11046025ioi.223.1476950551870; Thu, 20 Oct 2016 01:02:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.19.244 with HTTP; Thu, 20 Oct 2016 01:02:11 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Lorenzo Colitti Date: Thu, 20 Oct 2016 17:02:11 +0900 Message-ID: To: Hemant Singh Content-Type: multipart/alternative; boundary=001a113f9772ff49b5053f47587e Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 20 Oct 2016 08:02:38 -0000 --001a113f9772ff49b5053f47587e Content-Type: text/plain; charset=UTF-8 On Wed, Oct 19, 2016 at 11:33 PM, Hemant Singh wrote: > With respect to Containers, please note, the Container community has > copied Container IPv4 behavior to IPv6. For security, so that Container > ports could accidentally be advertised to the whole world via a global IPv4 > address, IPv4 Containers use a private IPv4 with NAT44. IPv6 has done the > same with ULA. Thus a global IPv6 address may not be used by a Container. > Why not also have apps and whatever else also use a ULA? > https://tools.ietf.org/html/rfc7934#section-5 > See this URL for the IPv6 Container implementation. The URL includes some > discussion related to NAT. > > https://github.com/robbertkl/docker-ipv6nat > AIUI that project started because lots of things didn't work with global IPv6 addresses and they didn't have a good method to assign IPv6 addresses to containers. That doesn't mean it was the right thing to do, and it definitely doesn't mean that other designs should follow that approach. --001a113f9772ff49b5053f47587e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 19, 2016 at 11:33 PM, Hemant Singh <hemantietf@gmail.com>= ; wrote:
With respect to Containers, please note, the Container community= has copied Container IPv4 behavior to IPv6.=C2=A0 For security, so that Co= ntainer ports could accidentally be advertised to the whole world via a glo= bal IPv4 address, IPv4 Containers use a private IPv4 with NAT44.=C2=A0 IPv6= has done the same with ULA.=C2=A0 Thus a global IPv6 address may not be us= ed by a Container.=C2=A0 Why not also have apps and whatever else also use = a ULA?

https://tools.ietf.org/html/rfc7934#section-5
=C2=A0
See this URL for the IPv6 Container implementatio= n.=C2=A0 The URL includes some discussion related to NAT.

https://github.com/robbertkl/docker-ipv6nat
=C2=A0
AIUI that project started because lots of th= ings didn't work with global IPv6 addresses and they didn't have a = good method to assign IPv6 addresses to containers. That doesn't mean i= t was the right thing to do, and it definitely doesn't mean that other = designs should follow that approach.
--001a113f9772ff49b5053f47587e-- From nobody Thu Oct 20 08:20: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 1F21F1294F0 for ; Thu, 20 Oct 2016 08:20:31 -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 8xEzkvfH0Hph for ; Thu, 20 Oct 2016 08:20:29 -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 91CA61294C6 for ; Thu, 20 Oct 2016 08:20:29 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t193so57345072ywc.2 for ; Thu, 20 Oct 2016 08:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ykio3+e9L5kJ9kuPfHxBTX7IfSCDrMT79Rj22igipWk=; b=mYvQioBK6nOd/u4iCKYUWViVTy6p3AO3C1axo74Q6SgXvMIcie+IHlbMq3hsCJdXjH WdaFXMNTrfmQTsfxPWynopq7hAHiZz3/xZ3YdlXz+qZ1KbPvAmNVK0uxp9kowjMOAeTP UEqKbP0eXQYVZZSVMRwR/73uCWocuxvYi3+X78nNeW65f5YU94UMqvdYI4WxuQfDiE3U XXjEdDtj3Gb5MhA5oMWa5LV+lRIWhu2OIhTK+uajEQmikM51ydknOHhTsoy8yw+PoL5G FerPMYjf9ZsTV03e7wMx5SU6Zjmev9kARjESlkfevNPJOJlfqfNlohuLDI1B0WqNQeiU ClKQ== 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=ykio3+e9L5kJ9kuPfHxBTX7IfSCDrMT79Rj22igipWk=; b=Z/7aKUsqWrzvncUI/ui7b5N5ZkXgkS3uKJxgMaSHPblakW+ECe4J0wSRsSZSP3MoJP nhBCqvFZHnMh+LS9+CnRxk12J22ieW3JXuejPqhOOq3benFVC3oTp5XzPoxctATbDRGB 3h7dYJNM0WLJBvR4pVFlOM4bpIA5hxXanXw2qGC8+xhFPcC70wbhEH91Rio9DzQ8d05e 10uIFciqkdCbt8YPPcWAEDAIbdJEfG2LRn+mmgs/ItE37ZmHMKCVnb/GIBoLhFbr1C2F uchUhEGW9ZXcqfX9QBZ7S/OmIsUqR5zSxOin8mJ7M+JIt/kfC+YCz823Nwbh5k/Dpdar 9ckQ== X-Gm-Message-State: AA6/9RnzjGPMirEpafCyCmpqNbmCXL2i4FUXDBqAREJiECcEi0U8OL4BBjAnDxbpLAhLOnk/epyBl0MBq/TZUA== X-Received: by 10.202.91.131 with SMTP id p125mr7689543oib.173.1476976827782; Thu, 20 Oct 2016 08:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.71 with HTTP; Thu, 20 Oct 2016 08:20:27 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Hemant Singh Date: Thu, 20 Oct 2016 11:20:27 -0400 Message-ID: To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a113d4d0c295e64053f4d7761 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 20 Oct 2016 15:20:31 -0000 --001a113d4d0c295e64053f4d7761 Content-Type: text/plain; charset=UTF-8 The IPv6 Container code duplicated what the IPv4 Container code does. As I said in the past, the IPv4 Container use a private IPv4 address (including why) and thus the IPv6 code also uses a ULA. The ULA packets cannot go out to the Internet and stay within the local network. Thus, I think using a ULA by the IPv6 Docker Container is not open to debate. On a different note, before the IPv4 /8 address pools were all used up, at each IETF, especially in the plenary session, folks asked "why does Skype not support IPv6". We should collect a list of such broken IPv6 nodes such as the IPv6 Container, and other software and hardware that does not support IPv6 and put the list at a wiki. Maybe such a wiki already exists related to v6ops. Then we can, as a team, fix the software and hardware, including prioritizing what gets fixed first. Recently, a video streamer which has existed since 1999 and even supported till today did not support IPv6. I took that public-domain code and made it work for IPv6 in about one week. I am going to put the code in the public domain after more testing is done. Cheers, Hemant On Thu, Oct 20, 2016 at 4:02 AM, Lorenzo Colitti wrote: > > > AIUI that project started because lots of things didn't work with global > IPv6 addresses and they didn't have a good method to assign IPv6 addresses > to containers. That doesn't mean it was the right thing to do, and it > definitely doesn't mean that other designs should follow that approach. > --001a113d4d0c295e64053f4d7761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The IPv6 Container code duplicated what the IPv4 Container= code does.=C2=A0 As I said in the past, the IPv4 Container use a private I= Pv4 address (including why) and thus the IPv6 code also uses a ULA.=C2=A0 T= he ULA packets cannot go out to the Internet and stay within the local netw= ork. =C2=A0 Thus, I think using a ULA by the IPv6 Docker Container is not o= pen to debate. =C2=A0

On a different note, before the IP= v4 /8 address pools were all used up, at each IETF, especially in the plena= ry session, folks asked "why does Skype not support IPv6".=C2=A0 = We should collect a list of such broken IPv6 nodes such as the IPv6 Contain= er, and other software and hardware that does not support IPv6 and put the = list at a wiki.=C2=A0 Maybe such a wiki already exists related to v6ops. = =C2=A0 =C2=A0Then we can, as a team, fix the software and hardware, includi= ng prioritizing what gets fixed first.=C2=A0 Recently, a video streamer whi= ch has existed since 1999 and even supported till today did not support IPv= 6.=C2=A0 I took that public-domain code and made it work for IPv6 in about = one week. =C2=A0 I am going to put the code in the public domain after more= testing is done.=C2=A0

Cheers,

Hemant

On Thu, Oct 20, 2016 at 4:02 AM, Lorenzo Colitti <lorenzo@goog= le.com> wrote:

=C2=A0
AIUI that project started bec= ause lots of things didn't work with global IPv6 addresses and they did= n't have a good method to assign IPv6 addresses to containers. That doe= sn't mean it was the right thing to do, and it definitely doesn't m= ean that other designs should follow that approach.

--001a113d4d0c295e64053f4d7761-- From nobody Fri Oct 21 16:21:38 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 39DFF1296C1; Fri, 21 Oct 2016 16:21:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206623.28214.4718533652986565704.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:06 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] v6ops - Requested session has been scheduled for IETF 97 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, 21 Oct 2016 23:21:06 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Grand Ballroom 2 size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg Second Priority: tsvarea intarea lmap softwire Special Requests: --------------------------------------------------------- From nobody Sun Oct 23 12:16: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 D171312944D for ; Sun, 23 Oct 2016 12:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 g2ZY4gkKgF9S for ; Sun, 23 Oct 2016 12:16:24 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 6DC12127ABE for ; Sun, 23 Oct 2016 12:16:24 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id r64so26885989uar.2 for ; Sun, 23 Oct 2016 12:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahIhSn4CZOW7MWeOInIVhrHuy+jSYIoFdY4AtDwsNdw=; b=0OsYUEvSH7921fM7o9OS6P/BIWHBTGQJQR9zwibqUxBh945H67lxrmCiXkGv57oK7B 0JcfkHSIPhj2YgYr4moZTTijafeebEGmubGLnQkdwwz5hGAGQSYcW4NSpf9LxB5EWUJo /h8g1EMPszKBXln7pf7//k9RlFXiff4Gk/dFoflSD+JoAxOARXfwyfJI17x+ESBQTynn VFw5PtSVTQulk+plvCaKgPg174CuCQwvdgZPOgN6bif/1FkDwxM1KslOC60o+YePaxWO cEgr/V9DAamvmER6CIyzvfp+th5pW/KZZczHJuiYIzu/bWAqYhjfDxKkyfsG2gmS6qp8 BXMA== 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=ahIhSn4CZOW7MWeOInIVhrHuy+jSYIoFdY4AtDwsNdw=; b=PjVsYvNsmxCmrxM3stshzS7xtNSEysoeRtVPZpiDwHN7YCmKHLDVO0RfBs73lmznHa +w7ggHUKrxi3GLS6o/odlId03c1uP+uHElD54JaXgphmi+0DQvy6Jme8qV0ZcAmsnCH3 H3y+rxfjLncVRpQtYXO2hBAmDMmGB/769GDn4ukQ5WMay3d+XbxKpAGa2oe7ZiL0gCMQ eSpfAhfy8K4M3Qq3soB8DyljpKDQY/ftEDI51/9P1OCg1BWowvHB+R50DOtRSt829bhd euN1ekjeUHQgzHMahSeQfF7t8wIxsRxp1nrefHh9fdmTF3gSF4Vs/wioJ+EEOBihfEj+ GKpA== X-Gm-Message-State: ABUngvchxRIIELWbuHXxxeXFjPyBstmROmyt4SMLR7UvSTM1fjkdbaK5u7+nFmqLEGbPrjNYqst1ioCSNZ9fag== X-Received: by 10.176.2.65 with SMTP id 59mr6063657uas.11.1477250183445; Sun, 23 Oct 2016 12:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Sun, 23 Oct 2016 12:15:53 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Mark Smith Date: Mon, 24 Oct 2016 06:15:53 +1100 Message-ID: To: Hemant Singh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 23 Oct 2016 19:16:26 -0000 On 21 October 2016 at 02:20, Hemant Singh wrote: > The IPv6 Container code duplicated what the IPv4 Container code does. As I > said in the past, the IPv4 Container use a private IPv4 address (including > why) and thus the IPv6 code also uses a ULA. The ULA packets cannot go out > to the Internet and stay within the local network. In theory. Packets leak via default routes all of the time. (I appreciate what you're saying, however lets not pretend just using private addresses prevents unwanted packet leaks to the Internet) > Thus, I think using a > ULA by the IPv6 Docker Container is not open to debate. > I really think we should put some effort into convincing them that ULAs and NAT66 are not the way to achieve the security they want. This viewpoint also shows a lack of some fundamentals about IPv6 - such that it is possible to have both public and private addresses concurrently. Once IPv6 application developers have to assume the possibility of the presence of NAT, every application will be burdened with either NAT traversal code or will be forced to adopt a client-server architecture, even when a peer-to-peer application architecture that IPv6 (without NAT) can facilitate would be far better. I've assumed the whole point of containers is to run one service/application per container because the container overhead is so minimal. I'd think that means that firewalling of containers is almost binary - either remote access to the container is available or it isn't. In other words, a container won't hold a mix of public and private applications (if there is any inter-application communication within a container, it takes place over ::1), so firewalling should be much simpler. I think this is an example of applying pure IPv4 mentality to IPv6. In recent times I've started to think that it would have been better to create the demand for IPv6 deployment not be promoting it to network operators, but rather, the promoting its benefits to the people who create the capability demands of the network - the networked application developers. > On a different note, before the IPv4 /8 address pools were all used up, at > each IETF, especially in the plenary session, folks asked "why does Skype > not support IPv6". We should collect a list of such broken IPv6 nodes such > as the IPv6 Container, and other software and hardware that does not support > IPv6 and put the list at a wiki. Maybe such a wiki already exists related > to v6ops. Then we can, as a team, fix the software and hardware, > including prioritizing what gets fixed first. Recently, a video streamer > which has existed since 1999 and even supported till today did not support > IPv6. I took that public-domain code and made it work for IPv6 in about one > week. I am going to put the code in the public domain after more testing > is done. > > Cheers, > > Hemant > > Regards, Mark. From nobody Mon Oct 24 13:53: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 A54C31299B6 for ; Mon, 24 Oct 2016 13:53:16 -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] 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 lI5MVKFBaYmK for ; Mon, 24 Oct 2016 13:53:15 -0700 (PDT) Received: from tor-smtp-04.primus.ca (smtp-auth2-160.primus.ca [216.254.140.160]) by ietfa.amsl.com (Postfix) with ESMTP id 999B7129441 for ; Mon, 24 Oct 2016 13:53:15 -0700 (PDT) Received: from [24.114.80.153] (helo=[172.20.10.4]) by tor-smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bymF9-0002mC-2D; Mon, 24 Oct 2016 16:53:15 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2016 16:52:55 -0400 Message-Id: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> To: v6ops list Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.80.153] Archived-At: Subject: [v6ops] IETF meeting with IPv6 routes over IPv4? 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, 24 Oct 2016 20:53:16 -0000 I have a memory that there was an IETF meeting some years ago where the = IPv6 connectivity used BGP sessions where the IPv6 routes were carried = over an BGP session that ran over IPv4 transport. Does anyone remember = which meeting that was, and why this was done? We are updating the BGP = section in the Design Choices draft and are considering mentioning this. -Philip= From nobody Mon Oct 24 14:51: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 1EB51129A39 for ; Mon, 24 Oct 2016 14:51: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 l6s9dvu-NMqf for ; Mon, 24 Oct 2016 14:51:21 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 756EB129479 for ; Mon, 24 Oct 2016 14:51:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u124so17708821ywg.3 for ; Mon, 24 Oct 2016 14:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UzA1PT5ZUlfrt89H/P7RqtxEDmcUfQKIfpTh7Z9MUDg=; b=s8lbcR2r5fC5K8bbFB9pw6GBUK4/xifUEMVbKwTsJ5krzXNqd/hcQn/nsbylgUjUUQ PZ2oovItr1a/bjbbSdH4gnQgC7sM7r4cNJVk3apApfnApd18thOiVtakPte2xsM6tD8A icWjtquo1unZFZkNVVij7ND3AzAz0KYD/0HeumMV8mFmS2+0bp6KCJgi3ZQKkZDo4WfD PJP8oaHWx154TA/OPQpmrOs5WhhJE86n3qleIw467696pecyN4EcbRUfqlZkdgcHff9q 8tc6SmGB/tjWyg0falmeTZeDEEpiyLMRuHzzIkq/beruslbB5b22ahO4MsOgTI59xXti s2FQ== 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=UzA1PT5ZUlfrt89H/P7RqtxEDmcUfQKIfpTh7Z9MUDg=; b=HS1cvhFSa8FBmpH2yAoqxXT53QQjLkjCeBoTiVYfYMP2TaQHpGTJxopAt4yREuHEZD SC5OPTM7x44KETtuTH6Iqnd2ggy4goA960griDAxS3UTMg0b109gNeiGTHfrtU8C+6SX +d4Q5RsLL6GBIPCU0er3xzqqkOAkQAuIj9LGWYBIwLNTpYiyup5xmi2VA1xpt59weyIQ 9HNOrTHTHAE+hM0mU7cXvHr+9DOtRhHt+DWKBj6mlWg+JJgKrL/TshpHmprC5c+ix95G z+eNRfeftK++z+1H1aQwDuoTHN1/YqQykhv1Q+4eGe81GXU3npGYcZZGMLqTCWK9ICEk 31QQ== X-Gm-Message-State: AA6/9Rm1hbAZyvcSRicYCuQpN8xfiIkxa2GRAOaIp/KM4UTAlC2xll2HhVKbL85Q6Fmtk9dtO0FUsis3qNVfyQ== X-Received: by 10.202.91.131 with SMTP id p125mr21234438oib.173.1477345880759; Mon, 24 Oct 2016 14:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.71 with HTTP; Mon, 24 Oct 2016 14:51:20 -0700 (PDT) In-Reply-To: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> References: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> From: Hemant Singh Date: Mon, 24 Oct 2016 17:51:20 -0400 Message-ID: To: Philip Matthews Content-Type: multipart/alternative; boundary=001a113d4d0c6ee4dd053fa36470 Archived-At: Cc: v6ops list Subject: Re: [v6ops] IETF meeting with IPv6 routes over IPv4? 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, 24 Oct 2016 21:51:23 -0000 --001a113d4d0c6ee4dd053fa36470 Content-Type: text/plain; charset=UTF-8 I suspect it would have been a MPLS network which supported only IPv4 MPLS at the time and thus carried IPv6 BGP routers over IPv4 transport. Hemant On Mon, Oct 24, 2016 at 4:52 PM, Philip Matthews wrote: > I have a memory that there was an IETF meeting some years ago where the > IPv6 connectivity used BGP sessions where the IPv6 routes were carried over > an BGP session that ran over IPv4 transport. Does anyone remember which > meeting that was, and why this was done? We are updating the BGP section > in the Design Choices draft and are considering mentioning this. > > -Philip > _______________________________________________ > --001a113d4d0c6ee4dd053fa36470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suspect it would have been a MPLS network which supporte= d only IPv4 MPLS at the time and thus carried IPv6 BGP routers over IPv4 tr= ansport. =C2=A0

Hemant

On Mon, Oct 24, 2016 at 4:52 PM, Phi= lip Matthews <philip_matthews@magma.ca> wrote:
I have a memory that there was an IETF meeting = some years ago where the IPv6 connectivity used BGP sessions where the IPv6= routes were carried over an BGP session that ran over IPv4 transport.=C2= =A0 Does anyone remember which meeting that was, and why this was done?=C2= =A0 We are updating the BGP section in the Design Choices draft and are con= sidering mentioning this.

-Philip
_______________________________________________
=
--001a113d4d0c6ee4dd053fa36470-- From nobody Mon Oct 24 15:03: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 05BF3129A9F for ; Mon, 24 Oct 2016 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_NONE=-0.0001, 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 63hZE-7gmUbF for ; Mon, 24 Oct 2016 15:03:56 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 6A3E7129A9D for ; Mon, 24 Oct 2016 15:03:56 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id g68so90157954ybi.0 for ; Mon, 24 Oct 2016 15:03:56 -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=mGUmBQ+uJoelYWwluvkjHYNCLAYzr3tEhM86pBUTsDk=; b=cJPSggnmvoAsfWhTVvB+LvI6nItEDpoeiWcWHR8rG2o3zL36VypSPKYbNDeiJuctmE 9jxUHg+pXhCOdalWkkp1wZYx0KZppAaG1hERxg26qjAEWPsaTMFhN/Vji0kUeyTnlv/3 KiWAiFBUd4Zv2o1xukUHQRo1Nal3Oo5VMVvq57qnoJfMpFJYCVwtjqzUC/plwkKDZ4jB NviEz/ULmLCRiN5qUJss67lzwv2BHqGLaQAGFIsaAVqHSw5Z/kAIrYsBOi5cC+Kh9yyl 0GPAc1YJ1gcRXexamWOHkYKp+2xwlE38P+bn4SucVmISI+mkSHJE0YDRBn3jBCtRnzxE wBQQ== 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=mGUmBQ+uJoelYWwluvkjHYNCLAYzr3tEhM86pBUTsDk=; b=gaYyTOdnGVoebrfeRbrSrBfhAAec26GDjiBr/ii2VJlz+CE92SN6oT7n7aWtYVbkEa 2cCQ2W5qJjfiH97a7VuEfLQeCDW1IVKrYKwsmBl9aRXuV6PGcOX3dWGk+gUueAkKZvI/ tjgdSXyAhLoZcEIyk9vSUwRilcV7H7ihD9Elp/fk6SNkYJibnUIt8ExjgYVrqenDj+cc lLHDxu6lcyM2K83Kkm89VHXCupJtHvGMcFk5bzdrRvEsQy0HZV5iztsdT9pfewl+em1Y faqUHJVuwOqeWn3WQ3Rx7BqbyrxFt75vfAD/q0CIN637y5gfXqkHTtan3c0pzmgVaAC3 1DTg== X-Gm-Message-State: ABUngvfitc0E9OTP6zi7df34Eb2lZH1O7YK46u/q7Co1unrJeQqNRrl6Zptk0Y6Q1tLmyb5nd9/hrleQQAntAQ== X-Received: by 10.157.44.73 with SMTP id f67mr2748317otb.126.1477346635688; Mon, 24 Oct 2016 15:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.71 with HTTP; Mon, 24 Oct 2016 15:03:55 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Hemant Singh Date: Mon, 24 Oct 2016 18:03:55 -0400 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=94eb2c11f1346e2f25053fa391e5 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 24 Oct 2016 22:03:58 -0000 --94eb2c11f1346e2f25053fa391e5 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 23, 2016 at 3:15 PM, Mark Smith wrote: > > > Once IPv6 application developers have to assume the possibility of the > presence of NAT, every application will be burdened with either NAT > traversal code or will be forced to adopt a client-server > architecture, even when a peer-to-peer application architecture that > IPv6 (without NAT) can facilitate would be far better. > > I've assumed the whole point of containers is to run one > service/application per container because the container overhead is so > minimal. I'd think that means that firewalling of containers is almost > binary - either remote access to the container is available or it > isn't. In other words, a container won't hold a mix of public and > private applications (if there is any inter-application communication > within a container, it takes place over ::1), so firewalling should be > much simpler. > > A bare-metal machine is running 100 Containers. Each Container has a global IPv6 address. Doesn't one now have to provision a firewall for these 100 IPv6 source addresses? It more provisioning vs. adding NAT support to apps are the the two extremes. Sure, we should run this Container behavior by IETF app groups. Operators who run large data centers are also welcome to chime in. In some instances between a large company intranet and extranet to its external vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred Baker. Regards, Hemant > > > > > --94eb2c11f1346e2f25053fa391e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 23, 2016 at 3:15 PM, Mark Smith <markzzzsmith@gmail.c= om> wrote:

Once IPv6 application developers have to assume the possibility of the
presence of NAT, every application will be burdened with either NAT
traversal code or will be forced to adopt a client-server
architecture, even when a peer-to-peer application architecture that
IPv6 (without NAT) can facilitate would be far better.

I've assumed the whole point of containers is to run one
service/application per container because the container overhead is so
minimal. I'd think that means that firewalling of containers is almost<= br> binary - either remote access to the container is available or it
isn't. In other words, a container won't hold a mix of public and private applications (if there is any inter-application communication
within a container, it takes place over ::1), so firewalling should be
much simpler.

A bare-metal machine is running 100 Containers.=C2=A0= Each Container has a global IPv6 address.=C2=A0 Doesn't one now have t= o provision a firewall for these 100 IPv6 source addresses?=C2=A0 It more p= rovisioning vs. adding NAT support to apps are the the two extremes. =C2=A0= Sure, we should run this Container behavior by IETF app groups.=C2=A0 Oper= ators who run large data centers are also welcome to chime in. =C2=A0 In so= me instances between a large company intranet and extranet to its external = vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred= Baker. =C2=A0

Regards,

H= emant
=C2=A0

--94eb2c11f1346e2f25053fa391e5-- From nobody Mon Oct 24 17:24:24 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 7331612961F for ; Mon, 24 Oct 2016 17:24:23 -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 IPoG-zEpLEiv for ; Mon, 24 Oct 2016 17:24:22 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 DBD7E1295A7 for ; Mon, 24 Oct 2016 17:24:21 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id r16so107547127pfg.1 for ; Mon, 24 Oct 2016 17:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6uZ3UknbGf/xC/Zl2CWxxzLgHa/ev4krXNeoEkkqPyM=; b=EI4jh39rYlGKc5f6xKJDTGT4NHaFmgFjCaVqrA0aKrPeI1uYJzfxwOjww3Uxh5s0ux uCCzS+we7ucbqEwlfHhqVn4B3rkVn2jHVPZ2Qq1Ndddl5EhcguDNxdSVn/YnZMX8gRzL qBFGEoManuCWVsT4pgVDUkaitSrCDe6uULs+8rZ+scv0HkvvOsxm8J/uZUndPnU4XFdl WWszmJy3w21r1buQOIRa/5y87X1W00YqnzKeQixk7DGvqF/DL0+7kZRDk1P/t/JORkpN u95GYBZNn1AzGjD+8b+TNpHwmHhmit0B5W/ZO23U1o0LzwTyMiYrRv79snSI/zpvKVYx i0eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6uZ3UknbGf/xC/Zl2CWxxzLgHa/ev4krXNeoEkkqPyM=; b=IN97F7RrJGSI56TQ1LCom0CGhGvRPfuPANi5iQ3eVzZUvZMRJ2Jrrbhy9o++lfRt76 /BhWh+OopDI0M9BvWOzJd9AZt2rJqvk4sePs4G8HW5me2qV/RQxX+A80EhwWWVlnHNLG uf78Q/pxSvuka0H5vm2TCRIgyaWrnOagXzmrr6WWnwVLsWUCT26BzlWJYtEKlSrGpph5 jMXfY1skvr6+JeZV7POpY0pI1unzIgsRha6BohI3mbLbn3QBapunB8/IxnejM9fnjnPD DM92HUXjIYy5DO3kbsG5T9bK/27n7F5pOm8QYnDPD7ntj7l7fouv8rTNgXr8Lmc/Zd22 VB0Q== X-Gm-Message-State: ABUngveYFi31612G/4Y2dlqmAQneuvX7Pehf0HdvS3yah3yh+K9E4j0acna7WYPolPF+6w== X-Received: by 10.98.52.194 with SMTP id b185mr33497830pfa.41.1477355061558; Mon, 24 Oct 2016 17:24:21 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:9411:eb6d:f253:b4c? ([2601:646:c005:a10:9411:eb6d:f253:b4c]) by smtp.gmail.com with ESMTPSA id a7sm27991974pan.34.2016.10.24.17.24.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 24 Oct 2016 17:24:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Mon, 24 Oct 2016 17:24:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <309DEE56-AFF2-461D-97DE-391A51A6AEBC@gmail.com> References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> To: Hemant Singh Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 00:24:23 -0000 Sent from my iPad > On Oct 24, 2016, at 3:03 PM, Hemant Singh wrote: >=20 > In some instances between a large company intranet and extranet to its e= xternal vendors, NAT44 is used and thus a NAT66 draft was actually authored b= y Fred Baker. =20 If you're going to invoke my name, you might consider getting your facts str= aight. Read RFC 6296, including the Security Considerations, before continui= ng.= From nobody Mon Oct 24 18:24: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 A4E8B1299D8 for ; Mon, 24 Oct 2016 18:24:13 -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 Yw_7ptcCM09p for ; Mon, 24 Oct 2016 18:24:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 19B99129A82 for ; Mon, 24 Oct 2016 18:24:12 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id i127so13328411oia.2 for ; Mon, 24 Oct 2016 18:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xvMvyWmDYBsWTM10U0xwP190gLVh3pAnTZ2ojx3gH80=; b=Tze/zMrA/s6gysdt1ajLPu/4SjczBFFtB+VfetsI6rCf4jiXp7uIv8fPujKIVYPUup 1DjlysQRbWypbeH/bnuASBY0AnQWgq+5XLJEvuR3PMC8WLvKbCUsfl4KCCoYM1dQbjy0 9Afmx/GMyyqZ0fV9o1LSDXLswZJMgeRW7Xv+HoTXT851fdtRNk4X7ETNGDmGVGewB3ud zexHrTNsbnVecp0YPB5ko8182ErZGC4b5b6zRmn4OeLZYG2FfVsVmAxzkGnKgxDYM7+z XTB9nbCDil0RILb2reMHk9IFl1+Ph+F9A7Gm2VdSkI2NSQDU/TfryrJyT4aamcBl57lE d/Sw== 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=xvMvyWmDYBsWTM10U0xwP190gLVh3pAnTZ2ojx3gH80=; b=cmAnT4YHHhWazVpT+uCNhOpRoktGBLeL7R0ls8bnlYZil8P4ly+oqkkh1vXyfFRp6e IqNPkhkSmgo6yCPHyQG7VWwKsOT/abGClTAQh4nF9QVTGJ5FH5gQIQ6t78g0XQHL1VUk IvrT8c4fX7IJJg0f4zUhZekTbEJ4hXTMGRKwAYO39Uu0eg+T3E4TWrYvAJAPijJSibck ZNisB/5Nr027i0ArIYw7+nZfp6I/02zeJh4VE7QehRScO+4WhmvBJULRA9LVSNC+YIHX MXI9g8IqpberIp5VWw/d+GpjWX5CsJXrBpKcAJn6+6YHh5chltykb8BFS6nTVNdz8QGZ /QVg== X-Gm-Message-State: ABUngvdwXu0QlO5/zrY+VPTWtQUbqZi97Kt5WuLSt7I12F+GcBNHWjNIAqZ676SmJosom3XLHI2r5eT3FwR/KQ== X-Received: by 10.202.104.8 with SMTP id d8mr7833061oic.18.1477358651241; Mon, 24 Oct 2016 18:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.71 with HTTP; Mon, 24 Oct 2016 18:24:10 -0700 (PDT) In-Reply-To: <309DEE56-AFF2-461D-97DE-391A51A6AEBC@gmail.com> References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> <309DEE56-AFF2-461D-97DE-391A51A6AEBC@gmail.com> From: Hemant Singh Date: Mon, 24 Oct 2016 21:24:10 -0400 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=001a11409e8a9cfb26053fa65dbc Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 01:24:13 -0000 --001a11409e8a9cfb26053fa65dbc Content-Type: text/plain; charset=UTF-8 Fred, I had heard the comments during a presentation at an IETF about intra vs. extra net and NAT66 as a use case, especially Cisco as a company. My apologies, if I incorrectly said anything.. Appreciate the RFC reference. Hemant On Mon, Oct 24, 2016 at 8:24 PM, Fred Baker wrote: > > > Sent from my iPad > > > On Oct 24, 2016, at 3:03 PM, Hemant Singh wrote: > > > > In some instances between a large company intranet and extranet to > its external vendors, NAT44 is used and thus a NAT66 draft was actually > authored by Fred Baker. > > If you're going to invoke my name, you might consider getting your facts > straight. Read RFC 6296, including the Security Considerations, before > continuing. --001a11409e8a9cfb26053fa65dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fred,

I had heard the comments during a= presentation at an IETF about intra vs. extra net and NAT66 as a use case,= especially Cisco as a company.=C2=A0 My apologies, if I incorrectly said a= nything..=C2=A0 Appreciate the RFC reference.

Hema= nt

On = Mon, Oct 24, 2016 at 8:24 PM, Fred Baker <fredbaker.ietf@gmail.com<= /a>> wrote:

Sent from my iPad

> On Oct 24, 2016, at 3:03 PM, Hemant Singh <hemantietf@gmail.com> wrote:
>
>=C2=A0 =C2=A0 In some instances between a large company intranet and ex= tranet to its external vendors, NAT44 is used and thus a NAT66 draft was ac= tually authored by Fred Baker.

If you're going to invoke my name, you might consider getting yo= ur facts straight. Read RFC 6296, including the Security Considerations, be= fore continuing.

--001a11409e8a9cfb26053fa65dbc-- From nobody Mon Oct 24 19:14: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 43B18129462 for ; Mon, 24 Oct 2016 19:14:14 -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, 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 Rn5v5dD2OYoI for ; Mon, 24 Oct 2016 19:14:12 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 B2F2D12941E for ; Mon, 24 Oct 2016 19:14:12 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id y123so3962967vka.3 for ; Mon, 24 Oct 2016 19:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s/tQBtQ7G8EzjmarvqpHRsly3Xwt/PabyInzCbT3Pgc=; b=JVp2jWfIyWkkujKt4VjDj0e+/HoX3d0YQcOa6QX9iX+sLO4/wDlyMQ07TPnlwB9sUX qaQY6o+2rtijvcttVQiFN3yglVwg6I4y9WTpsbcu4il9ZKrxe58thM5laOWziS8OkEaZ CjH4g20eBfpWbyuetg5mvZpsZA2jxScojVmBqYZnkZn0CP2z3aCO7GK3u7HIbQa6lK7N J4U2y+RgGep2nCz7w9suhkKSUDKNs34qLnHxhWzbauMPxMsJXiJG3edR2pJTjVuspIKu QDZfcxX0GX1JavEQUCAtTpCXbAWClFj78LNB0H4py7kJsxoNjeRVoUOIvc39UTmmQP5c fVVw== 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=s/tQBtQ7G8EzjmarvqpHRsly3Xwt/PabyInzCbT3Pgc=; b=i0BKgYCkYEgS3/KIKtFH47F5y8B7QphEOy5k9R9SNgqrSat5AbcKQqXRYmv0AsVd4f FjLymD6LECFWyh0esCeKBGSLIPoz7xYCNU5n4QwSca7tkR8VBCDBySzZOSf6CTCgVekg qtBB7L8AQYEKmeXAf5id7CTCGzYzwXZXiCdsJu9Te5zTSZF9InkNsKUO+e/f8mi8TNaa cZaq4uk0Sl3Qt7t1ME+pq+M2d7dUP24pmH7mir5X6rY3k1SOlwJHTa/i85uO3zCZxuLI al93OCebVcQcJpCna4rVq22vIaW1/rfrPPlTIHCMlLTi8uUMf5FuXYDD3P/hy7cCaqkO kleg== X-Gm-Message-State: ABUngvfmXbIZhdMGRYg0HUc2SF1/mvDukg3WWFSdigrB4oh2Stden5KZahFRu/bzp4BcmRMn21BeL79G8H2KBg== X-Received: by 10.31.203.3 with SMTP id b3mr205456vkg.131.1477361651596; Mon, 24 Oct 2016 19:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Mon, 24 Oct 2016 19:14:10 -0700 (PDT) Received: by 10.176.16.79 with HTTP; Mon, 24 Oct 2016 19:14:10 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Mark Smith Date: Tue, 25 Oct 2016 13:14:10 +1100 Message-ID: To: Hemant Singh Content-Type: multipart/alternative; boundary=001a114dc97872c2a1053fa710fc Archived-At: Cc: v6ops list Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 02:14:14 -0000 --001a114dc97872c2a1053fa710fc Content-Type: text/plain; charset=UTF-8 On 25 Oct. 2016 9:03 am, "Hemant Singh" wrote: > > > > On Sun, Oct 23, 2016 at 3:15 PM, Mark Smith wrote: >> >> >> >> Once IPv6 application developers have to assume the possibility of the >> presence of NAT, every application will be burdened with either NAT >> traversal code or will be forced to adopt a client-server >> architecture, even when a peer-to-peer application architecture that >> IPv6 (without NAT) can facilitate would be far better. >> >> I've assumed the whole point of containers is to run one >> service/application per container because the container overhead is so >> minimal. I'd think that means that firewalling of containers is almost >> binary - either remote access to the container is available or it >> isn't. In other words, a container won't hold a mix of public and >> private applications (if there is any inter-application communication >> within a container, it takes place over ::1), so firewalling should be >> much simpler. >> > A bare-metal machine is running 100 Containers. Each Container has a global IPv6 address. Doesn't one now have to provision a firewall for these 100 IPv6 source addresses? It more provisioning vs. adding NAT support to apps are the the two extremes. Containers a light weight virtual machines, and VMs are virtualised physical machines. How are and have people been securing 100s/1000s of physical machines running apps? It's not a new problem caused by containers. Google and Facebook are providing large scale services over IPv6, I very much doubt they're using ULAs with giant stateful NAT66 boxes in front of all of them. > Sure, we should run this Container behavior by IETF app groups. Operators who run large data centers are also welcome to chime in. In some instances between a large company intranet and extranet to its external vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred Baker. > If you're referring to Network Prefix Translation, it doesn't do or work the way you think it does. You also might want to have a look at this: "The Trouble with NAT" https://www.slideshare.net/mobile/MarkSmith214/ausnog-2016-the-trouble-with-nat Regards, Mark. > Regards, > > Hemant > >> >> >> >> >> > --001a114dc97872c2a1053fa710fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 25 Oct. 2016 9:03 am, "Hemant Singh" <hemantietf@gmail.com> wrote:
>
>
>
> On Sun, Oct 23, 2016 at 3:15 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>>
>>
>> Once IPv6 application developers have to assume the possibility of= the
>> presence of NAT, every application will be burdened with either NA= T
>> traversal code or will be forced to adopt a client-server
>> architecture, even when a peer-to-peer application architecture th= at
>> IPv6 (without NAT) can facilitate would be far better.
>>
>> I've assumed the whole point of containers is to run one
>> service/application per container because the container overhead i= s so
>> minimal. I'd think that means that firewalling of containers i= s almost
>> binary - either remote access to the container is available or it<= br> >> isn't. In other words, a container won't hold a mix of pub= lic and
>> private applications (if there is any inter-application communicat= ion
>> within a container, it takes place over ::1), so firewalling shoul= d be
>> much simpler.
>>
> A bare-metal machine is running 100 Containers.=C2=A0 Each Container h= as a global IPv6 address.=C2=A0 Doesn't one now have to provision a fir= ewall for these 100 IPv6 source addresses?=C2=A0 It more provisioning vs. a= dding NAT support to apps are the the two extremes.

Containers a light weight virtual machines, and VMs are virt= ualised physical machines.

How are and have people been securing 100s/1000s of physical= machines running apps? It's not a new problem caused by containers.
Google and Facebook are providing large scale services over = IPv6, I very much doubt they're using ULAs with giant stateful NAT66 bo= xes in front of all of them.

> =C2=A0 Sure, we should run this Container behavior by I= ETF app groups.=C2=A0 Operators who run large data centers are also welcome= to chime in. =C2=A0 In some instances between a large company intranet and= extranet to its external vendors, NAT44 is used and thus a NAT66 draft was= actually authored by Fred Baker. =C2=A0
>

If you're referring to Network Prefix Translation, it do= esn't do or work the way you think it does.

You also might want to have a look at this:

"The Trouble with NAT"
https://www.slideshare.net/mobile/MarkSmith214/ausnog-2016= -the-trouble-with-nat

Regards,
Mark.

> Regards,
>
> Hemant
> =C2=A0
>>
>>
>>
>>
>>
>
--001a114dc97872c2a1053fa710fc-- From nobody Mon Oct 24 20:37: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 AE7A8129589 for ; Mon, 24 Oct 2016 20:37:49 -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 OvrtNdMZ9c6E for ; Mon, 24 Oct 2016 20:37:48 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 139B612957A for ; Mon, 24 Oct 2016 20:37:47 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id r16so110486254pfg.1 for ; Mon, 24 Oct 2016 20:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=LB/oRHCzYIDprODa7HJR6dGbbEz6y+w2bgcs1RnNRGQ=; b=qKs4sUYznPwwZN8F1pbFxSFa2McSbsKSNzyPFG3obOxrQN0RQq4cD4RNBEUz0k4cPn jTO3le/9/GPmgp/xEAcKdhMM8CS/Sae2/7u3GMkXQ2+r1d2OzGP3dl7b5Ri3hqQCwInl TPwNYhfM4akfaRPZbJUGQzGPWJf/WlH/wXyN9KnaT3S2lEr9BdRvehPvTaqptJ73+MgT 0zLVkPNlZTmgHnj4qL0ER5W+coRy0RTAoEUSuA3bC2udQbXXn6Yd/KwPsTklscDtj4Ej t+so5mjwg5UhPHBwijIsKPUQJkOrXN8UX85eEdLCN8NzXoYGTxvuRBdjwVMD2Avm0+5W g2/Q== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=LB/oRHCzYIDprODa7HJR6dGbbEz6y+w2bgcs1RnNRGQ=; b=BGhVSs1h2sqxlstvvPl8GluYbTyepJFxIVlDSnJnbcdum+Fd6CBtAAapB1P7ETcIU2 sjoa3Ol7qFrtDZ0IkMThquqaM3E+ntstxTMRIKC7niLyE6l+RVtcBVfpWIG01YvFa3HX sb61+Hj1Sa5Mx5ua1R3tXw9EsflCyLWjD5pOebxHCKS2/BVMUutmB+sr5rjlGckIytrL Rz+uzeLkkY2I1hlCug3im2RdTwsuN4G1ku6RLb19MRA3DbSXVWlIBU6pwe6OQlaGAvaA bm86aYT4DR/CWlPTjqli4OvbCtrFNLErzH08T5mQt5RxnZRX2jQ+7m9/jE/uGkjzpTYv QG+w== X-Gm-Message-State: ABUngveafxZVMf6ZmUA58S+rMCDPYStiNHVj5mNcbJisXImjUxGcZsrn2NNwXHoSnsBRzg== X-Received: by 10.99.110.14 with SMTP id j14mr29193978pgc.135.1477366667291; Mon, 24 Oct 2016 20:37:47 -0700 (PDT) Received: from ?IPv6:2406:e007:6593:1:28cc:dc4c:9703:6781? ([2406:e007:6593:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y189sm4524785pfy.34.2016.10.24.20.37.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 20:37:46 -0700 (PDT) To: v6ops@ietf.org References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> <309DEE56-AFF2-461D-97DE-391A51A6AEBC@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <671bee70-422d-786d-70bd-9d1317715e72@gmail.com> Date: Tue, 25 Oct 2016 16:37:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 03:37:50 -0000 Hemant, On 25/10/2016 14:24, Hemant Singh wrote: > Fred, > > I had heard the comments during a presentation at an IETF about intra vs. > extra net and NAT66 as a use case, especially Cisco as a company. My > apologies, if I incorrectly said anything.. Appreciate the RFC reference. > > Hemant > > On Mon, Oct 24, 2016 at 8:24 PM, Fred Baker > wrote: > >> >> >> Sent from my iPad >> >>> On Oct 24, 2016, at 3:03 PM, Hemant Singh wrote: >>> >>> In some instances between a large company intranet and extranet to >> its external vendors, NAT44 is used To be clear, that mode (first raised in the IETF by Bob Moskowitz, iirc, and the original inspiration for HIP) was only ever needed because of IPv4 address exhaustion and the fact that companies and their business partners were all using Net 10 internally. It's actually a nightmare, too, because translating Net 10 to Net 10 is... ugly. Which 10.1.1.1 did you actually mean? Yours or theirs? >>and thus a NAT66 draft was actually >> authored by Fred Baker. Indeed it wasn't, because it would be an utterly stupid thing to do for IPv6 - you might also look at https://tools.ietf.org/html/rfc4864. The fact that some open source NAT66 code exists doesn't make it a good idea. Regards Brian >> >> If you're going to invoke my name, you might consider getting your facts >> straight. Read RFC 6296, including the Security Considerations, before >> continuing. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Oct 25 05:42:37 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 7802B12954B for ; Tue, 25 Oct 2016 05:42:35 -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 iiy_nuEJDojK for ; Tue, 25 Oct 2016 05:42:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 54B35129691 for ; Tue, 25 Oct 2016 05:42:23 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id y2so96209612oie.0 for ; Tue, 25 Oct 2016 05:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=guCGvl5FyKU75uFOI441PGsidoUfvuqn9fGCDqCgoZI=; b=dqt0Aims2xK384iFZNWnpdtPMUPkHVU4+eebZb3onBOQczHTcl7/1vXNs17bX+7rlT vr8UhbMwKvb6ycbhHCmp4qpQPZYVpXpjAUiIohE/fvza6Pd8vmI0zJhZaUNE+TsPZN50 2hICry59V2KwqCY1zvAq3tklrgPJzazE0yxnYIFkrN5ttT/Osilu4G3KXmXc57Zd3FF8 DdZO1veG1zbKgAqjKe8PejnRenXnb9EIQuYxP+tkbxPePBtvypCayJnQ3VPeTMFUW0jW WnASeBmFRVDoggu4TAHYPgl2n5gSU9LhSYjPhX0s95pCeYoEHxadXaPeJKy/e5ZNF1VT bflA== 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=guCGvl5FyKU75uFOI441PGsidoUfvuqn9fGCDqCgoZI=; b=Ocm3FEc72BQccH2yI+FRM2TsQfr2aI1vXP/dEYLmWfmBDatHvr1Tq5XM324S0nRzBY Mx8crBm51KZelE0gNTT0ByRPRsW6fgRWbmdSnW01tg49Cf+m7hpMd0uqt9sLmxaBgYD+ l78A7nWvCwt6iZYajAx1ctyZUZlo0iOoXXmgo5MFAP2edDu6ZNRxmJltYhL3SR/fsgfj JH7tWv1bsNDnHX1Xss73db+Vlv3SdSKmynQt7Yvg1cMbrvHg/tVjY1JJyVobnfm9k8QH aD+Pc4DBpp3heseBAxeFKzVDw3Pkfctb98CKn8CMPS37IcuHBb1BmI13onMLubs7uK7y Ra/w== X-Gm-Message-State: AA6/9Rnkv4gaAZcapT9zhDSs24dm+5jjaA0u2bQ3nlKe30kSBnIjyvIT5eH9t/Nef0TTL0s+R1x8ywUo12YrrQ== X-Received: by 10.202.171.15 with SMTP id u15mr22894250oie.11.1477399342755; Tue, 25 Oct 2016 05:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.15.72 with HTTP; Tue, 25 Oct 2016 05:42:21 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Hemant Singh Date: Tue, 25 Oct 2016 08:42:21 -0400 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a113cd7360438b9053fafd7c9 Archived-At: Cc: v6ops list Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 12:42:35 -0000 --001a113cd7360438b9053fafd7c9 Content-Type: text/plain; charset=UTF-8 Sorry, I didn't recall Fred's doc was prefix and not address related - since Fred sent us the RFC, I realized it. Never mind NAT66, If the only support that Docker Container supports is NAT66 with ULA, it is clear, no one is using this Container. It's apples vs. oranges discussing apps vs. Containers. The app uses the IP address of the machine or the VM running on the machine. The machine, the VM, and the app communicate to any other node in the data center or even to an external node to the data center. In contrast, the Containers generate/acquire an IP address and, by default, do not communicate to any other node in the data center and thus have to be provisioning differently. The scale of Containers to provision for an IP/IPv6 address, networking, and firewall, is another challenge because it's one thing to provision one million bare-metal machines and another to provision 100 million Containers. Regards, Hemant On Mon, Oct 24, 2016 at 10:14 PM, Mark Smith wrote: > > Containers a light weight virtual machines, and VMs are virtualised > physical machines. > > How are and have people been securing 100s/1000s of physical machines > running apps? It's not a new problem caused by containers. > > Google and Facebook are providing large scale services over IPv6, I very > much doubt they're using ULAs with giant stateful NAT66 boxes in front of > all of them. > > > Sure, we should run this Container behavior by IETF app groups. > Operators who run large data centers are also welcome to chime in. In > some instances between a large company intranet and extranet to its > external vendors, NAT44 is used and thus a NAT66 draft was actually > authored by Fred Baker. > > > > If you're referring to Network Prefix Translation, it doesn't do or work > the way you think it does. > > You also might want to have a look at this: > > "The Trouble with NAT" > https://www.slideshare.net/mobile/MarkSmith214/ausnog- > 2016-the-trouble-with-nat > > Regards, > Mark. > > > --001a113cd7360438b9053fafd7c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I didn't recall Fred's doc was prefix and n= ot address related - since Fred sent us the RFC, I realized it.=C2=A0 Never= mind NAT66, =C2=A0If the only support that Docker Container supports is NA= T66 with ULA, it is clear, no one is using this Container. =C2=A0

<= /div>
It's apples vs. oranges discussing apps vs. Containers.=C2=A0= The app uses the IP address of the machine or the VM running on the machin= e. =C2=A0 The machine, the VM, and the app communicate to any other node in= the data center or even to an external node to the data center.=C2=A0 In c= ontrast, the Containers generate/acquire an IP address and, by default, do = not communicate to any other node in the data center and thus have to be pr= ovisioning differently.=C2=A0 The scale of Containers to provision for an I= P/IPv6 address, networking, and firewall, is another challenge because it&#= 39;s one thing to provision one million bare-metal machines and another to = provision 100 million Containers.

Regards,

Hemant

On Mon, Oct 24, 2016 at 10:14 PM, Mark Smith <m= arkzzzsmith@gmail.com> wrote:

Containers a light weight virtual machines, and VMs a= re virtualised physical machines.

How are and have people been securing 100s/1000s of physical= machines running apps? It's not a new problem caused by containers.
Google and Facebook are providing large scale services over = IPv6, I very much doubt they're using ULAs with giant stateful NAT66 bo= xes in front of all of them.

> =C2=A0 Sure, we should run this Container behavior by I= ETF app groups.=C2=A0 Operators who run large data centers are also welcome= to chime in. =C2=A0 In some instances between a large company intranet and= extranet to its external vendors, NAT44 is used and thus a NAT66 draft was= actually authored by Fred Baker. =C2=A0
>

If you're referring to Network Prefix Translation= , it doesn't do or work the way you think it does.

You also might want to have a look at this:

"The Trouble with NAT"
https://www.slideshare.net/mobile/M= arkSmith214/ausnog-2016-the-trouble-with-nat

Regards,
Mark.

--001a113cd7360438b9053fafd7c9-- From nobody Tue Oct 25 12:28:53 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 2783C129990 for ; Tue, 25 Oct 2016 12:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6XYenNApEvL4 for ; Tue, 25 Oct 2016 12:28:51 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 D67811298CE for ; Tue, 25 Oct 2016 12:28:50 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 20so15519805uak.6 for ; Tue, 25 Oct 2016 12:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SPbcIIXLOrzoXyio7TDh6tpjidUGDDIrhAoB8fdGp+k=; b=Q+KgJ4tnQRsWPKQJ+9VVAjs3xNBSZkuXYjnfI6S76lW8/DLUHwseN5A7Fzze5PP6GK uUkbtIBsEHYRJ1TEdESElWUubZtz1Qg3Tkrrt8N2kOWRgFMtPr/tFpoNi8eXHcErIygA BfEL9HLCIsZ+3Akr0Tr4MVs06wZrIzvfBk1HW8DPP1BNX6R5KXAWtRNZPHB1A1Xb/eii vQkehycIsg6ZGolBIxR84kmzas2g8Q7Fl/A2fvo5SYyGiERRPXP7D5ZrzuS2NuZ/y90U WUYdfIvgyStdPofPiAdPlJ11w2VoY7nREJTkPipmxxcFT7eiCAWJ0thbeO8QqtjcmsUm SjLQ== 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=SPbcIIXLOrzoXyio7TDh6tpjidUGDDIrhAoB8fdGp+k=; b=ZQRC/VLrTpoxtd37yNW2DkkFBz6hzANtkEr9LtdiVCwtSdGmYxelUKnDJqqT0TIu/1 hLmQz+iAJ0t52oWmbouGzOFVXoJnhWKCwQG3U6sKztqNYViYZJjv9wGxaVFoNvyALE9H DTo1XDuLcz9SSDmow7Abgt+hWIQnP6wLCUUSDEuZQj8lpbLuROdEklVGys7FDfeAIzZC WJ0qC4LieefmhnxHD+dUPsqB4gSxJ3ehOJAVzY/OAU/FQShZj7lorziq9Ej/NCTDN/s/ H8Z63oqpU84K5U5OKIbSjUc8ii2ltrIO5aheIOmjQMWlScWXH9SVoA8OS+JOJPf8AgTE +ZAw== X-Gm-Message-State: ABUngvfOkZG67P3DTkLLUUmeF+sUqKeOYBn3eywAD9Z5+yMsn6T7akY1NK+Nrr7ER/lH4UZzmIhSM5xuE1h4HQ== X-Received: by 10.159.39.68 with SMTP id a62mr14399257uaa.95.1477423729837; Tue, 25 Oct 2016 12:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Tue, 25 Oct 2016 12:28:19 -0700 (PDT) In-Reply-To: References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> From: Mark Smith Date: Wed, 26 Oct 2016 06:28:19 +1100 Message-ID: To: Hemant Singh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 19:28:52 -0000 On 25 October 2016 at 23:42, Hemant Singh wrote: > Sorry, I didn't recall Fred's doc was prefix and not address related - since > Fred sent us the RFC, I realized it. Never mind NAT66, If the only support > that Docker Container supports is NAT66 with ULA, it is clear, no one is > using this Container. > > It's apples vs. oranges discussing apps vs. Containers. The app uses the IP > address of the machine or the VM running on the machine. With IPv6 it doesn't need to. It would be quite possible to give a container its own IPv6 address, and I think that is the assumption that is commonly being made here (because containers are nothing more than with light weight VMs, with the only significant differences been faster startup times and the ability run many more on the same physical machine). It would even be possible for each application component within a container to have its own IPv6 address. So much more is possible and conceivable because of IPv6's so much larger address space than IPv4's. > The machine, the > VM, and the app communicate to any other node in the data center or even to > an external node to the data center. In contrast, the Containers > generate/acquire an IP address and, by default, do not communicate to any > other node in the data center and thus have to be provisioning differently. > The scale of Containers to provision for an IP/IPv6 address, networking, and > firewall, is another challenge because it's one thing to provision one > million bare-metal machines and another to provision 100 million Containers. > We solve these problems the same way we commonly solve them - scalably using a divide-and-conquer approach - slice the problem up into smaller versions and then solve the multiple instances of the same smaller problem. Delegating prefixes to physical or virtual machines for use with containers is the exact same technique that has been used to scale the Internet's routing system. Delegation of an aggregate, and then sub-division downstream of the aggregate, hidden from the upstream. Regards, Mark. > Regards, > > Hemant > > > On Mon, Oct 24, 2016 at 10:14 PM, Mark Smith wrote: >> >> >> Containers a light weight virtual machines, and VMs are virtualised >> physical machines. >> >> How are and have people been securing 100s/1000s of physical machines >> running apps? It's not a new problem caused by containers. >> >> Google and Facebook are providing large scale services over IPv6, I very >> much doubt they're using ULAs with giant stateful NAT66 boxes in front of >> all of them. >> >> > Sure, we should run this Container behavior by IETF app groups. >> > Operators who run large data centers are also welcome to chime in. In some >> > instances between a large company intranet and extranet to its external >> > vendors, NAT44 is used and thus a NAT66 draft was actually authored by Fred >> > Baker. >> > >> >> If you're referring to Network Prefix Translation, it doesn't do or work >> the way you think it does. >> >> You also might want to have a look at this: >> >> "The Trouble with NAT" >> >> https://www.slideshare.net/mobile/MarkSmith214/ausnog-2016-the-trouble-with-nat >> >> Regards, >> Mark. >> >> > From nobody Tue Oct 25 12:38:37 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 F3B591299B2 for ; Tue, 25 Oct 2016 12:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[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, 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 WthE7SGwfGvw for ; Tue, 25 Oct 2016 12:38:36 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 D8CF91299A9 for ; Tue, 25 Oct 2016 12:38:35 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id y123so13607894vka.3 for ; Tue, 25 Oct 2016 12:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NvBODbbKxBmEIYTjkievke6jNoPbiz+1hcUduBxnaCM=; b=YEsHmpFC/1A4VVGDReO+sTGxnRbBaq6QPJrM9GnW2L8pD3UttGCD6WxkhorfJO3bja oCvEkvBrLa3aGiqZptmnccqeqLZW1/FU2YYtUnqCe6E5KTW0Pz3g4RMjpvNt8ofwDTYT XHtlRrwe3n/IKLqZv5P5AHtyirWiUsJl3au59Hze2u8dPBtPv+HJGLvXigot+Q1ynHIg INfxvOPiLQd6PmoBGyR530E6zfiNr/Ax9uAKwt1Grqi9vJdmZ9qFD1AQXSPXi6FDWZYw ACmogv8f86bQW0sSnm1f6OnZ7c4Eytll8UaQRjwo6LQ458U4UEMOQ5S06icj0ITrexIW TCwQ== 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=NvBODbbKxBmEIYTjkievke6jNoPbiz+1hcUduBxnaCM=; b=gAs/DTg7K5ILtub/bg19UzEKFq3GbhLPcXBaXR1WirQ6Jv6pUmx4Bh6lnx9kLGu+9i 1Vfy6lK2sikmZyD0Hcu7T2Zy6hVvD/mBdUsp4zD53LId8CjAwRk3uS15zv5ZfwyBD/RA 8wtSmhlPUZwghVotzJn3EOoYnL6nQKbg6Hok1GWOl0NTlguWfKkCTJIsAUbUPd+ZBGnP vFb1eJH+FmE7V3XipdUTKkHzgkDUcjF5tVy/kGqYugxhAQoXt/BKyR/y4zm5hKj6mMvV fQ6Uu40osmT1WPLBCAh7VsLSwtdqO4F294ylctVi6MpC16Kzx1/30WVW80EqM71rFNxk rAQw== X-Gm-Message-State: ABUngveUpp2eOh3jFbYDL+tuvJviR1TNoxi8mdzVzU+EYxr5U3dysAG+XQYG8El7nKv3mD3EPoj1klWzU0R4Mg== X-Received: by 10.31.16.207 with SMTP id 76mr15369800vkq.169.1477424314941; Tue, 25 Oct 2016 12:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Tue, 25 Oct 2016 12:38:04 -0700 (PDT) In-Reply-To: <671bee70-422d-786d-70bd-9d1317715e72@gmail.com> References: <9031E4E6-878C-45A6-B30A-0D220F5BAFDA@gmail.com> <309DEE56-AFF2-461D-97DE-391A51A6AEBC@gmail.com> <671bee70-422d-786d-70bd-9d1317715e72@gmail.com> From: Mark Smith Date: Wed, 26 Oct 2016 06:38:04 +1100 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] unique-ipv6-prefix-per-host Will Unsolicited RA be sent in this model? 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, 25 Oct 2016 19:38:37 -0000 On 25 October 2016 at 14:37, Brian E Carpenter wrote: > Hemant, > On 25/10/2016 14:24, Hemant Singh wrote: >> Fred, >> >> I had heard the comments during a presentation at an IETF about intra vs. >> extra net and NAT66 as a use case, especially Cisco as a company. My >> apologies, if I incorrectly said anything.. Appreciate the RFC reference. >> >> Hemant >> >> On Mon, Oct 24, 2016 at 8:24 PM, Fred Baker >> wrote: >> >>> >>> >>> Sent from my iPad >>> >>>> On Oct 24, 2016, at 3:03 PM, Hemant Singh wrote: >>>> >>>> In some instances between a large company intranet and extranet to >>> its external vendors, NAT44 is used > > To be clear, that mode (first raised in the IETF by Bob Moskowitz, iirc, > and the original inspiration for HIP) was only ever needed because of > IPv4 address exhaustion and the fact that companies and their business > partners were all using Net 10 internally. It's actually a nightmare, too, > because translating Net 10 to Net 10 is... ugly. Which 10.1.1.1 did > you actually mean? Yours or theirs? > It certainly is. One of the lessons I learnt from working with two NATs facing each other and duplicated address spaces behind them is to place more significant value on the global uniqueness of addresses. For operating and troubleshooting a network, it is immensely useful to be in a position to say "that packet could have only come from or be going to host X", regardless of where host X is. In IPv4 we had no choice but to consume globally routable addresses to achieve this global uniqueness, even if we didn't intend or need host X to have global connectivity. In IPv6, we have two choices. If host X needs to have both a globally unique address and have global reachability, give it a GUA. If only a globally unique address is required, give it a (properly formed) ULA. (Or combinations of the two for different use cases.) Regards, Mark. From nobody Wed Oct 26 12:13:32 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 832AE1298BF for ; Wed, 26 Oct 2016 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 9YXyNxn6o1RK for ; Wed, 26 Oct 2016 12:13:28 -0700 (PDT) Received: from tor-smtp-01.primus.ca (smtp-auth2-165.primus.ca [216.254.140.165]) by ietfa.amsl.com (Postfix) with ESMTP id 36ECB129898 for ; Wed, 26 Oct 2016 12:13:28 -0700 (PDT) Received: from [24.114.82.250] (helo=[172.20.10.4]) by tor-smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bzTdZ-0003RT-Hl; Wed, 26 Oct 2016 15:13:21 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2-985790251 From: Philip Matthews In-Reply-To: Date: Wed, 26 Oct 2016 15:13:16 -0400 Message-Id: References: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> To: Hemant Singh X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.82.250] Archived-At: Cc: v6ops list Subject: Re: [v6ops] IETF meeting with IPv6 routes over IPv4? 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, 26 Oct 2016 19:13:30 -0000 --Apple-Mail-2-985790251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hemant: I don't think that was the reason. I know of a number of networks = running IPv4 MPLS that carry IPv6 BGP routes over IPv6 transport. -Philip On 2016-10-24, at 17:51 , Hemant Singh wrote: > I suspect it would have been a MPLS network which supported only IPv4 = MPLS at the time and thus carried IPv6 BGP routers over IPv4 transport. =20= >=20 > Hemant >=20 >=20 > On Mon, Oct 24, 2016 at 4:52 PM, Philip Matthews = wrote: > I have a memory that there was an IETF meeting some years ago where = the IPv6 connectivity used BGP sessions where the IPv6 routes were = carried over an BGP session that ran over IPv4 transport. Does anyone = remember which meeting that was, and why this was done? We are updating = the BGP section in the Design Choices draft and are considering = mentioning this. >=20 > -Philip > _______________________________________________ --Apple-Mail-2-985790251 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I suspect it would have been a MPLS network which supported = only IPv4 MPLS at the time and thus carried IPv6 BGP routers over IPv4 = transport.

Hemant

On Mon, Oct 24, = 2016 at 4:52 PM, Philip Matthews <philip_matthews@magma.ca> = wrote:
I have a memory that = there was an IETF meeting some years ago where the IPv6 connectivity = used BGP sessions where the IPv6 routes were carried over an BGP session = that ran over IPv4 transport. Does anyone remember which meeting = that was, and why this was done? We are updating the BGP section = in the Design Choices draft and are considering mentioning this.

-Philip
= _______________________________________________

= --Apple-Mail-2-985790251-- From nobody Fri Oct 28 14:04:41 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 9D5791295A4; Fri, 28 Oct 2016 14:04:35 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 14:04:35 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.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, 28 Oct 2016 21:04:35 -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 : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-11.txt Pages : 26 Date : 2016-10-28 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-11 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 Fri Oct 28 14:09: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 83601129498 for ; Fri, 28 Oct 2016 14:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 L1zMihfMlul6 for ; Fri, 28 Oct 2016 14:09:20 -0700 (PDT) Received: from tor-smtp-03.primus.ca (smtp-auth2-130.primus.ca [216.254.140.130]) by ietfa.amsl.com (Postfix) with ESMTP id 15B69129450 for ; Fri, 28 Oct 2016 14:09:20 -0700 (PDT) Received: from [24.114.83.157] (helo=[172.20.10.4]) by tor-smtp-03.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c0EOo-00010C-ER; Fri, 28 Oct 2016 17:09:14 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 17:09:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.83.157] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 28 Oct 2016 21:09:22 -0000 Folks: We have just published the -11 revision of the Design Choices draft. The main change in this revision is totally new text for the Addresses = section. We have totally rewritten this section after the comments we = received in Yokohama (yes, one year ago, sigh). We also took into = account the comments made by Brian Carpenter about 10 days ago, though = we didn't structure the section the way he suggested. The other significant change the addition of the scenario of using = OSPFv3 to route both IPv4 and IPv6. Thanks to John Mann for pointing = out this omission. Unfortunately, we don't know of anyone actually = running this combination in a non-trivial production network -- email = the authors privately if you have data you are willing to share. It is our belief that this revision addresses the concerns people had = with previous versions, and that all that is required is a perhaps a few = minor tweaks before it is finished off. Let us know if you agree or = disagree. This draft has been in the works for a long time. Hopefully we are = getting close to the end. - Philip and Victor On 2016-10-28, at 17:04 , internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Some Design Choices for IPv6 Networks > Authors : Philip Matthews > Victor Kuarsingh > Filename : draft-ietf-v6ops-design-choices-11.txt > Pages : 26 > Date : 2016-10-28 >=20 > Abstract: > This document presents advice on certain routing-related design > choices that arise when designing IPv6 networks (both dual-stack and > IPv6-only). The intended audience is someone designing an IPv6 > network who is knowledgeable about best current practices around = IPv4 > network design, and wishes to learn the corresponding practices for > IPv6. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-design-choices-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Oct 28 15:00: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 82BF81294DB for ; Fri, 28 Oct 2016 15:00:49 -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, 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 uOn047spjPqJ for ; Fri, 28 Oct 2016 15:00:47 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c: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 BC9EE129481 for ; Fri, 28 Oct 2016 15:00:46 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d65so37237653vkg.0 for ; Fri, 28 Oct 2016 15:00:46 -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=ew6dfl/hvbII10tDIQbdV3O72VXhxiFmW3HfcmyXfUQ=; b=WxqcN9wL4Vo3LOCsl5kcsDhvGImMI9fxkXWh0pQQejkf0YgayTwVpleq/Thneya0PM BFeFG96/MtydwmOmTMPOWh5b4xbSiZMDUe/UKOzBHGCeGPuXIHZtmi58pTsSxoyBYoce Mx4gk1671oMONY25Y86jNd2lIG/gabwfx/6mYnb/p3mAPASWI4td9b50q8V6Gshjykf4 +o4ZgerUB0G4dDUTmOJHeH65f0cXcSOyQedfDnEqFZaIJH0UPNEfvTI+ST0dPhfKnxNW xRFp6+8NNdw0xs6got4ziOrjWkOzqvfAd7I+lwX2GhZ3manAJ5QR/+nKafX5tJCG3PPa O2AQ== 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=ew6dfl/hvbII10tDIQbdV3O72VXhxiFmW3HfcmyXfUQ=; b=Fw6wRGzDVcuFbbdK7lpuuupS2HMVkMk6hzKcv791TnMjdy/qnX4eS3xlOjYRwKoeAd 6l7D9nIjc76XF/hSD1WR2578HQWddeERYnXp1M2Q9crgKOJQC2KaeCLT0n73qCEBZc8/ dng/3Fmvyz2at1b7ztYNvAQ+UBqUQ7s7qtjR1r/r5xgj2PdkVPM7ZmWr8Vj0nc5P+YVR P6JtIL5izXR7odwruVSSQ6yUgRJrrZUgj/OKInH+imW35LnVnQOGnbH/xlI4T9Wjnvkd +JANMtRFGjqiHfytUM2DZKnoeKZt+rIXCXVVzRqye5vFD0x6VwAzJQqmsoeSiK4XZ9uQ haOA== X-Gm-Message-State: ABUngvcwYLtlbB6h2eiCwMPx5/vuGElqYf8CpzpfYzwnIo2R6umTm/yL3WDyOr9m4QmsAgYhvF4X2IRhkxYJEQ== X-Received: by 10.31.78.5 with SMTP id c5mr13790167vkb.169.1477692045703; Fri, 28 Oct 2016 15:00:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Fri, 28 Oct 2016 15:00:45 -0700 (PDT) Received: by 10.176.16.79 with HTTP; Fri, 28 Oct 2016 15:00:45 -0700 (PDT) In-Reply-To: <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> From: Mark Smith Date: Sat, 29 Oct 2016 09:00:45 +1100 Message-ID: To: Philip Matthews Content-Type: multipart/alternative; boundary=001a114847da78c085053ff3fd9b Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 28 Oct 2016 22:00:49 -0000 --001a114847da78c085053ff3fd9b Content-Type: text/plain; charset=UTF-8 There's still IPv4 mentality here: "In IPv6, all interfaces are assigned a Link-Local Address (LLA) [ref]. The Link-Local address can only be used for communicating with devices that are on-link, so often additional addresses are assigned which are able to communicate off-link. These additional addresses can be one of three types:" The last sentence is reading GUA PI xor GUA PA xor ULA, implying IPv6 interfaces only support a single LLA and a single other address, which is not the case. I think it is also implying that address assignments to nodes are semi-permanent rather than more dynamic, as supported by IPv6 address lifetimes. If this draft is reflecting how people are deploying IPv6, then I think it is reflecting an IPv4 mentality applied to IPv6. I don't think that is a very useful thing to publish as advice on deploying IPv6, as it isn't identifying opportunities to take advantages that IPv6 provides and IPv4 does not. If we want to go down that path, then I think it would be better to state that this is a snapshot of current deployments, point out that they are IPv4 oriented IPv6 deployments, and identify capabilities of IPv6 that are not being taken advantage of that would provide operational and end-user application advantages. The cost of developing and deploying IPv6 has been and will continue to high for quite a while, so I think we should be looking to take advantage of its capabilities as often as possible to maximise the return on those costs. Some of what I wrote here is taking a "how to do IPv6 better than IPv4" perspective which I think is the one the v6ops group should be taking. https://blog.apnic.net/2016/10/27/trouble-nat-part-3/ Regards, Mark. On 29 Oct. 2016 8:09 am, "Philip Matthews" wrote: > > Folks: > > We have just published the -11 revision of the Design Choices draft. > > The main change in this revision is totally new text for the Addresses section. We have totally rewritten this section after the comments we received in Yokohama (yes, one year ago, sigh). We also took into account the comments made by Brian Carpenter about 10 days ago, though we didn't structure the section the way he suggested. > > The other significant change the addition of the scenario of using OSPFv3 to route both IPv4 and IPv6. Thanks to John Mann for pointing out this omission. Unfortunately, we don't know of anyone actually running this combination in a non-trivial production network -- email the authors privately if you have data you are willing to share. > > It is our belief that this revision addresses the concerns people had with previous versions, and that all that is required is a perhaps a few minor tweaks before it is finished off. Let us know if you agree or disagree. > > This draft has been in the works for a long time. Hopefully we are getting close to the end. > > - Philip and Victor > > > On 2016-10-28, at 17:04 , internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IPv6 Operations of the IETF. > > > > Title : Some Design Choices for IPv6 Networks > > Authors : Philip Matthews > > Victor Kuarsingh > > Filename : draft-ietf-v6ops-design-choices-11.txt > > Pages : 26 > > Date : 2016-10-28 > > > > Abstract: > > This document presents advice on certain routing-related design > > choices that arise when designing IPv6 networks (both dual-stack and > > IPv6-only). The intended audience is someone designing an IPv6 > > network who is knowledgeable about best current practices around IPv4 > > network design, and wishes to learn the corresponding practices for > > IPv6. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-11 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-11 > > > > > > 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/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114847da78c085053ff3fd9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's still IPv4 mentality here:

"In IPv6, all interfaces are assigned a Link-Local Addr= ess (LLA) [ref]. The Link-Local address can only be used for communicating = with devices that are on-link, so often additional addresses are assigned w= hich are able to communicate off-link. These additional addresses can be on= e of three types:"

The last sentence is reading GUA PI xor GUA PA xor ULA, impl= ying IPv6 interfaces only support a single LLA and a single other address, = which is not the case. I think it is also implying that address assignments= to nodes are semi-permanent rather than more dynamic, as supported by IPv6= address lifetimes.

If this draft is reflecting how people are deploying IPv6, t= hen I think it is reflecting an IPv4 mentality applied to IPv6. I don't= think that is a very useful thing to publish as advice on deploying IPv6, = as it isn't identifying opportunities to take advantages that IPv6 prov= ides and IPv4 does not.

If we want to go down that path, then I think it would be be= tter to state that this is a snapshot of current deployments, point out tha= t they are IPv4 oriented IPv6 deployments, and identify capabilities of IPv= 6 that are not being taken advantage of that would provide operational and = end-user application advantages.

The cost of developing and deploying IPv6 has been and will = continue to high for quite a while, so I think we should be looking to take= advantage of its capabilities as often as possible to maximise the return = on those costs. Some of what I wrote here is taking a "how to do IPv6 = better than IPv4" perspective which I think is the one the v6ops group= should be taking.

https://blog.apnic.net/2016/10/27/trouble-nat-part-3/

Regards,
Mark.

On 29 Oct. 2016 8:09 am, "Philip Matthews" <philip_matthews@magma.ca> w= rote:
>
> Folks:
>
> We have just published the -11 revision of the Design Choices draft. >
> The main change in this revision is totally new text for the Addresses= section. We have totally rewritten this section after the comments we rece= ived in Yokohama (yes, one year ago, sigh). We also took into account the c= omments made by Brian Carpenter about 10 days ago, though we didn't str= ucture the section the way he suggested.
>
> The other significant change the addition of the scenario of using OSP= Fv3 to route both IPv4 and IPv6.=C2=A0 Thanks to John Mann for pointing out= this omission. Unfortunately, we don't know of anyone actually running= this combination in a non-trivial production network -- email the authors = privately if you have data you are willing to share.
>
> It is our belief that this revision addresses the concerns people had = with previous versions, and that all that is required is a perhaps a few mi= nor tweaks before it is finished off.=C2=A0 Let us know if you agree or dis= agree.
>
> This draft has been in the works for a long time.=C2=A0 Hopefully we a= re getting close to the end.
>
> - Philip and Victor
>
>
> On 2016-10-28, at 17:04 , = internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > This draft is a work item of the IPv6 Operations of the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Some Design Choices for IPv6 Networks
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Philip Matthews
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Victor Kuarsingh
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-v6ops-design-choices-11.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 26
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2016-10-28
> >
> > Abstract:
> >=C2=A0 =C2=A0This document presents advice on certain routing-rela= ted design
> >=C2=A0 =C2=A0choices that arise when designing IPv6 networks (both= dual-stack and
> >=C2=A0 =C2=A0IPv6-only).=C2=A0 The intended audience is someone de= signing an IPv6
> >=C2=A0 =C2=A0network who is knowledgeable about best current pract= ices around IPv4
> >=C2=A0 =C2=A0network design, and wishes to learn the corresponding= practices for
> >=C2=A0 =C2=A0IPv6.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choic= es/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-11
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-desi= gn-choices-11
> >
> >
> > 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.or= g/internet-drafts/
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
--001a114847da78c085053ff3fd9b-- From nobody Fri Oct 28 16:25: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 0E9CB129435 for ; Fri, 28 Oct 2016 16:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 xFHsuVqT-hwT for ; Fri, 28 Oct 2016 16:25:22 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 37CD2129463 for ; Fri, 28 Oct 2016 16:25:21 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 601F0C15F8 for ; Fri, 28 Oct 2016 18:25:21 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id CB893C14E6; Fri, 28 Oct 2016 18:25:20 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 840FA92065; Fri, 28 Oct 2016 19:25:20 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 64BB092053; Fri, 28 Oct 2016 19:25:20 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 28 Oct 2016 19:25:20 -0400 (EDT) Received: from PWN401EA103.ent.corp.bcbsm.com (10.64.140.237) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Oct 2016 19:25:20 -0400 Received: from PWN401EA120.ent.corp.bcbsm.com ([169.254.12.199]) by PWN401EA103.ent.corp.bcbsm.com ([10.64.140.237]) with mapi id 14.03.0319.002; Fri, 28 Oct 2016 19:25:19 -0400 From: "Ackermann, Michael" To: Mark Smith , Philip Matthews Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt Thread-Index: AQHSMV8K1aRR5a6v9E62LkpV07TxIKC+n10AgAAOaoD//9QE8A== Date: Fri, 28 Oct 2016 23:25:18 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0DC2CD35PWN401EA120entc_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 1ad1934c-82c9-448f-a6d3-8cc87614ce56 X-VPM-MSG-ID: 93e9e937-280b-4cb8-989b-870afdbf016e X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 28 Oct 2016 23:25:25 -0000 --_000_4FC37E442D05A748896589E468752CAA0DC2CD35PWN401EA120entc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgc29tZW9uZSB0cnlpbmcgdmVyeSBoYXJkIHRvIGdldCBFbnRlcnByaXNlcyB0byBpbXBs ZW1lbnQgSVB2NiAoYW5kIG5vdCBzdWNjZWVkaW5nKSwgIGFueXRoaW5nIHRoYXQgcG9pbnRz IG91dCBhZHZhbnRhZ2VzIG92ZXIgSVB2NCBpcyB2ZXJ5IGNvbXBlbGxpbmcuDQpTbyBhICsx IG9uIE1hcmtzIGNvbW1lbnRzLg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJrIFNtaXRoDQpTZW50OiBGcmlkYXksIE9j dG9iZXIgMjgsIDIwMTYgNjowMSBQTQ0KVG86IFBoaWxpcCBNYXR0aGV3cyA8cGhpbGlwX21h dHRoZXdzQG1hZ21hLmNhPg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24t Y2hvaWNlcy0xMS50eHQNCg0KDQpUaGVyZSdzIHN0aWxsIElQdjQgbWVudGFsaXR5IGhlcmU6 DQoNCiJJbiBJUHY2LCBhbGwgaW50ZXJmYWNlcyBhcmUgYXNzaWduZWQgYSBMaW5rLUxvY2Fs IEFkZHJlc3MgKExMQSkgW3JlZl0uIFRoZSBMaW5rLUxvY2FsIGFkZHJlc3MgY2FuIG9ubHkg YmUgdXNlZCBmb3IgY29tbXVuaWNhdGluZyB3aXRoIGRldmljZXMgdGhhdCBhcmUgb24tbGlu aywgc28gb2Z0ZW4gYWRkaXRpb25hbCBhZGRyZXNzZXMgYXJlIGFzc2lnbmVkIHdoaWNoIGFy ZSBhYmxlIHRvIGNvbW11bmljYXRlIG9mZi1saW5rLiBUaGVzZSBhZGRpdGlvbmFsIGFkZHJl c3NlcyBjYW4gYmUgb25lIG9mIHRocmVlIHR5cGVzOiINCg0KVGhlIGxhc3Qgc2VudGVuY2Ug aXMgcmVhZGluZyBHVUEgUEkgeG9yIEdVQSBQQSB4b3IgVUxBLCBpbXBseWluZyBJUHY2IGlu dGVyZmFjZXMgb25seSBzdXBwb3J0IGEgc2luZ2xlIExMQSBhbmQgYSBzaW5nbGUgb3RoZXIg YWRkcmVzcywgd2hpY2ggaXMgbm90IHRoZSBjYXNlLiBJIHRoaW5rIGl0IGlzIGFsc28gaW1w bHlpbmcgdGhhdCBhZGRyZXNzIGFzc2lnbm1lbnRzIHRvIG5vZGVzIGFyZSBzZW1pLXBlcm1h bmVudCByYXRoZXIgdGhhbiBtb3JlIGR5bmFtaWMsIGFzIHN1cHBvcnRlZCBieSBJUHY2IGFk ZHJlc3MgbGlmZXRpbWVzLg0KDQpJZiB0aGlzIGRyYWZ0IGlzIHJlZmxlY3RpbmcgaG93IHBl b3BsZSBhcmUgZGVwbG95aW5nIElQdjYsIHRoZW4gSSB0aGluayBpdCBpcyByZWZsZWN0aW5n IGFuIElQdjQgbWVudGFsaXR5IGFwcGxpZWQgdG8gSVB2Ni4gSSBkb24ndCB0aGluayB0aGF0 IGlzIGEgdmVyeSB1c2VmdWwgdGhpbmcgdG8gcHVibGlzaCBhcyBhZHZpY2Ugb24gZGVwbG95 aW5nIElQdjYsIGFzIGl0IGlzbid0IGlkZW50aWZ5aW5nIG9wcG9ydHVuaXRpZXMgdG8gdGFr ZSBhZHZhbnRhZ2VzIHRoYXQgSVB2NiBwcm92aWRlcyBhbmQgSVB2NCBkb2VzIG5vdC4NCg0K SWYgd2Ugd2FudCB0byBnbyBkb3duIHRoYXQgcGF0aCwgdGhlbiBJIHRoaW5rIGl0IHdvdWxk IGJlIGJldHRlciB0byBzdGF0ZSB0aGF0IHRoaXMgaXMgYSBzbmFwc2hvdCBvZiBjdXJyZW50 IGRlcGxveW1lbnRzLCBwb2ludCBvdXQgdGhhdCB0aGV5IGFyZSBJUHY0IG9yaWVudGVkIElQ djYgZGVwbG95bWVudHMsIGFuZCBpZGVudGlmeSBjYXBhYmlsaXRpZXMgb2YgSVB2NiB0aGF0 IGFyZSBub3QgYmVpbmcgdGFrZW4gYWR2YW50YWdlIG9mIHRoYXQgd291bGQgcHJvdmlkZSBv cGVyYXRpb25hbCBhbmQgZW5kLXVzZXIgYXBwbGljYXRpb24gYWR2YW50YWdlcy4NCg0KVGhl IGNvc3Qgb2YgZGV2ZWxvcGluZyBhbmQgZGVwbG95aW5nIElQdjYgaGFzIGJlZW4gYW5kIHdp bGwgY29udGludWUgdG8gaGlnaCBmb3IgcXVpdGUgYSB3aGlsZSwgc28gSSB0aGluayB3ZSBz aG91bGQgYmUgbG9va2luZyB0byB0YWtlIGFkdmFudGFnZSBvZiBpdHMgY2FwYWJpbGl0aWVz IGFzIG9mdGVuIGFzIHBvc3NpYmxlIHRvIG1heGltaXNlIHRoZSByZXR1cm4gb24gdGhvc2Ug Y29zdHMuIFNvbWUgb2Ygd2hhdCBJIHdyb3RlIGhlcmUgaXMgdGFraW5nIGEgImhvdyB0byBk byBJUHY2IGJldHRlciB0aGFuIElQdjQiIHBlcnNwZWN0aXZlIHdoaWNoIEkgdGhpbmsgaXMg dGhlIG9uZSB0aGUgdjZvcHMgZ3JvdXAgc2hvdWxkIGJlIHRha2luZy4NCg0KaHR0cHM6Ly9i bG9nLmFwbmljLm5ldC8yMDE2LzEwLzI3L3Ryb3VibGUtbmF0LXBhcnQtMy8NCg0KUmVnYXJk cywNCk1hcmsuDQoNCk9uIDI5IE9jdC4gMjAxNiA4OjA5IGFtLCAiUGhpbGlwIE1hdHRoZXdz IiA8cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPG1haWx0bzpwaGlsaXBfbWF0dGhld3NAbWFn bWEuY2E+PiB3cm90ZToNCj4NCj4gRm9sa3M6DQo+DQo+IFdlIGhhdmUganVzdCBwdWJsaXNo ZWQgdGhlIC0xMSByZXZpc2lvbiBvZiB0aGUgRGVzaWduIENob2ljZXMgZHJhZnQuDQo+DQo+ IFRoZSBtYWluIGNoYW5nZSBpbiB0aGlzIHJldmlzaW9uIGlzIHRvdGFsbHkgbmV3IHRleHQg Zm9yIHRoZSBBZGRyZXNzZXMgc2VjdGlvbi4gV2UgaGF2ZSB0b3RhbGx5IHJld3JpdHRlbiB0 aGlzIHNlY3Rpb24gYWZ0ZXIgdGhlIGNvbW1lbnRzIHdlIHJlY2VpdmVkIGluIFlva29oYW1h ICh5ZXMsIG9uZSB5ZWFyIGFnbywgc2lnaCkuIFdlIGFsc28gdG9vayBpbnRvIGFjY291bnQg dGhlIGNvbW1lbnRzIG1hZGUgYnkgQnJpYW4gQ2FycGVudGVyIGFib3V0IDEwIGRheXMgYWdv LCB0aG91Z2ggd2UgZGlkbid0IHN0cnVjdHVyZSB0aGUgc2VjdGlvbiB0aGUgd2F5IGhlIHN1 Z2dlc3RlZC4NCj4NCj4gVGhlIG90aGVyIHNpZ25pZmljYW50IGNoYW5nZSB0aGUgYWRkaXRp b24gb2YgdGhlIHNjZW5hcmlvIG9mIHVzaW5nIE9TUEZ2MyB0byByb3V0ZSBib3RoIElQdjQg YW5kIElQdjYuICBUaGFua3MgdG8gSm9obiBNYW5uIGZvciBwb2ludGluZyBvdXQgdGhpcyBv bWlzc2lvbi4gVW5mb3J0dW5hdGVseSwgd2UgZG9uJ3Qga25vdyBvZiBhbnlvbmUgYWN0dWFs bHkgcnVubmluZyB0aGlzIGNvbWJpbmF0aW9uIGluIGEgbm9uLXRyaXZpYWwgcHJvZHVjdGlv biBuZXR3b3JrIC0tIGVtYWlsIHRoZSBhdXRob3JzIHByaXZhdGVseSBpZiB5b3UgaGF2ZSBk YXRhIHlvdSBhcmUgd2lsbGluZyB0byBzaGFyZS4NCj4NCj4gSXQgaXMgb3VyIGJlbGllZiB0 aGF0IHRoaXMgcmV2aXNpb24gYWRkcmVzc2VzIHRoZSBjb25jZXJucyBwZW9wbGUgaGFkIHdp dGggcHJldmlvdXMgdmVyc2lvbnMsIGFuZCB0aGF0IGFsbCB0aGF0IGlzIHJlcXVpcmVkIGlz IGEgcGVyaGFwcyBhIGZldyBtaW5vciB0d2Vha3MgYmVmb3JlIGl0IGlzIGZpbmlzaGVkIG9m Zi4gIExldCB1cyBrbm93IGlmIHlvdSBhZ3JlZSBvciBkaXNhZ3JlZS4NCj4NCj4gVGhpcyBk cmFmdCBoYXMgYmVlbiBpbiB0aGUgd29ya3MgZm9yIGEgbG9uZyB0aW1lLiAgSG9wZWZ1bGx5 IHdlIGFyZSBnZXR0aW5nIGNsb3NlIHRvIHRoZSBlbmQuDQo+DQo+IC0gUGhpbGlwIGFuZCBW aWN0b3INCj4NCj4NCj4gT24gMjAxNi0xMC0yOCwgYXQgMTc6MDQgLCBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+ DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIG9mIHRoZSBJRVRGLg0KPiA+ DQo+ID4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNvbWUgRGVzaWduIENob2ljZXMgZm9y IElQdjYgTmV0d29ya3MNCj4gPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUGhpbGlwIE1h dHRoZXdzDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIFZpY3RvciBLdWFyc2luZ2gN Cj4gPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1j aG9pY2VzLTExLnR4dA0KPiA+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDI2DQo+ID4gICAg ICAgRGF0ZSAgICAgICAgICAgIDogMjAxNi0xMC0yOA0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ ID4gICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGFkdmljZSBvbiBjZXJ0YWluIHJvdXRpbmct cmVsYXRlZCBkZXNpZ24NCj4gPiAgIGNob2ljZXMgdGhhdCBhcmlzZSB3aGVuIGRlc2lnbmlu ZyBJUHY2IG5ldHdvcmtzIChib3RoIGR1YWwtc3RhY2sgYW5kDQo+ID4gICBJUHY2LW9ubHkp LiAgVGhlIGludGVuZGVkIGF1ZGllbmNlIGlzIHNvbWVvbmUgZGVzaWduaW5nIGFuIElQdjYN Cj4gPiAgIG5ldHdvcmsgd2hvIGlzIGtub3dsZWRnZWFibGUgYWJvdXQgYmVzdCBjdXJyZW50 IHByYWN0aWNlcyBhcm91bmQgSVB2NA0KPiA+ICAgbmV0d29yayBkZXNpZ24sIGFuZCB3aXNo ZXMgdG8gbGVhcm4gdGhlIGNvcnJlc3BvbmRpbmcgcHJhY3RpY2VzIGZvcg0KPiA+ICAgSVB2 Ni4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcy8NCj4gPg0KPiA+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLTExDQo+ID4N Cj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZv cHMtZGVzaWduLWNob2ljZXMtMTENCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4gPg0K PiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPiA+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11 bmljYXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5p Y2F0aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5n LCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHBy b2hpYml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWls IG9yIHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUg Q3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9m IE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBs aWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9u Lgo= --_000_4FC37E442D05A748896589E468752CAA0DC2CD35PWN401EA120entc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgc29tZW9uZSB0cnlpbmcgdmVy eSBoYXJkIHRvIGdldCBFbnRlcnByaXNlcyB0byBpbXBsZW1lbnQgSVB2NiAoYW5kIG5vdCBz dWNjZWVkaW5nKSwmbmJzcDsgYW55dGhpbmcgdGhhdCBwb2ludHMgb3V0IGFkdmFudGFnZXMg b3ZlciBJUHY0IGlzIHZlcnkgY29tcGVsbGluZy4mbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBhICYjNDM7MSBvbiBNYXJrcyBjb21tZW50cy4mbmJz cDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmsgU21pdGg8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBPY3RvYmVyIDI4LCAyMDE2IDY6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWxpcCBNYXR0 aGV3cyAmbHQ7cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhJmd0Ozxicj4NCjxiPkNjOjwvYj4g djZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2lj ZXMtMTEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGVyZSdzIHN0aWxsIElQdjQgbWVudGFsaXR5 IGhlcmU6PG86cD48L286cD48L3A+DQo8cD4mcXVvdDtJbiBJUHY2LCBhbGwgaW50ZXJmYWNl cyBhcmUgYXNzaWduZWQgYSBMaW5rLUxvY2FsIEFkZHJlc3MgKExMQSkgW3JlZl0uIFRoZSBM aW5rLUxvY2FsIGFkZHJlc3MgY2FuIG9ubHkgYmUgdXNlZCBmb3IgY29tbXVuaWNhdGluZyB3 aXRoIGRldmljZXMgdGhhdCBhcmUgb24tbGluaywgc28gb2Z0ZW4gYWRkaXRpb25hbCBhZGRy ZXNzZXMgYXJlIGFzc2lnbmVkIHdoaWNoIGFyZSBhYmxlIHRvIGNvbW11bmljYXRlIG9mZi1s aW5rLiBUaGVzZSBhZGRpdGlvbmFsDQogYWRkcmVzc2VzIGNhbiBiZSBvbmUgb2YgdGhyZWUg dHlwZXM6JnF1b3Q7PG86cD48L286cD48L3A+DQo8cD5UaGUgbGFzdCBzZW50ZW5jZSBpcyBy ZWFkaW5nIEdVQSBQSSB4b3IgR1VBIFBBIHhvciBVTEEsIGltcGx5aW5nIElQdjYgaW50ZXJm YWNlcyBvbmx5IHN1cHBvcnQgYSBzaW5nbGUgTExBIGFuZCBhIHNpbmdsZSBvdGhlciBhZGRy ZXNzLCB3aGljaCBpcyBub3QgdGhlIGNhc2UuIEkgdGhpbmsgaXQgaXMgYWxzbyBpbXBseWlu ZyB0aGF0IGFkZHJlc3MgYXNzaWdubWVudHMgdG8gbm9kZXMgYXJlIHNlbWktcGVybWFuZW50 IHJhdGhlciB0aGFuIG1vcmUNCiBkeW5hbWljLCBhcyBzdXBwb3J0ZWQgYnkgSVB2NiBhZGRy ZXNzIGxpZmV0aW1lcy48bzpwPjwvbzpwPjwvcD4NCjxwPklmIHRoaXMgZHJhZnQgaXMgcmVm bGVjdGluZyBob3cgcGVvcGxlIGFyZSBkZXBsb3lpbmcgSVB2NiwgdGhlbiBJIHRoaW5rIGl0 IGlzIHJlZmxlY3RpbmcgYW4gSVB2NCBtZW50YWxpdHkgYXBwbGllZCB0byBJUHY2LiBJIGRv bid0IHRoaW5rIHRoYXQgaXMgYSB2ZXJ5IHVzZWZ1bCB0aGluZyB0byBwdWJsaXNoIGFzIGFk dmljZSBvbiBkZXBsb3lpbmcgSVB2NiwgYXMgaXQgaXNuJ3QgaWRlbnRpZnlpbmcgb3Bwb3J0 dW5pdGllcyB0byB0YWtlIGFkdmFudGFnZXMNCiB0aGF0IElQdjYgcHJvdmlkZXMgYW5kIElQ djQgZG9lcyBub3QuPG86cD48L286cD48L3A+DQo8cD5JZiB3ZSB3YW50IHRvIGdvIGRvd24g dGhhdCBwYXRoLCB0aGVuIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIHN0YXRlIHRo YXQgdGhpcyBpcyBhIHNuYXBzaG90IG9mIGN1cnJlbnQgZGVwbG95bWVudHMsIHBvaW50IG91 dCB0aGF0IHRoZXkgYXJlIElQdjQgb3JpZW50ZWQgSVB2NiBkZXBsb3ltZW50cywgYW5kIGlk ZW50aWZ5IGNhcGFiaWxpdGllcyBvZiBJUHY2IHRoYXQgYXJlIG5vdCBiZWluZyB0YWtlbiBh ZHZhbnRhZ2Ugb2YgdGhhdA0KIHdvdWxkIHByb3ZpZGUgb3BlcmF0aW9uYWwgYW5kIGVuZC11 c2VyIGFwcGxpY2F0aW9uIGFkdmFudGFnZXMuPG86cD48L286cD48L3A+DQo8cD5UaGUgY29z dCBvZiBkZXZlbG9waW5nIGFuZCBkZXBsb3lpbmcgSVB2NiBoYXMgYmVlbiBhbmQgd2lsbCBj b250aW51ZSB0byBoaWdoIGZvciBxdWl0ZSBhIHdoaWxlLCBzbyBJIHRoaW5rIHdlIHNob3Vs ZCBiZSBsb29raW5nIHRvIHRha2UgYWR2YW50YWdlIG9mIGl0cyBjYXBhYmlsaXRpZXMgYXMg b2Z0ZW4gYXMgcG9zc2libGUgdG8gbWF4aW1pc2UgdGhlIHJldHVybiBvbiB0aG9zZSBjb3N0 cy4gU29tZSBvZiB3aGF0IEkgd3JvdGUgaGVyZSBpcw0KIHRha2luZyBhICZxdW90O2hvdyB0 byBkbyBJUHY2IGJldHRlciB0aGFuIElQdjQmcXVvdDsgcGVyc3BlY3RpdmUgd2hpY2ggSSB0 aGluayBpcyB0aGUgb25lIHRoZSB2Nm9wcyBncm91cCBzaG91bGQgYmUgdGFraW5nLjxvOnA+ PC9vOnA+PC9wPg0KPHA+PGEgaHJlZj0iaHR0cHM6Ly9ibG9nLmFwbmljLm5ldC8yMDE2LzEw LzI3L3Ryb3VibGUtbmF0LXBhcnQtMy8iPmh0dHBzOi8vYmxvZy5hcG5pYy5uZXQvMjAxNi8x MC8yNy90cm91YmxlLW5hdC1wYXJ0LTMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+UmVnYXJk cyw8YnI+DQpNYXJrLjxvOnA+PC9vOnA+PC9wPg0KPHA+T24gMjkgT2N0LiAyMDE2IDg6MDkg YW0sICZxdW90O1BoaWxpcCBNYXR0aGV3cyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo aWxpcF9tYXR0aGV3c0BtYWdtYS5jYSI+cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgRm9sa3M6PGJyPg0KJmd0Ozxicj4NCiZn dDsgV2UgaGF2ZSBqdXN0IHB1Ymxpc2hlZCB0aGUgLTExIHJldmlzaW9uIG9mIHRoZSBEZXNp Z24gQ2hvaWNlcyBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgbWFpbiBjaGFuZ2Ug aW4gdGhpcyByZXZpc2lvbiBpcyB0b3RhbGx5IG5ldyB0ZXh0IGZvciB0aGUgQWRkcmVzc2Vz IHNlY3Rpb24uIFdlIGhhdmUgdG90YWxseSByZXdyaXR0ZW4gdGhpcyBzZWN0aW9uIGFmdGVy IHRoZSBjb21tZW50cyB3ZSByZWNlaXZlZCBpbiBZb2tvaGFtYSAoeWVzLCBvbmUgeWVhciBh Z28sIHNpZ2gpLiBXZSBhbHNvIHRvb2sgaW50byBhY2NvdW50IHRoZSBjb21tZW50cyBtYWRl IGJ5IEJyaWFuIENhcnBlbnRlciBhYm91dA0KIDEwIGRheXMgYWdvLCB0aG91Z2ggd2UgZGlk bid0IHN0cnVjdHVyZSB0aGUgc2VjdGlvbiB0aGUgd2F5IGhlIHN1Z2dlc3RlZC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgb3RoZXIgc2lnbmlmaWNhbnQgY2hhbmdlIHRoZSBhZGRpdGlv biBvZiB0aGUgc2NlbmFyaW8gb2YgdXNpbmcgT1NQRnYzIHRvIHJvdXRlIGJvdGggSVB2NCBh bmQgSVB2Ni4mbmJzcDsgVGhhbmtzIHRvIEpvaG4gTWFubiBmb3IgcG9pbnRpbmcgb3V0IHRo aXMgb21pc3Npb24uIFVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGtub3cgb2YgYW55b25lIGFj dHVhbGx5IHJ1bm5pbmcgdGhpcyBjb21iaW5hdGlvbiBpbiBhIG5vbi10cml2aWFsIHByb2R1 Y3Rpb24NCiBuZXR3b3JrIC0tIGVtYWlsIHRoZSBhdXRob3JzIHByaXZhdGVseSBpZiB5b3Ug aGF2ZSBkYXRhIHlvdSBhcmUgd2lsbGluZyB0byBzaGFyZS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJdCBpcyBvdXIgYmVsaWVmIHRoYXQgdGhpcyByZXZpc2lvbiBhZGRyZXNzZXMgdGhlIGNv bmNlcm5zIHBlb3BsZSBoYWQgd2l0aCBwcmV2aW91cyB2ZXJzaW9ucywgYW5kIHRoYXQgYWxs IHRoYXQgaXMgcmVxdWlyZWQgaXMgYSBwZXJoYXBzIGEgZmV3IG1pbm9yIHR3ZWFrcyBiZWZv cmUgaXQgaXMgZmluaXNoZWQgb2ZmLiZuYnNwOyBMZXQgdXMga25vdyBpZiB5b3UgYWdyZWUg b3IgZGlzYWdyZWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBkcmFmdCBoYXMgYmVlbiBp biB0aGUgd29ya3MgZm9yIGEgbG9uZyB0aW1lLiZuYnNwOyBIb3BlZnVsbHkgd2UgYXJlIGdl dHRpbmcgY2xvc2UgdG8gdGhlIGVuZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIFBoaWxpcCBh bmQgVmljdG9yPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDIwMTYtMTAtMjgs IGF0IDE3OjA0ICwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQom Z3Q7ICZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRp b25zIG9mIHRoZSBJRVRGLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiBTb21lIERlc2lnbiBDaG9pY2VzIGZvciBJUHY2IE5ldHdvcmtzPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBQaGlsaXAgTWF0dGhld3M8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVmljdG9yIEt1YXJz aW5naDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVuYW1l Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24t Y2hvaWNlcy0xMS50eHQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyNjxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTYtMTAtMjg8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwO1RoaXMgZG9jdW1lbnQgcHJlc2VudHMgYWR2aWNlIG9uIGNlcnRhaW4gcm91dGluZy1y ZWxhdGVkIGRlc2lnbjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtjaG9pY2VzIHRoYXQg YXJpc2Ugd2hlbiBkZXNpZ25pbmcgSVB2NiBuZXR3b3JrcyAoYm90aCBkdWFsLXN0YWNrIGFu ZDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtJUHY2LW9ubHkpLiZuYnNwOyBUaGUgaW50 ZW5kZWQgYXVkaWVuY2UgaXMgc29tZW9uZSBkZXNpZ25pbmcgYW4gSVB2Njxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDtuZXR3b3JrIHdobyBpcyBrbm93bGVkZ2VhYmxlIGFib3V0IGJl c3QgY3VycmVudCBwcmFjdGljZXMgYXJvdW5kIElQdjQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7bmV0d29yayBkZXNpZ24sIGFuZCB3aXNoZXMgdG8gbGVhcm4gdGhlIGNvcnJlc3Bv bmRpbmcgcHJhY3RpY2VzIGZvcjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtJUHY2Ljxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZn dDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMvPC9hPjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMtMTEiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLTExPC9h Pjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLWRlc2ln bi1jaG9pY2VzLTExIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLTExPC9hPjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0K Jmd0OyAmZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIj4NCnRvb2xzLmlldGYu b3JnPC9hPi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgJmd0 OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4N CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz PC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB2Nm9wcyBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZv cHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQoKCjxCUj4KPGh0bWw+CiA8cD5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0 aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdp bmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3Jt YXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVj dHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGll cy48L3A+CiA8cD5CbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVl IENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBh bmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNo aWVsZCBBc3NvY2lhdGlvbi48L3A+CiAgPC9odG1sPgoK --_000_4FC37E442D05A748896589E468752CAA0DC2CD35PWN401EA120entc_-- From nobody Fri Oct 28 21:44:14 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 437951295AD for ; Fri, 28 Oct 2016 21:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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.431, 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 FvBMF_GdnHIN for ; Fri, 28 Oct 2016 21:44:11 -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 C4EDB129460 for ; Fri, 28 Oct 2016 21:44:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D775AA3; Sat, 29 Oct 2016 06:44:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477716247; bh=gWdsy8zaXs6sCpXDpemWjWiTymtDTvRndueQ1Tw+Q88=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oYvyaN7zmt0ml0s8iZyUSgVtfzAmT6YpxI02IJKSV/xbFMwMfPEPv35hGkDk/7Ns0 LbLpFgeLRzJx4v6/DpqFmW59buVYrS7A+5lR1+ic3Ztn9DjOi3M/Z9owgA6GTbWEPQ CyLad6UzNgmghQexcBaePFgFSh+lyrC8i7w/iYDM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CB7D5A2; Sat, 29 Oct 2016 06:44:07 +0200 (CEST) Date: Sat, 29 Oct 2016 06:44:07 +0200 (CEST) From: Mikael Abrahamsson To: "Ackermann, Michael" In-Reply-To: <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> Message-ID: References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.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: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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: Sat, 29 Oct 2016 04:44:13 -0000 On Fri, 28 Oct 2016, Ackermann, Michael wrote: > As someone trying very hard to get Enterprises to implement IPv6 (and not succeeding), anything that points out advantages over IPv4 is very compelling. > So a +1 on Marks comments. I am preparing an IPv6 related presentation, and on one slide I have: --- With A=1, M=1 a device can have address(es): EUI64 based address Privacy extensions based address(s) DHCPv6 IA_NA / IA_TA (one or more each) 50 addresses that it (randomly) chose for itself from on-link /64 prefix Link-Local /56 delegated to it by means of DHCPv6-PD This is perfectly valid deployment scenario --- Not sure though that a lot of people will feel that this is progress (they're used to have more control), but it's important to make people understand that this is how IPv6 was designed. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Oct 29 11:34:37 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 4545E129564 for ; Sat, 29 Oct 2016 11:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 jaS5J5jw0E-Y for ; Sat, 29 Oct 2016 11:34:34 -0700 (PDT) Received: from tor-smtp-03.primus.ca (smtp-auth2-149.primus.ca [216.254.140.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9F1279EB for ; Sat, 29 Oct 2016 11:34:34 -0700 (PDT) Received: from bas5-ottawa10-3096709524.dsl.bell.ca ([184.148.9.148] helo=[10.0.1.24]) by tor-smtp-03.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c0YSe-0002yv-QV; Sat, 29 Oct 2016 14:34:33 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-1--904827827 From: Philip Matthews In-Reply-To: Date: Sat, 29 Oct 2016 14:34:21 -0400 Message-Id: References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> To: Mark Smith X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-3096709524.dsl.bell.ca ([10.0.1.24]) [184.148.9.148] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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: Sat, 29 Oct 2016 18:34:36 -0000 --Apple-Mail-1--904827827 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-10-28, at 18:00 , Mark Smith wrote: > There's still IPv4 mentality here: >=20 > "In IPv6, all interfaces are assigned a Link-Local Address (LLA) = [ref]. The Link-Local address can only be used for communicating with = devices that are on-link, so often additional addresses are assigned = which are able to communicate off-link. These additional addresses can = be one of three types:" >=20 > The last sentence is reading GUA PI xor GUA PA xor ULA, implying IPv6 = interfaces only support a single LLA and a single other address, which = is not the case. I think it is also implying that address assignments to = nodes are semi-permanent rather than more dynamic, as supported by IPv6 = address lifetimes. >=20 > If this draft is reflecting how people are deploying IPv6, then I = think it is reflecting an IPv4 mentality applied to IPv6. I don't think = that is a very useful thing to publish as advice on deploying IPv6, as = it isn't identifying opportunities to take advantages that IPv6 provides = and IPv4 does not. >=20 > If we want to go down that path, then I think it would be better to = state that this is a snapshot of current deployments, point out that = they are IPv4 oriented IPv6 deployments, and identify capabilities of = IPv6 that are not being taken advantage of that would provide = operational and end-user application advantages. >=20 > The cost of developing and deploying IPv6 has been and will continue = to high for quite a while, so I think we should be looking to take = advantage of its capabilities as often as possible to maximise the = return on those costs. Some of what I wrote here is taking a "how to do = IPv6 better than IPv4" perspective which I think is the one the v6ops = group should be taking. >=20 > https://blog.apnic.net/2016/10/27/trouble-nat-part-3/ >=20 > Regards, > Mark. >=20 Mark: You quoted the following sentences from the draft: > "In IPv6, all interfaces are assigned a Link-Local Address (LLA) = [ref]. The Link-Local address can only be used for communicating with = devices that are on-link, so often additional addresses are assigned = which are able to communicate off-link. These additional addresses can = be one of three types:" >=20 These sentences were deliberately phrased that way to suggest that = multiple addresses per interface are possible. However, as I now re-read = them, I see that they are also consistent with the interpretation that = at most a single additional address is permitted per interface, though = this was never the intention. To avoid the idea that an interface can have at most two addresses, I = propose to change the wording to the following: > "In IPv6, an interface is always assigned a Link-Local Address (LLA) = [REF]. The link-local address can only be used for communicating with = devices that are on-link, so often one or more additional addresses are = assigned which are able to communicate off-link. This additional address = or addresses can be one of three types:" Regarding lifetimes, this section is only about addresses used on = loopbacks and router-to-router links, as is stately clearly in the first = paragraph of the section. This restriction is consistent with the = overall scope of this document, which only talks about routing-related = design choices, and avoids any discussion of end host addresses in = enterprises, which is a bit of a minefield. In this regard, I personally = don't know of any router implementation that allows the addresses on a = router-to-router links to age out. Do you?=20 Regarding your blog post, I am confused. It seems to be about NAT, which = is not discussed in this document, so I don't see how it applies to this = document. - Philip --Apple-Mail-1--904827827 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There's still IPv4 mentality here:
"In = IPv6, all interfaces are assigned a Link-Local Address (LLA) [ref]. The = Link-Local address can only be used for communicating with devices that = are on-link, so often additional addresses are assigned which are able = to communicate off-link. These additional addresses can be one of three = types:"
The last sentence is reading GUA PI xor GUA PA = xor ULA, implying IPv6 interfaces only support a single LLA and a single = other address, which is not the case. I think it is also implying that = address assignments to nodes are semi-permanent rather than more = dynamic, as supported by IPv6 address lifetimes.
If = this draft is reflecting how people are deploying IPv6, then I think it = is reflecting an IPv4 mentality applied to IPv6. I don't think that is a = very useful thing to publish as advice on deploying IPv6, as it isn't = identifying opportunities to take advantages that IPv6 provides and IPv4 = does not.
If we want to go down that path, then I = think it would be better to state that this is a snapshot of current = deployments, point out that they are IPv4 oriented IPv6 deployments, and = identify capabilities of IPv6 that are not being taken advantage of that = would provide operational and end-user application advantages.
The cost of developing and deploying IPv6 has been and will = continue to high for quite a while, so I think we should be looking to = take advantage of its capabilities as often as possible to maximise the = return on those costs. Some of what I wrote here is taking a "how to do = IPv6 better than IPv4" perspective which I think is the one the v6ops = group should be taking.
https://blo= g.apnic.net/2016/10/27/trouble-nat-part-3/
Regards,
= Mark.

Mark:

= You quoted the following sentences from the draft:

"In IPv6, all interfaces are assigned a = Link-Local Address (LLA) [ref]. The Link-Local address can only be used = for communicating with devices that are on-link, so often additional = addresses are assigned which are able to communicate off-link. These = additional addresses can be one of three = types:"

These sentences were = deliberately phrased that way to suggest that multiple addresses per = interface are possible. However, as I now re-read them, I see that they = are also consistent with the interpretation that at most a single = additional address is permitted per interface, though this was = never the intention.

To avoid the idea that an = interface can have at most two addresses, I propose to change the = wording to the following:

"In IPv6, an interface is always assigned a = Link-Local Address (LLA) [REF]. The link-local address can only be used = for communicating with devices that are on-link, so often one or more = additional addresses are assigned which are able to communicate = off-link. This additional address or addresses can be one of three = types:"

Regarding = lifetimes, this section is only about addresses used on loopbacks and = router-to-router links, as is stately clearly in the first paragraph of = the section. This restriction is consistent with the overall scope = of this document, which only talks about routing-related design choices, = and avoids any discussion of end host addresses in enterprises, which is = a bit of a minefield. In this regard, I personally don't know of any = router implementation that allows the addresses on a router-to-router = links to age out. Do you?

Regarding your = blog post, I am confused. It seems to be about NAT, which is not = discussed in this document, so I don't see how it applies to this = document.

- = Philip

= --Apple-Mail-1--904827827-- From nobody Sat Oct 29 11:38:39 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 70F1F129547 for ; Sat, 29 Oct 2016 11:38:38 -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] 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 Ch46On6-XCgz for ; Sat, 29 Oct 2016 11:38:36 -0700 (PDT) Received: from tor-smtp-06.primus.ca (smtp-auth2-154.primus.ca [216.254.140.154]) by ietfa.amsl.com (Postfix) with ESMTP id 435E312952F for ; Sat, 29 Oct 2016 11:38:36 -0700 (PDT) Received: from bas5-ottawa10-3096709524.dsl.bell.ca ([184.148.9.148] helo=[10.0.1.24]) by tor-smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c0YWZ-0002qN-BF; Sat, 29 Oct 2016 14:38:35 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Sat, 29 Oct 2016 14:38:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-3096709524.dsl.bell.ca ([10.0.1.24]) [184.148.9.148] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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: Sat, 29 Oct 2016 18:38:38 -0000 Mikael: Is this something you would like to see happen on a router-to-router = interface in a network near you? - Philip On 2016-10-29, at 0:44 , Mikael Abrahamsson wrote: > On Fri, 28 Oct 2016, Ackermann, Michael wrote: >=20 >> As someone trying very hard to get Enterprises to implement IPv6 (and = not succeeding), anything that points out advantages over IPv4 is very = compelling. >> So a +1 on Marks comments. >=20 > I am preparing an IPv6 related presentation, and on one slide I have: >=20 > --- > With A=3D1, M=3D1 a device can have address(es): > EUI64 based address > Privacy extensions based address(s) > DHCPv6 IA_NA / IA_TA (one or more each) > 50 addresses that it (randomly) chose for itself from on-link /64 = prefix > Link-Local > /56 delegated to it by means of DHCPv6-PD >=20 > This is perfectly valid deployment scenario > --- >=20 > Not sure though that a lot of people will feel that this is progress = (they're used to have more control), but it's important to make people = understand that this is how IPv6 was designed. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 From nobody Sat Oct 29 12:27: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 5A4381295CF for ; Sat, 29 Oct 2016 12:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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.431, 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 Fn3O4aR2WjQK for ; Sat, 29 Oct 2016 12:27:38 -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 63927129593 for ; Sat, 29 Oct 2016 12:27:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 32E79A3; Sat, 29 Oct 2016 21:27:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477769256; bh=LzyLv1XeR5AI9qMUPcQKQrHsl0Akmg2/EM/LL4svhM8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qT0lBNRzdD0Aonp9dhxQkw2wQq7IsgZg6EUu9lrGB+SkKNokUyVq9QSGdZNnQausS ImN9ngKiozDLl4uOEh1LyaRIGzZK2KkAKPRkhTFLpL8l0k78oUei8jBhZZ1uONILwX IVsgXsFiePb+9zgF/+rLyVCNi5Y3UUHhHgkaHtnk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 28BE5A2; Sat, 29 Oct 2016 21:27:36 +0200 (CEST) Date: Sat, 29 Oct 2016 21:27:36 +0200 (CEST) From: Mikael Abrahamsson To: Philip Matthews In-Reply-To: <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> Message-ID: References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> 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: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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: Sat, 29 Oct 2016 19:27:40 -0000 On Sat, 29 Oct 2016, Philip Matthews wrote: > Mikael: > > Is this something you would like to see happen on a router-to-router interface in a network near you? Nope. I never read the draft before and didn't realise that this only covered router-router links. Now that I have read some of it, I would like to comment that I think this document doesn't present its "within an ISP/enterprise, only router-to-router link" scope limitation well enough in its introduction paragraph. btw typo: "when designing a Pv6-only or dual-stack network." , first sentence in the introduction. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Oct 29 15:27:44 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 BDC74129442 for ; Sat, 29 Oct 2016 15:27:43 -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 UB4Fuc3UUM39 for ; Sat, 29 Oct 2016 15:27:42 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 6263712940F for ; Sat, 29 Oct 2016 15:27:42 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 189so2603825pfz.3 for ; Sat, 29 Oct 2016 15:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KFAJBbLJCdEm/mov1KXYgMGRSOYOwQqSi2SuSIv+Tjc=; b=IdeP4Vcj6zTPvk/t1Tau9tX6SpYoaNzkptoIptF0Tbffe9vfjsiJzY+tlJnSnF6pH4 TMagBJnvltVUleGiplZzR5nAd3XUSlPkhpPY2Fr3ngv1qC/cqmw137SceBty1qedlSK8 rscTd9TdRiw5f4ISjRvtE2vOKBqj5aDBq1RMbvN/ed/3PBOk/1zw60H1TLFKgKlbfakZ i1xlWsoFjXe05zUK36lrP77usBOFQ8Kh5FjKs4t7gnNcOvFBlRT+cUd59OH64RwCH4DF o8ZaYNRrWxJs+YctUA+K1x0A4wKmCIUZ1iV20QXGKOkati0Y0CFR6GJcZlf4zxGJibWU aBCg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=KFAJBbLJCdEm/mov1KXYgMGRSOYOwQqSi2SuSIv+Tjc=; b=d2Hau05Ft3XCyV3zFQ6gkf5h7Z0S+i0fTfaq0UGfkFSPja9ipajKTh4y1fSp4FNcgn ukSwjm5a9UsMI1wxXIZECNiRrrKPBqIXe9zjAtpZ9vbfakl4YgiX5APNC5hGZUphlV3G sbVEn+YuBfOu+EZT9lRX3xqqhIaG4+tn0C1eRtoMg/NoVjDAxnxO3/BC3wQbtCvAxSpX D8XCv4O2qLFCvDgE0eh4/f8doxPyZ5QBkh80G60rEaxM4P335Wij3ArMamdut7zXEoOa flxP5pDRR7p0iYqe8fxki2IMl0xOTUXyFeHtPxCPYmH+qBzq1gXefJUBfnEok1ysGGdM AxAQ== X-Gm-Message-State: ABUngvcuV/OChWp3P2i5jyW/BxUAGi4YFPXLRh41X9JwKO1E6odpN5mJmr0zqu2dj7EpOQ== X-Received: by 10.98.205.207 with SMTP id o198mr36276791pfg.114.1477780062016; Sat, 29 Oct 2016 15:27:42 -0700 (PDT) Received: from [192.168.178.23] (113.217.69.111.dynamic.snap.net.nz. [111.69.217.113]) by smtp.gmail.com with ESMTPSA id b66sm27162262pfg.10.2016.10.29.15.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 15:27:41 -0700 (PDT) To: Philip Matthews , v6ops list References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <10f66f20-6c91-b447-2fc2-c84d85b9ec65@gmail.com> Date: Sun, 30 Oct 2016 11:27:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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: Sat, 29 Oct 2016 22:27:44 -0000 Hi, Thanks for the rewrite. > 2.1. Addresses ... > does not cover the choice of addresses > for end hosts. That's incorrect because everything else up to the start of subsection 2.1.1 is about site-wide addressing choices. Isn't it just subsection 2.1.1 that is specific to router addressing? The fact is that you can't completely separate the addressing choices for routers from the addressing choices for subnets and hosts. So that aspect of your document scoping is fundamentally illogical. You can wordsmith around it, but the Abstract and Introduction need to make it clear that router addressing choices depend on site-wide addressing choices. (For example, if you are running two site-wide PA GUA prefixes, you could still choose to use ULAs for all router interfaces, or one of the GUA prefixes.) > These disadvantages mean that some > smaller organization may not qualify or be willing to pay for these > addresses. Once we are talking about tens of millions of sites, this will not be 'some'. s/some/many/ > ULAs ... > Though there is currently no > document that describes these situations, I believe that RFC4864 is relevant. > Not discussed in this document is the possibility of using the > technology described in RFC 6296 to work around some of the > limitations of PA GUAs and ULAs. Then why mention it at all? It's only an experimental RFC. > 2.1.1. Where to Use Addresses s/Where to Use Addresses/Addresses for Router Interfaces/ > Option (a) means that the router cannot be reached (ping, management, > etc.) from farther than one-hop away. The authors are not aware of > anyone using this option. I think people have seen LLAs in traceroutes. Not sure where that really comes from, but in any case it's a strong argument for allocating GUAs or ULAs to routers. In any case, ICMP MUST NOT be sourced from LLAs. Regards Brian Carpenter From nobody Sat Oct 29 18:19:40 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 076E612954A for ; Sat, 29 Oct 2016 18:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 I07LYymKRVOc for ; Sat, 29 Oct 2016 18:19:38 -0700 (PDT) Received: from tor-smtp-02.primus.ca (smtp-auth2-170.primus.ca [216.254.140.170]) by ietfa.amsl.com (Postfix) with ESMTP id 417A4129498 for ; Sat, 29 Oct 2016 18:19:38 -0700 (PDT) Received: from bas5-ottawa10-3096709524.dsl.bell.ca ([184.148.9.148] helo=[10.0.1.24]) by tor-smtp-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c0ema-0005z2-57; Sat, 29 Oct 2016 21:19:32 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Sat, 29 Oct 2016 21:19:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5892BEB2-A55A-416A-97B1-9F6AF88FBE07@magma.ca> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-3096709524.dsl.bell.ca ([10.0.1.24]) [184.148.9.148] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 30 Oct 2016 01:19:39 -0000 On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote: > Now that I have read some of it, I would like to comment that I think = this document doesn't present its "within an ISP/enterprise, only = router-to-router link" scope limitation well enough in its introduction = paragraph. By "introduction paragraph" do you mean the first paragraph in section = 2.1, or do you mean the overall introduction (section 1)? - Philip= From nobody Sat Oct 29 22:27:25 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 08E051295FB for ; Sat, 29 Oct 2016 22:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, 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 TuceatKMLL1E for ; Sat, 29 Oct 2016 22:27:20 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 DB125129546 for ; Sat, 29 Oct 2016 22:27:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 68302A3; Sun, 30 Oct 2016 06:27:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477805236; bh=jTay0b/C29XgarS+c6jQjqnne0zdlbbGlMCoBbPcg8Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XxtlPvvQcU4ra+OWke0fn8+bTSF08d6woE40kPzs5ut3TWi6FGJjhPIsJrGE8iuVX 7WTjA3hDex1lGaNwBJvTP/U9g8FOuvXlMf6GMhw5JGRroZC7uVTAhepXp5e0oLdIC0 pcToskhk1e77Ou909bjNs3uv/mjuWODtkDaKEW+Y= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5E9A9A2; Sun, 30 Oct 2016 06:27:16 +0100 (CET) Date: Sun, 30 Oct 2016 06:27:16 +0100 (CET) From: Mikael Abrahamsson To: Philip Matthews In-Reply-To: <5892BEB2-A55A-416A-97B1-9F6AF88FBE07@magma.ca> Message-ID: References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> <5892BEB2-A55A-416A-97B1-9F6AF88FBE07@magma.ca> 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: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 30 Oct 2016 05:27:22 -0000 On Sat, 29 Oct 2016, Philip Matthews wrote: > > On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote: > >> Now that I have read some of it, I would like to comment that I think this document doesn't present its "within an ISP/enterprise, only router-to-router link" scope limitation well enough in its introduction paragraph. > > By "introduction paragraph" do you mean the first paragraph in section 2.1, or do you mean the overall introduction (section 1)? I mean 1. "This document discusses routing-related design choices" isn't obvious in that it mens "ISP internal router-router interfaces". with the current wording in the abstract and Introduction I expected to find for instance customer access port considerations. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Oct 30 05:04:59 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 D354E12953A for ; Sun, 30 Oct 2016 05:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 xXkPCV_VH5sy for ; Sun, 30 Oct 2016 05:04:56 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 311751294DA for ; Sun, 30 Oct 2016 05:04:56 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id q130so14892322qke.1 for ; Sun, 30 Oct 2016 05:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2BvorHRYZ7dQ+e+M6Hq0YiRSEN7qWqy7bMK6PvBwaxE=; b=m2hXEIsgD1nPfiduiSpIQcTWi1EApgPSolPt8xoxmbNaRqjjauC76yRH9sgACx3sOD vgf5KRO9LisSrqq+BFwjKhOV5Lbcp1s6wVaFAcETZ92LECaZncjdx2BzBf2PXwLkC1Yy c/K++Z9xo2XKsWG6EPNvvkF5NiveMuQNg25Oi7ndoy42sBlXrnARNSbNtAfEKDwiOEWt f8N22gL7jSEFWNdIOK9fqZ1uTypaA2n6H/GEkmc/iza4GzHD36nWYe93TLwBrF/+Zvj/ dNl2KVg94LhIT/ORlH1uoAE6nxIqPjWXoT87v87gygDzvNTuWayu/rZtinVft3rkPihP zcdw== 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:content-transfer-encoding; bh=2BvorHRYZ7dQ+e+M6Hq0YiRSEN7qWqy7bMK6PvBwaxE=; b=PbaeMPFv/9uQGGWyPRabSEkxYluGw2F31gzuXgJh2QSpZJSwlO2VAwAcq4U+7RH2Fi U2fEt/IiYfEys+Q3onHQXXvH9aSyA1F81rk41LVPrBvDsrRmkWLk5MFRgRyNil7rGtop uhPgHvoV2bvp50A52nkWPMaxhk79Nq356UQWjwCuh5SnDjwoe8+oC6vxzF994sjsaYJ1 86XwP6OPucFBUJmtgaJ23jt/PyIdreYxp8fkTvCKTvfbrCWhUNIqrPpmN5Y2sR0KjHyS 0ccQo9AzK/rn5Uq2G4o/8lW16pwsd48+8dCXAQJgMKItfaMj6t9ctmgr5awEAIaGScbk svgg== X-Gm-Message-State: ABUngvfUiAOgBqP2eKXmyejMuYL+SPvNtZMYsE+f2RHEUKgIUSdOR0RDM43vrbAYB9/FeqPpjeSf0sJkDQOyW7ee X-Received: by 10.55.70.84 with SMTP id t81mr18367055qka.309.1477829095152; Sun, 30 Oct 2016 05:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.146.71 with HTTP; Sun, 30 Oct 2016 05:04:24 -0700 (PDT) In-Reply-To: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> References: <03BE826C-CCD4-4F46-B1FC-4B2ACF6782BA@magma.ca> From: Warren Kumari Date: Sun, 30 Oct 2016 13:04:24 +0100 Message-ID: To: Philip Matthews Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] IETF meeting with IPv6 routes over IPv4? 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, 30 Oct 2016 12:04:58 -0000 On Mon, Oct 24, 2016 at 10:52 PM, Philip Matthews wrote: > I have a memory that there was an IETF meeting some years ago where the I= Pv6 connectivity used BGP sessions where the IPv6 routes were carried over = an BGP session that ran over IPv4 transport. Does anyone remember which me= eting that was, and why this was done? We are updating the BGP section in = the Design Choices draft and are considering mentioning this. > You are probably thinking of IETF81, IETF84 or IETF88. For some reason Telus (who very kindly donate circuits) like to provide a single BGP peering, and carry both IPv4 and IPv6 over it. I cannot remember the justification, but I'll try find more / grab the archived configs where we rewrite the next hop... W > -Philip > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Oct 30 12:12:52 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 EFC801294BB for ; Sun, 30 Oct 2016 12:12:50 -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 tXdx3SEp3AiP for ; Sun, 30 Oct 2016 12:12:49 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 91406129444 for ; Sun, 30 Oct 2016 12:12:49 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 197so64848408pfu.0 for ; Sun, 30 Oct 2016 12:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iHR97b3BfOUmoy6xK1Cyx4DrJ2lcg4naBR2tO1V1LKc=; b=LmE0fhlSoGO7uJNjRP3O06AdMdv4UyRE1Z+WyF+Y9VWHRHT8O71u744umsckwB6fbB w7gqhkwnpPBjN7uWouYXWvmDeDBagRFbga2KARWRO1HJqx8WhhPWpDMWMH2eNyqEFQ8u h8615R5teMdUFlov8+qCoU5GeTAUeZHfLP7UruORTyC4zbZjaoBb8GXhdjzI4U2FiqhW XHi4T0kYMM8bMujCenduoSeFXikG6g7fbQ3xE4souj9QHlZjBt7LnFc1rgQ1IdhbxEUu 9RlZu/mZsjF56lS8X3apYS9dM6dROLJd/wFltfTUidk/3TeP+hdVVTcHFQ49vuz1/aBT 411g== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=iHR97b3BfOUmoy6xK1Cyx4DrJ2lcg4naBR2tO1V1LKc=; b=WZx75Sf7cCgegwt/NxKD2jMpUOxc75EubaQ8pgJjKknNIV1n6bvohQSNZU+0rrDzT+ RycmX2c7fSSo+Nx+9LMOlWiHV3nMZGUOkk3sH29WXXPKJO6TQJTKlC769XZbmRHsSc4O uit9kWmPUhCiAhxFgg5R6mEroSVWORtopLG1ajlbN3rEFRcJXfqdx6UxytMl/yJQiBgb JUexiAqSTvthxyIkmMJqcksHILlAI7+4UFv142t6RI6gx5cE0qMNxsK0CvacXv7jSFl0 AnK8U5Lqy1kSCdSYwXYJm5vPg/j8LXYeYezTcbO5h+PtNmEhn3y0NaMHO/2Zqiiu7S3p hV/A== X-Gm-Message-State: ABUngvfE3ULItM77rz02gPfWxOCPk3ijPC3uuTfqdqzmszRHnEaxr5awyNZCtEcCsUWL/A== X-Received: by 10.99.10.20 with SMTP id 20mr35107253pgk.98.1477854768960; Sun, 30 Oct 2016 12:12:48 -0700 (PDT) Received: from ?IPv6:2406:e007:7cc3:1:28cc:dc4c:9703:6781? ([2406:e007:7cc3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d79sm31352479pfj.68.2016.10.30.12.12.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Oct 2016 12:12:48 -0700 (PDT) To: v6ops@ietf.org References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> <5892BEB2-A55A-416A-97B1-9F6AF88FBE07@magma.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c43574b-f228-61ad-40d7-a0f47dee1ed5@gmail.com> Date: Mon, 31 Oct 2016 08:12:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 30 Oct 2016 19:12:51 -0000 On 30/10/2016 18:27, Mikael Abrahamsson wrote: > On Sat, 29 Oct 2016, Philip Matthews wrote: > >> >> On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote: >> >>> Now that I have read some of it, I would like to comment that I think this document doesn't present its "within an ISP/enterprise, only router-to-router link" scope limitation well enough in its introduction paragraph. >> >> By "introduction paragraph" do you mean the first paragraph in section 2.1, or do you mean the overall introduction (section 1)? > > I mean 1. > > "This document discusses routing-related design choices" isn't obvious in > that it mens "ISP internal router-router interfaces". > > with the current wording in the abstract and Introduction I expected to > find for instance customer access port considerations. The title is also too general, IMHO. (We've tried a few times to write more general guidance, e.g. RFC6036, RFC6883 and RFC7381. But when we're writing specific guidance, the title should be equally specific.) Brian From nobody Sun Oct 30 14:46: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 79F8B1293FF for ; Sun, 30 Oct 2016 14:46:52 -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, 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 x5Tw1HrVADAP for ; Sun, 30 Oct 2016 14:46:50 -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 3B7AE1294E2 for ; Sun, 30 Oct 2016 14:46:50 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y123so92811438vka.3 for ; Sun, 30 Oct 2016 14:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GQL06ygstn7bSly94JQfNb/NZ3Cn4VuLfIGU8Uy3jM8=; b=auk8n+a+MC++mzzNpQ9L4JSWOQtM5lz2WvqD0n/w2RSh4ZGokzOVw/OZfsvGyWeL2U Hro+tzkvIQES3g5c/d7tWOS+ioyL5fryBLJb83nHWDPGVKVX7LpYbzbUNKM22ozdR/Mv c/G0NlDX+S4WkDRjKjff/WRxEYfJ3mR8VRy7JEXfE6YhaqE/HhusG3GyGnDFb7HbRdu1 dv2Fa7LUIs7+kgwAjXTFjELqJ/q+H+gOTO5gte/LeEkUtOeqkRcXcfpfjYEjFbwdYwna hhsbqpubm7Nsm8YCQKS3tFhXdltwa5biyO++BNuhG+AGc3NzhraxP3Y+1pa79VJUN7+A VlAA== 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=GQL06ygstn7bSly94JQfNb/NZ3Cn4VuLfIGU8Uy3jM8=; b=fEECn6uRdvVLzm2b8gBcliLaNOJ3En+Uu7tg0psXmNI+kNcFyHk8PaJl9JihkGKcd3 bcHPyTyKdr+WCgeHZg95ugQgliLyInp0WAurEJGyaWMrt8z7hvvYKvJauh/lxm0BcgAM rbw5zq+oYpcTRP7TZMToweaSViXCyJCK46OXDR+PqhGYU3v4XSg4rhR2CbbISVuh98Dp 6VbeAPXvnl+wvsjjVXYyFRR3IyBLQg/VpAEfm/rL1LSONTWR/mvpNdfHj/dlxwwRKWuc PsklnDJhGJVx0xHmboiQg+bQ9XyVFBvgpCVMwsjQxeIWZLLLQfYrCyF1nwk7PDsxdEOQ AZ4A== X-Gm-Message-State: ABUngvdredn9iUQ2vxE1tBxFaM2NKkkymfMGL96oQvOQc7C7rl9APFA6EvCZVsm+f1SlVaSy5HAy90Vf3OGfaQ== X-Received: by 10.31.203.3 with SMTP id b3mr20716120vkg.131.1477864009165; Sun, 30 Oct 2016 14:46:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.79 with HTTP; Sun, 30 Oct 2016 14:46:48 -0700 (PDT) Received: by 10.176.16.79 with HTTP; Sun, 30 Oct 2016 14:46:48 -0700 (PDT) In-Reply-To: <5c43574b-f228-61ad-40d7-a0f47dee1ed5@gmail.com> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <4FC37E442D05A748896589E468752CAA0DC2CD35@PWN401EA120.ent.corp.bcbsm.com> <41BC3BFD-10BC-4229-80F5-57A796508968@magma.ca> <5892BEB2-A55A-416A-97B1-9F6AF88FBE07@magma.ca> <5c43574b-f228-61ad-40d7-a0f47dee1ed5@gmail.com> From: Mark Smith Date: Mon, 31 Oct 2016 08:46:48 +1100 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114dc9784af1b805401c0713 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 30 Oct 2016 21:46:52 -0000 --001a114dc9784af1b805401c0713 Content-Type: text/plain; charset=UTF-8 On 31 Oct. 2016 5:43 am, "Brian E Carpenter" wrote: > > On 30/10/2016 18:27, Mikael Abrahamsson wrote: > > On Sat, 29 Oct 2016, Philip Matthews wrote: > > > >> > >> On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote: > >> > >>> Now that I have read some of it, I would like to comment that I think this document doesn't present its "within an ISP/enterprise, only router-to-router link" scope limitation well enough in its introduction paragraph. > >> > >> By "introduction paragraph" do you mean the first paragraph in section 2.1, or do you mean the overall introduction (section 1)? > > > > I mean 1. > > > > "This document discusses routing-related design choices" isn't obvious in > > that it mens "ISP internal router-router interfaces". > > > > with the current wording in the abstract and Introduction I expected to > > find for instance customer access port considerations. > > The title is also too general, IMHO. > That's what caught me. I've read the draft before, however the other day I just read the diff. I'd forgotten the draft was about routing only, and the title is very generic . The addressing text I commented on was both generic and also incorrect (going by RFC2460, "router interfaces" are actually host interfaces because the addresses on them are used as packet sources and destinations, so IPv6 host interface addressing etc. rules apply to them.) The title needs to be something like "IPv6 Routing Design Choices", and the next needs to use more specific terms more often to ensure the reader is reminded that this is only advice for the IPv6 routing plane. Regards, Mark. > (We've tried a few times to write more general guidance, e.g. RFC6036, RFC6883 > and RFC7381. But when we're writing specific guidance, the title should be > equally specific.) > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114dc9784af1b805401c0713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 31 Oct. 2016 5:43 am, "Brian E Carpenter" <<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:
>
> On 30/10/2016 18:27, Mikael Abrahamsson wrote:
> > On Sat, 29 Oct 2016, Philip Matthews wrote:
> >
> >>
> >> On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote:
> >>
> >>> Now that I have read some of it, I would like to comment = that I think this document doesn't present its "within an ISP/ente= rprise, only router-to-router link" scope limitation well enough in it= s introduction paragraph.
> >>
> >> By "introduction paragraph" do you mean the first p= aragraph in section 2.1,=C2=A0 or do you mean the overall introduction (sec= tion 1)?
> >
> > I mean 1.
> >
> > "This document discusses routing-related design choices"= ; isn't obvious in
> > that it mens "ISP internal router-router interfaces". > >
> > with the current wording in the abstract and Introduction I expec= ted to
> > find for instance customer access port considerations.
>
> The title is also too general, IMHO.
>

That's what caught me.

I've read the draft before, however the other day I just= read the diff. I'd forgotten the draft was about routing only, and the= title is very generic . The addressing text I commented on was both generi= c and also incorrect (going by RFC2460, "router interfaces" are a= ctually host interfaces because the addresses on them are used as packet so= urces and destinations, so IPv6 host interface addressing etc. rules apply = to them.)

The title needs to be something like "IPv6 Routing Desi= gn Choices", and the next needs to use more specific terms more often = to ensure the reader is reminded that this is only advice for the IPv6 rout= ing plane.

Regards,
Mark.

> (We've tried a few times to write more general guid= ance, e.g. RFC6036, RFC6883
> and RFC7381. But when we're writing specific guidance, the title s= hould be
> equally specific.)
>
> =C2=A0 =C2=A0 =C2=A0Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
--001a114dc9784af1b805401c0713-- From nobody Mon Oct 31 07:44:14 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 A8DEA1294AC for ; Mon, 31 Oct 2016 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 LVpCbsAVqQvh for ; Mon, 31 Oct 2016 07:44:12 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0093.outbound.protection.outlook.com [104.47.42.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E230C129430 for ; Mon, 31 Oct 2016 07:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DiLDxO0418xP1ZcLYzas7e64rZ4lTaoQr0vqlSL+AWQ=; b=C8osjswXoiFeL8iKsPCF4iTdEsSBv0/czfgCvJ/j4dUiYh0vF/LNq07+UvVDRRNQZM07yQirfFIKbsoj0aP+J9fwzRAYw5WCWZfV2QU/1LbWeD6uvKslZEkmp1ohgeYAAAsROm82ZIzpYedpVexBcawlaWYZqDROulfvkD6x/9s= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Mon, 31 Oct 2016 14:44:10 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0679.020; Mon, 31 Oct 2016 14:44:10 +0000 From: Ron Bonica To: IPv6 Ops WG Thread-Topic: IETF 97 Agenda Thread-Index: AdIzhRSI1GXzkF/tSfuvohsQejJpgw== Date: Mon, 31 Oct 2016 14:44:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 78d36920-d1d4-486c-1eda-08d4019c6041 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2051; 7:LcJT5Kg3DRm4gu3MI/ir3N0FI4KtpKcQWYbKLi6ZyYeEMGl0P5Pj1EMrREBm5O3RFDjw/EQ/oCvTRpJSqZDErAGLJGiv7JiXAQcLFDpCulQGX9mT8gwAUK06vSYZaNrWzBOcB16VIz9lV3JseAOBbFgab4KPuLJ8ly6SqVe0klhRLWEBqCNYHFwiapIjlEm2gVKseDOMYDAvR0Ix+cC9mw7QoKav4EO9NHsOYALXWmiWdMrRPcYXkyWm1lbbll2JOpa/vAFnaJK4KJc11RC+2oMGf+UisG5jdyapOkqDz7VXf1JsvIOMXayrVoFfNrmm6ufnO9MQrp8z98WVWvUvwJO8+RI3rFBGgntrlLfD7mY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2051; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB2051; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2051; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(586003)(76576001)(74316002)(68736007)(101416001)(107886002)(54356999)(86362001)(50986999)(92566002)(33656002)(2900100001)(10400500002)(9686002)(87936001)(102836003)(189998001)(77096005)(6116002)(3846002)(11100500001)(8936002)(5660300001)(3660700001)(99286002)(105586002)(7846002)(229853001)(19580395003)(305945005)(106356001)(7736002)(7116003)(66066001)(15975445007)(3280700002)(2906002)(122556002)(110136003)(97736004)(6916009)(450100001)(8676002)(81166006)(81156014)(5002640100001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2051; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 31 Oct 2016 14:44:10.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2051 Archived-At: Subject: [v6ops] IETF 97 Agenda 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, 31 Oct 2016 14:44:14 -0000 Folks, The following is a proposed agenda for our next meeting. Please email the c= hairs if you would like to be added to or deleted from the list. Ron IPv6 Operations - IETF 96 November 14, 13:30-15:30 -- Some Design Choices for IPv6 Networks P. Matthews, V. Kuarsingh draft-ietf-v6ops-design-choices -- Unique IPv6 Prefix Per Host J. Brzozowski, G. Van De Velde draft-ietf-v6ops-unique-ipv6-prefix-per-host=20 -- Enterprise Multihoming using Provider-Assigned Addresses=20 without Network Prefix Translation: Requirements and=20 Solution F. Baker, C. Bowers, J. Linkova draft-bowbakova-rtgwg-enterprise-pa-multihoming=09 -- Local-use IPv4/IPv6 Translation Prefix T. Anderson draft-anderson-v6ops-v4v6-xlat-prefix The status of v6ops drafts, both working group drafts (draft-ietf-v6ops-*) = and individual=20 submissions to the working group (draft--v6ops-*), may be determine= d from=20 https://datatracker.ietf.org/wg/v6ops/. From nobody Mon Oct 31 09:26: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 C0CEC129894 for ; Mon, 31 Oct 2016 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 lEzi9hJIi3pG for ; Mon, 31 Oct 2016 09:26:09 -0700 (PDT) Received: from tor-smtp-06.primus.ca (smtp-auth2-134.primus.ca [216.254.140.134]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2C12989B for ; Mon, 31 Oct 2016 09:26:09 -0700 (PDT) Received: from [24.114.94.162] (helo=[172.20.10.4]) by tor-smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c1FPU-0004mH-MO; Mon, 31 Oct 2016 12:26:09 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2--739749734 From: Philip Matthews In-Reply-To: <10f66f20-6c91-b447-2fc2-c84d85b9ec65@gmail.com> Date: Mon, 31 Oct 2016 12:25:40 -0400 Message-Id: <0DE1B631-CE5C-4424-BB29-97407700F9C9@magma.ca> References: <147768867563.24948.10024907649047718692.idtracker@ietfa.amsl.com> <2465D1CC-7A48-46A3-93F8-340980B2E5FF@magma.ca> <10f66f20-6c91-b447-2fc2-c84d85b9ec65@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.94.162] Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt 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, 31 Oct 2016 16:26:11 -0000 --Apple-Mail-2--739749734 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian: Thanks for your comments. See responses inline. On 2016-10-29, at 18:27 , Brian E Carpenter wrote: >> 2.1. Addresses > ... >> does not cover the choice of addresses >> for end hosts. >=20 > That's incorrect because everything else up to the start of subsection = 2.1.1 > is about site-wide addressing choices. Isn't it just subsection 2.1.1 = that is > specific to router addressing? The comment about scoped to just router addressing is made at the start = of section 2.1. The text before that section (section 1) is simply = introductory material that primarily defines what this document does and = does not cover. And the sections after 2.1 do not cover addressing. So I = don't see how your comment applies. See also my next response. >=20 > The fact is that you can't completely separate the addressing choices = for routers > from the addressing choices for subnets and hosts. So that aspect of = your document > scoping is fundamentally illogical. You can wordsmith around it, but = the Abstract > and Introduction need to make it clear that router addressing choices = depend on > site-wide addressing choices. (For example, if you are running two = site-wide > PA GUA prefixes, you could still choose to use ULAs for all router = interfaces, or > one of the GUA prefixes.) I agree that it is difficult to do, which is why we almost deleted this = section from the draft. We put it back in part because you encouraged = us to. The rest of the document is scoped to be just about routers, and = there are many reasons why the authors do not want to expand that scope. = If the WG really wants to discuss design choices for end host = addressing, then the authors suggest this be done in a different = document. >=20 >> These disadvantages mean that some >> smaller organization may not qualify or be willing to pay for these >> addresses. >=20 > Once we are talking about tens of millions of sites, this will not be = 'some'. > s/some/many/ We were trying not to say anything about how many organizations would = fall into this category, but I agree that it is likely to be a lot. I = have changed the word as you suggested. >=20 >> ULAs ... >> Though there is currently no >> document that describes these situations, >=20 > I believe that RFC4864 is relevant. I read through this RFC, and it seems to be talking about an entirely = different set of problems than RFC 6752. =20 >=20 >> 2.1.1. Where to Use Addresses >=20 > s/Where to Use Addresses/Addresses for Router Interfaces/ >=20 >> Option (a) means that the router cannot be reached (ping, management, >> etc.) from farther than one-hop away. The authors are not aware of >> anyone using this option. >=20 > I think people have seen LLAs in traceroutes. Not sure where that = really > comes from, but in any case it's a strong argument for allocating GUAs > or ULAs to routers. In any case, ICMP MUST NOT be sourced from LLAs. I agree that this option seems bad, but we are trying hard to be neutral = and just present pros and cons. Is there a specific disadvantage of = this option that you think we should include? - Philip --Apple-Mail-2--739749734 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
2.1. = Addresses
...
does = not cover the choice of addresses
for end hosts.

That's incorrect = because everything else up to the start of subsection 2.1.1
is about = site-wide addressing choices. Isn't it just subsection 2.1.1 that = is
specific to router = addressing?

The comment about = scoped to just router addressing is made at the start of section 2.1. = The text before that section (section 1) is simply introductory = material that primarily defines what this document does and does not = cover. And the sections after 2.1 do not cover addressing. So I don't = see how your comment applies. See also my next = response.

The fact is that = you can't completely separate the addressing choices for routers
from = the addressing choices for subnets and hosts. So that aspect of your = document
scoping is fundamentally illogical. You can wordsmith around = it, but the Abstract
and Introduction need to make it clear that = router addressing choices depend on
site-wide addressing choices. = (For example, if you are running two site-wide
PA GUA prefixes, you = could still choose to use ULAs for all router interfaces, or
one of = the GUA prefixes.)

I agree = that it is difficult to do, which is why we almost deleted this section = from the draft. We put it back in part because you encouraged us = to. The rest of the document is scoped to be just about routers, = and there are many reasons why the authors do not want to expand that = scope. If the WG really wants to discuss design choices for end host = addressing, then the authors suggest this be done in a different = document.

These disadvantages = mean that some
smaller = organization may not qualify or be willing to pay for = these
addresses.

Once we are talking about = tens of millions of sites, this will not be = 'some'.
s/some/many/

We = were trying not to say anything about how many organizations would fall = into this category, but I agree that it is likely to be a lot. I = have changed the word as you = suggested.

ULAs = ...
Though there is currently = no
document that describes = these situations,

I believe that RFC4864 is = relevant.

I read through this RFC, = and it seems to be talking about an entirely different set of problems = than RFC 6752.