From nobody Sun Jun 1 03:24:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9481A01D4 for ; Sun, 1 Jun 2014 03:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 jDetkNucXyw1 for ; Sun, 1 Jun 2014 03:24:16 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F501A01D3 for ; Sun, 1 Jun 2014 03:24:15 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C499460B34 for ; Sun, 1 Jun 2014 12:24:08 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 882C860AED for ; Sun, 1 Jun 2014 12:24:08 +0200 (CEST) Received: (qmail 57822 invoked by uid 1007); 1 Jun 2014 12:24:08 +0200 Date: Sun, 1 Jun 2014 12:24:08 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20140601102408.GH46558@Space.Net> References: <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531213133.GB46558@Space.Net> <20140531222321.8A5D8171A140@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ley0jF/Xzz4aC/u2" Content-Disposition: inline In-Reply-To: <20140531222321.8A5D8171A140@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1Auzckysc1hTITBHi36Y6bljfF4 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 10:24:18 -0000 --ley0jF/Xzz4aC/u2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jun 01, 2014 at 08:23:21AM +1000, Mark Andrews wrote: > > > But I have nothing to update my DNS zones. How do I reflect which lin= ks=20 > > > are up or down? Is there even a draft for that? What's the BCP for TTL > > > values, DNSSEC, etc? > >=20 > > This is where things get interesting. You, Owen, I are not "the 99% ho= me > > users out there" - home users don't do DNS zones, because they do not= =20 > > control a DNS server... (they do mDNS because it's automatic and works [..] > The IETF has published exactly one method for updating the DNS (RFC 2136). > It has standardized several methods for securing that update. While technically fully correct, this is completely missing the point :-) - how does the homenet CPE/host know *which* domain to update? - how does the homenet CPE/host know *how* to update this domain (end=20 users do not understand "entering keys in bind config on authoritative= =20 name servers, and then copy these keys to their CPE")? - *when* should the CPE/host do the update, particularily, when one of the= =20 ISP uplinks goes down, *should* it remove the records using that ISP's prefix? If yes, after which time of non-availability? (The ISP might never come back, it might be a move to a new ISP, after all) - if, on the same ISP, the prefix changes, how should the update look like? Flash replace, staggered add/remove? these are the interesting questions. The mechanics of doing a zone update via DNS protocol are interesting for DNS software implementors, but fairly= =20 uninteresting as far as the yet-unsolved questions surrounding a CPE in a non-managed home or SME network go :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ley0jF/Xzz4aC/u2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4r/SN9WwGXkzn/FAQI+2BAAsboerLZAa5xKKMmi4CNbwvib+iehifGm ruhOwpnUSxmo03zuJ9HOTJXz8WcB8BA2K4O1S4iu1LClrEGr4RHol/y0sRxvnL37 wYvr9Y+wU0CN2fOxN/eLHIv/RTL0Hjnd+Gk+nBxbnr7qn1CgDmdxwnOsd6zJBxto ru66xxnSz1+JGAWZFmlAuj3WXRIdgKoR6N3ZIZtAEgRWRAtmXEmcITeQTp9jdktt QwirKjlpUaKk1yDtrB580kx9NvTzsUgmrso9dAgVf6+vwMURRqDbQw7jkdAp58J9 oCjVmW8CBDKQ9f8zi3wcZ0TFdTBKLVS6hotYOSrtCMZaFdlluyS5uR9qVuN0nMdH PLuN3fI2srtCb6zeyt+l1RqG2t3l5PVYpaPCi6ILOU+RJWJeafq5BbVrlzfvA2pV TckillF76zYwy/9oVIVv7EKirtz/6DGs2IIL28tSlnU+i3+nj1mZlwcmIptjJ3H1 tXQLpLnCOroSp4eZmMrUwqPsRQpDBsM5wUR7RWyXY00czJcK0EPR8i+u93ubahXJ O4glUPpwLh+INsFeUf7Nn134AHza+ZQzFIaWWi24zS4XJ0nvzAMp0iNim5etWA3B xjcnQmi2bcYG8X6+UYI93Byx8OQAGVxg1GZiLk1HV+k4Ecrfj58Bm2HfjxgIYUwk vV+DEJ1iiy4= =eBdQ -----END PGP SIGNATURE----- --ley0jF/Xzz4aC/u2-- From nobody Sun Jun 1 06:46:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AA61A021F for ; Sun, 1 Jun 2014 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 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.651, SPF_NEUTRAL=0.779] autolearn=ham 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 Q2l5gC2aEKAe for ; Sun, 1 Jun 2014 06:46:14 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884801A0213 for ; Sun, 1 Jun 2014 06:46:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s51DjuNC020024; Sun, 1 Jun 2014 14:45:56 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s51DjuNC020024 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401630357; bh=aE+gxxDhJOrbZPqj5qh0Psu4ESo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=hzqciCRYKXWv40Hyci92Ph0UPieeiLqHvzfO0T1rRPyb2i4H1L0snYs/WDcTbxbQc oq8pFDRKLfY02dRpAt4zEb/eqwSQFOpxIjBDmt8/VkyumDR20yPgm2zZ9TJPqCj5kg 8wvXNQVsmrC311/NmyGCFPfT4BgnWZwTmxfk70UY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q50Eju0546056013y1 ret-id none; Sun, 01 Jun 2014 14:45:57 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s51DjqWO007120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jun 2014 14:45:52 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_E248B8EB-758B-4783-B5C7-E1651CFFF515" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: Date: Sun, 1 Jun 2014 14:45:51 +0100 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q50Eju054605601300; tid=q50Eju0546056013y1; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s51DjuNC020024 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v84dw1u6WFlS-dfGRN4mxZSCNcs Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:46:16 -0000 --Apple-Mail=_E248B8EB-758B-4783-B5C7-E1651CFFF515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 30 May 2014, at 02:58, Lorenzo Colitti wrote: > Owen, >=20 > I said "BEFORE we discuss questions #2 and #3". :-) >=20 > The chairs have expressed concern that this document keeps getting = mired in debate. I'm trying to help. One way to avoid that is to avoid = this particular debate altogether. This was pretty much what = draft-ietf-v6ops-enterprise-incremental-ipv6-05 did, which is being = published soon. It does include a fairly minimal reference to NPTv6, and = a reference to the ULA draft under discussion here.=20 In the homenet arch text there=92s again a fairly short paragraph = referencing NPTv6, with a short =91health warning=92 later in the text, = to quote: "Note that unlike private IPv4 RFC 1918 space, the use of ULAs does not imply use of an IPv6 equivalent of a traditional IPv4 NAT [RFC3022], or of NPTv6 prefix-based NAT [RFC6296]. When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally, and use its additional globally unique IPv6 address as a source address for external communications. This should be the natural behaviour given support for Default Address Selection for IPv6 [RFC6724]. By using such globally unique addresses between hosts and devices in remote networks, the architectural cost and complexity, particularly to applications, of NAT or NPTv6 translation is avoided. As such, neither IPv6 NAT or NPTv6 is recommended for use in the homenet architecture. Further, the homenet border router(s) should filter packets with ULA source/destination addresses as discussed in Section 3.4.2.=94 =85 "As explained previously, while NPTv6 has been proposed for providing multi-homing support in networks, its use is not recommended in the homenet architecture." Perhaps something similar can be stated in this ULA draft. Tim > Cheers, > Lorenzo >=20 > On Fri, May 30, 2014 at 10:52 AM, Owen DeLong wrote: > I think this use case is absurd. >=20 > If you need to communicate to outside world, it=92s perfectly = reasonable to use SLAAC with GUA and there=92s no benefit derived from = ULA+NPT. >=20 > Owen >=20 > On May 29, 2014, at 1:28 AM, Liubing (Leo) = wrote: >=20 > > Hi, All > > > > We're going to update the ULA draft. Before making a new version, I = think it would be helpful to confirm/discuss several important topics = which were discussed in last IETF meeting. > > > > I'd like to discuss the topics in different mail threads = respectively. > > (Current draft link: = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > > = **************************************************************************= **** > > > > #3 NPTv6 Use Case > > > > In current draft Section 3.2.1, there is an NPTv6 use case: > > "In some very constrained situations(for example, in the sensors), = the > > network needs ULA as the on-demand and stable addressing which > > doesn't need much code to support address assignment mechanisms = like > > DHCP or full ND (Note: surely it needs SLAAC). If the network also > > needs to connect to the outside, then there can be an NPTv6 = gateway > > which is not subject to extreme resource constraints. Especially = when > > a lightweight isolated network needs to add Internet connectivity, > > this is quite a straightforward and efficient way." > > > > This use case is not based on real experience, but an assumption = that supporting multiple prefixes might be a heavy burden for some = resource-constrained nodes such as sensors. Because it needs to store = multiple addresses and dealing with the address selection problem. > > > > Question 1: > > In last IETF meeting, Lorenzo questioned this assumption whether it = is reasonable. I'd like to hear opinions from you on this issue. If it's = unreasonable, we'll move the use case out of the draft. > > > > Question 2: > > Besides the resource-constrained use case. There is another case = which was raised by Alex and has been talked a lot in 6man two months = ago: one node is assigned a /64, and it is the gateway of multi-subnets. = This might probably happen in the 3GPP terminals. 3GPP R11 supports = DHCP-PD, but former specifications only support /64. Current networks = just haven't implemented R11. > > Besides DHCP-PD, another solution for the multi-subnets is bridging = them at L2. But it is not feasible in some situations. For example, In a = vehicle there might be numerous incompatible L2s. > > > > I think it is a reasonable use case to be documented. > > > > Question 3: > > This question is derived from Question 2. Current draft only refers = NPTv6, but might been other IPv6 NAT implementations available in the = vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) . > > > > Regards, > > Bing > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E248B8EB-758B-4783-B5C7-E1651CFFF515 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

On 30 May 2014, at 02:58, = Lorenzo Colitti <lorenzo@google.com> = wrote:

Owen,

I said "BEFORE = we discuss questions #2 and #3". :-)

The chairs = have expressed concern that this document keeps getting mired in debate. = I'm trying to help. One way to avoid that is to avoid this particular = debate altogether.

This was = pretty much what draft-ietf-v6ops-enterprise-incremental-ipv6-05 = did, which is being published soon. It does include a fairly minimal = reference to NPTv6, and a reference to the ULA draft under discussion = here. 

In the homenet arch text there=92s = again a fairly short paragraph referencing NPTv6, with a short =91health = warning=92 later in the text, to quote:

  = "Note that unlike private IPv4 RFC = 1918 space, the use of ULAs does
   =
not imply use of an IPv6 equivalent of a traditional IPv4 NAT
   [RFC3022], or of NPTv6 prefix-based NAT [RFC6296].  When an IPv6 node
   in a homenet has both a ULA and a globally unique IPv6 address, it
   should only use its ULA address internally, and use its additional
   globally unique IPv6 address as a source address for external
   communications.  This should be the natural behaviour given support
   for Default Address Selection for IPv6 [RFC6724].  By using such
   globally unique addresses between hosts and devices in remote
   networks, the architectural cost and complexity, particularly to
   applications, of NAT or NPTv6 translation is avoided.  As such,
   neither IPv6 NAT or NPTv6 is recommended for use in the homenet
   architecture.  Further, the homenet border router(s) should filter
   packets with ULA source/destination addresses as discussed in
   Section 3.4.2.=94

=85

  "As explained previously, while NPTv6 has =
been proposed for providing
   =
multi-homing support in networks, its use is not recommended in the
   homenet architecture."

Perhaps = something similar can be stated in this ULA = draft.

Tim

Cheers,
Lorenzo

On Fri, May 30, = 2014 at 10:52 AM, Owen DeLong <owen@delong.com> wrote:
I think this use case is absurd.

If you need to communicate to outside world, it=92s perfectly reasonable = to use SLAAC with GUA and there=92s no benefit derived from ULA+NPT.

Owen

On May 29, 2014, at 1:28 AM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:

> Hi, All
>
> We're going to update the ULA draft. Before making a new version, I = think it would be helpful to confirm/discuss several important topics = which were discussed in last IETF meeting.
>
> I'd like to discuss the topics in different mail threads = respectively.
> (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-re= commendations-02)
> = **************************************************************************= ****
>
> #3 NPTv6 Use Case
>
> In current draft Section 3.2.1, there is an NPTv6 use case:
>  "In some very constrained situations(for example, in the = sensors), the
>   network needs ULA as the on-demand and stable addressing = which
>   doesn't need much code to support address assignment = mechanisms like
>   DHCP or full ND (Note: surely it needs SLAAC). If the = network also
>   needs to connect to the outside, then there can be an NPTv6 = gateway
>   which is not subject to extreme resource constraints. = Especially when
>   a lightweight isolated network needs to add Internet = connectivity,
>   this is quite a straightforward and efficient way."
>
> This use case is not based on real experience, but an assumption = that supporting multiple prefixes might be a heavy burden for some = resource-constrained nodes such as sensors. Because it needs to store = multiple addresses and dealing with the address selection problem.
>
> Question 1:
> In last IETF meeting, Lorenzo questioned this assumption whether it = is reasonable. I'd like to hear opinions from you on this issue. If it's = unreasonable, we'll move the use case out of the draft.
>
> Question 2:
> Besides the resource-constrained use case. There is another case = which was raised by Alex and has been talked a lot in 6man two months = ago: one node is assigned a /64, and it is the gateway of multi-subnets. = This might probably happen in the 3GPP terminals. 3GPP R11 supports = DHCP-PD, but former specifications only support /64. Current networks = just haven't implemented R11.
> Besides DHCP-PD, another solution for the multi-subnets is bridging = them at L2. But it is not feasible in some situations. For example, In a = vehicle there might be numerous incompatible L2s.
>
> I think it is a reasonable use case to be documented.
>
> Question 3:
> This question is derived from Question 2. Current draft only refers = NPTv6, but might been other IPv6 NAT implementations available in the = vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ?  (Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) .
>
> Regards,
> Bing
>
> = _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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

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

= --Apple-Mail=_E248B8EB-758B-4783-B5C7-E1651CFFF515-- From nobody Sun Jun 1 09:51:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0791A0008 for ; Sun, 1 Jun 2014 09:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 s-H1Qep5wxds for ; Sun, 1 Jun 2014 09:51:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0921A0005 for ; Sun, 1 Jun 2014 09:51:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8FF4A1B8032 for ; Sun, 1 Jun 2014 09:51:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7A6F019005C; Sun, 1 Jun 2014 09:51:04 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 09:51:04 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <20140601102408.GH46558@Space.Net> Date: Sun, 1 Jun 2014 12:51:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <52967092-EA3D-49D9-9ADC-19A9B47E3C92@nominum.com> References: <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531213133.GB46558@Space.Net> <20140531222321.8A5D8171A140@rock.dv.isc.org> <20140601102408.GH46558@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xqetNUhmnDkBeOXtZr78C4h7MCU Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:51:10 -0000 On Jun 1, 2014, at 6:24 AM, Gert Doering wrote: > - how does the homenet CPE/host know *which* domain to update? > [etc] Daniel Migault has been working on this problem for a while, and there = hasn't been a whole lot of working group participation and review. I = got that some people didn't like the solution Daniel proposed, but we = need to work on this--it would be nice if people could try to come up = with proposals rather than just pointing out the well-known issues that = need to be addressed (although that was certainly a nice summary). From nobody Sun Jun 1 09:54:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C841A0024 for ; Sun, 1 Jun 2014 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Pr8b6MT5_ekM for ; Sun, 1 Jun 2014 09:54:49 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D9F1A001E for ; Sun, 1 Jun 2014 09:54:49 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DFBB61B8032 for ; Sun, 1 Jun 2014 09:54:44 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C922619005C; Sun, 1 Jun 2014 09:54:44 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 09:54:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Sun, 1 Jun 2014 12:54:31 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kY1cOxs6QxG32GTlqrwyMvtKeL0 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:54:51 -0000 On May 31, 2014, at 5:55 PM, Philip Homburg = wrote: > You suggest that every possible piece of software should implement HE? Software that doesn't implement some kind of happy eyeballs mechanism is = going to work poorly on an IPv6 internet. Ask rather whether there = could be some support for HE-like behavior that is relatively easy for = app developers to use, so that they don't fail to use it and wind up = making applications with crappy behaviors during partial outages. From nobody Sun Jun 1 10:37:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2675E1A0025 for ; Sun, 1 Jun 2014 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 wqFY1BHSRX6H for ; Sun, 1 Jun 2014 10:37:16 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74C31A0020 for ; Sun, 1 Jun 2014 10:37:15 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h3so2543842igd.7 for ; Sun, 01 Jun 2014 10:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3ryV+FGCZQqCgF6P2mVSpEkYvhox2vPjlqDTplXYfl0=; b=BzRLWr2kSPj56nsQ7fZkMIc9vntopGKKDvG0RYlRtts4+sZfRRgQkBSmEXUF2jGHb+ AaZSoaIRlbOKQZxlVTJY5WMxC0GGSJxpNSxwuwF+F8CKnrsetutfMD8DpkkmLj1s+K5G Le2c2HNMdXKEZdcStoS2qsl5nP60rpfZ4ahLc2QXsENj9kk239CDU+cA9/3jXMBJevkz XGlEo/bbJ2juFquBJGQ1uR65+AMsj0z+O6d9+zbGkc+2e1BIiO25bXTlZ0D6FPM1/D1S 9SX73O9psGSMGZ3CYiPNTYRWonyeS0KxzuiRyx55NEUj99mtRAC699yXTlvseEQ9cQhX 8jZQ== 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-type; bh=3ryV+FGCZQqCgF6P2mVSpEkYvhox2vPjlqDTplXYfl0=; b=VlwOAGA9z8HNbuxUKRfUg8n7E+Z23C4KqAnACzlb94+7BpB62LPs7YNyhBxOjFWtX9 Oq40BdWRGwB9X99986KaCuLZ86i95J+ccaghtY1o0H/2LygpyrsfqDniHRo5qDnc9DRU Qtle6ZwbDBy8Ht8E7REMtiFc0j1/XwQV4N/AIRMD7Hj0KTY0pjXOz189SJD82vqzNmuY pD5HpKwqjoQNoXN4cYGjgtP7gKMcWWWGEcfqHioNKeJ4rg/Zfrbni5OwvGcxO80ainqX bOgmKg2k++MqQS0YlzWVy7sa8BF02/21Pm55NzXrMtP9NOxmLjnIXolRf/wDxddK99DV 9nkA== X-Gm-Message-State: ALoCoQl3d+hoqJ1+VpCGo2uCRyh7woOI8tO3Sj79mhX9GM83IC/VlLujock+tXDKHZ3VBvyEkGY/ X-Received: by 10.42.211.205 with SMTP id gp13mr28307907icb.29.1401644230541; Sun, 01 Jun 2014 10:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Sun, 1 Jun 2014 10:36:50 -0700 (PDT) In-Reply-To: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> From: Lorenzo Colitti Date: Mon, 2 Jun 2014 02:36:50 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf301d39fc76aecb04fac9bab1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VTNtevLjIL3BHV8hQGNLT7k5y7k Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 17:37:17 -0000 --20cf301d39fc76aecb04fac9bab1 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 1:54 AM, Ted Lemon wrote: > > You suggest that every possible piece of software should implement HE? > > Software that doesn't implement some kind of happy eyeballs mechanism is > going to work poorly on an IPv6 internet. Because...? --20cf301d39fc76aecb04fac9bab1 Content-Type: text/html; charset=UTF-8
On Mon, Jun 2, 2014 at 1:54 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
> You suggest that every possible piece of software should implement HE?

Software that doesn't implement some kind of happy eyeballs mechanism is going to work poorly on an IPv6 internet.

Because...?
--20cf301d39fc76aecb04fac9bab1-- From nobody Sun Jun 1 13:10:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B57F1A007E for ; Sun, 1 Jun 2014 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0m5pHkt9IgeW for ; Sun, 1 Jun 2014 13:10:26 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808F61A0078 for ; Sun, 1 Jun 2014 13:10:26 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 767A21B81EB for ; Sun, 1 Jun 2014 13:10:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 56DE019005C; Sun, 1 Jun 2014 13:10:21 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 13:10:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Sun, 1 Jun 2014 16:10:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i74Zm3MHhQNoe_k3wh8BMGUpjnM Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:10:27 -0000 On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti wrote: > Because...? Because any situation where you are multi-homed, if either home fails = and your software can't try both to see which one is working, there's a = good chance it will fail to connect. From nobody Sun Jun 1 13:24:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621551A007B for ; Sun, 1 Jun 2014 13:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 ZvytfdVy-Gxp for ; Sun, 1 Jun 2014 13:24:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E9E081A008C for ; Sun, 1 Jun 2014 13:24:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WrCJ2-0000DVC; Sun, 1 Jun 2014 22:24:36 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> In-reply-to: Your message of "Sun, 1 Jun 2014 16:10:18 -0400 ." <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> Date: Sun, 01 Jun 2014 22:24:36 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/itxS8TJRNvgxJeOBMEYkDa5B2S8 Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:24:45 -0000 In your letter dated Sun, 1 Jun 2014 16:10:18 -0400 you wrote: >On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti wrote: >> Because...? > >Because any situation where you are multi-homed, if either home fails >and your software can't try both to see which one is working, there's a >good chance it will fail to connect. Nice how this thread evolves: - Use PI space, it works (but is not really scalable) - No, no, get with the program. Get multi-homed on PA. - We don't actually have anything for servers and multi-homed PA. - Every piece of software has to do HE because of how multi-homed PA fails. Great way of advertising IPv6. From nobody Sun Jun 1 13:32:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1361A008C for ; Sun, 1 Jun 2014 13:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 RxAi9y3vwu23 for ; Sun, 1 Jun 2014 13:32:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AB61A0086 for ; Sun, 1 Jun 2014 13:31:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DB0E1B806B for ; Sun, 1 Jun 2014 13:31:55 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 06FD019005C; Sun, 1 Jun 2014 13:31:55 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 13:31:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Sun, 1 Jun 2014 16:31:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3F6C2102-4572-41AE-B31F-5ED5183954C0@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bhSdq9SnhWQUB077ZF7Q1Ea6ZZQ Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:32:01 -0000 On Jun 1, 2014, at 4:24 PM, Philip Homburg = wrote: > Nice how this thread evolves: > - Use PI space, it works (but is not really scalable) > - No, no, get with the program. Get multi-homed on PA. > - We don't actually have anything for servers and multi-homed PA. > - Every piece of software has to do HE because of how multi-homed PA = fails. >=20 > Great way of advertising IPv6. Every piece of software that uses the network has to use DNS for = ease-of-use, and has to use some kind of API to establish connections or = send datagrams. There is no reason why this API can't do happy = eyeballs for the application without requiring any complexity _in_ the = application. Indeed, the API provided by Apple already provides this = capability for free. In comparison to what most apps have to do to work because of the = higher-layer protocols they use (e.g., RESTful APIs have to support HTTP = and TLS, streaming APIs have to support loss detection and data rate = adaptation), doing happy eyeballs is the picture of simplicity. The = only reason it seems like it's not is that your mental model of a = network API is (apparently) the BSD sockets API, which, while extremely = useful, is pretty bare-bones. From nobody Sun Jun 1 13:33:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E811A027A for ; Sun, 1 Jun 2014 13:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 RmUJzaETTAVB for ; Sun, 1 Jun 2014 13:32:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01F91A0086 for ; Sun, 1 Jun 2014 13:32:59 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s51KWsZk084013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 1 Jun 2014 20:32:54 GMT (envelope-from joelja@bogus.com) Message-ID: <538B6AC3.7020402@bogus.com> Date: Sun, 01 Jun 2014 11:02:43 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Ted Lemon , Philip Homburg References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> In-Reply-To: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QLpoCVPQSm0raINdWf2rkKuoGxlk7Enwi" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 01 Jun 2014 20:32:54 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_rA4bYfdoH_OL0L5D0nJQqkJlJU Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QLpoCVPQSm0raINdWf2rkKuoGxlk7Enwi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/1/14, 9:54 AM, Ted Lemon wrote: > On May 31, 2014, at 5:55 PM, Philip Homburg > wrote: >> You suggest that every possible piece of software should implement >> HE? >=20 > Software that doesn't implement some kind of happy eyeballs mechanism > is going to work poorly on an IPv6 internet. Ask rather whether > there could be some support for HE-like behavior that is relatively > easy for app developers to use, so that they don't fail to use it and > wind up making applications with crappy behaviors during partial > outages. Assumption of the Existence of HE is a pretty dodgy proposition. if you're an application and you support it great. but v6-only connected hosts even with 4 translation probably don't bother or even know to try for example. > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --QLpoCVPQSm0raINdWf2rkKuoGxlk7Enwi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOLasMACgkQ8AA1q7Z/VrLjaACghs52DnXetMk9QoDlbUC5Qc2x dXoAnRFtxbBcOyyViI4Q4UuhWu3MnOdY =V/Gn -----END PGP SIGNATURE----- --QLpoCVPQSm0raINdWf2rkKuoGxlk7Enwi-- From nobody Sun Jun 1 13:38:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F395F1A00A6 for ; Sun, 1 Jun 2014 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Y9HuRgJvzRKH for ; Sun, 1 Jun 2014 13:38:48 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F5B1A0086 for ; Sun, 1 Jun 2014 13:38:48 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CAFD11B806B for ; Sun, 1 Jun 2014 13:38:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BD5BE19005C; Sun, 1 Jun 2014 13:38:43 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 13:38:43 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <538B6AC3.7020402@bogus.com> Date: Sun, 1 Jun 2014 16:38:41 -0400 Content-Transfer-Encoding: 7bit Message-ID: <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jwG2-8BcQ8yCjWQgImzaQz-ZNUQ Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:38:50 -0000 On Jun 1, 2014, at 2:02 PM, joel jaeggli wrote: > Assumption of the Existence of HE is a pretty dodgy proposition. Then we can't do multihoming without NAT. From nobody Sun Jun 1 13:45:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCCF1A027E for ; Sun, 1 Jun 2014 13:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RGfuSeGWrJTT for ; Sun, 1 Jun 2014 13:45:31 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6631A027D for ; Sun, 1 Jun 2014 13:45:30 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id v10so2725350pde.37 for ; Sun, 01 Jun 2014 13:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dk80W4k/Li1+X5DWEdk4yKtnR0UMrpWSHZQHr22NB4g=; b=p5NOulclF2GlB0OeO4+Woznl82NGT3Xpu2OTBiMKQzcz0/m2UCFm/Tp/PE354RWHA6 LnzyZt9L3irZF+S4CwM7VL6AaWyCtNrbKYTwNd+XRvJdS0aHaDoXYeeLXlJJ2DmCkUVl 33DhdLnJmCnPzpkXKh/jCkBxQ4XB8nkfTWPQpVm5RiW4nGeAl0VFbfz3qmbvY02f2m7c v0FgSmmZ+XBzaXMSZLccmX3N+e8wEhnHbNixC2muW3IfR2DqT2ErPrWIqPU8zbiwSPdI bzn8xh4KW7o5+CH3FcxE7aVbCYaDFluEzvhXRWBZZToYC9hjPqb2lGLjFL4PNeN/Ykx+ MaVg== X-Received: by 10.66.232.166 with SMTP id tp6mr34965660pac.127.1401655525931; Sun, 01 Jun 2014 13:45:25 -0700 (PDT) Received: from [192.168.178.23] (158.198.69.111.dynamic.snap.net.nz. [111.69.198.158]) by mx.google.com with ESMTPSA id qv9sm16831687pbc.71.2014.06.01.13.45.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 13:45:25 -0700 (PDT) Message-ID: <538B90E2.4090806@gmail.com> Date: Mon, 02 Jun 2014 08:45:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <3F6C2102-4572-41AE-B31F-5ED5183954C0@nominum.com> In-Reply-To: <3F6C2102-4572-41AE-B31F-5ED5183954C0@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jgpYk2UnI2ll-j3ZjJ6rzjbLwys Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:45:36 -0000 On 02/06/2014 08:31, Ted Lemon wrote: > On Jun 1, 2014, at 4:24 PM, Philip Homburg wrote: >> Nice how this thread evolves: >> - Use PI space, it works (but is not really scalable) >> - No, no, get with the program. Get multi-homed on PA. >> - We don't actually have anything for servers and multi-homed PA. >> - Every piece of software has to do HE because of how multi-homed PA fails. >> >> Great way of advertising IPv6. > > Every piece of software that uses the network has to use DNS for ease-of-use, and has to use some kind of API to establish connections or send datagrams. There is no reason why this API can't do happy eyeballs for the application without requiring any complexity _in_ the application. Indeed, the API provided by Apple already provides this capability for free. There's a lot I'm tempted to say about this, but I've already said it elsewhere: http://www.sigcomm.org/ccr/papers/2014/April/0000000.0000008 N.B. PLEASE don't debate that article on this list. Brian > In comparison to what most apps have to do to work because of the higher-layer protocols they use (e.g., RESTful APIs have to support HTTP and TLS, streaming APIs have to support loss detection and data rate adaptation), doing happy eyeballs is the picture of simplicity. The only reason it seems like it's not is that your mental model of a network API is (apparently) the BSD sockets API, which, while extremely useful, is pretty bare-bones. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Sun Jun 1 13:51:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A711A0091 for ; Sun, 1 Jun 2014 13:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ZoMOKPIxg3C3 for ; Sun, 1 Jun 2014 13:51:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BCA1A0088 for ; Sun, 1 Jun 2014 13:51:17 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 422CC60ABF for ; Sun, 1 Jun 2014 22:51:11 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1323A60A8E for ; Sun, 1 Jun 2014 22:51:11 +0200 (CEST) Received: (qmail 92617 invoked by uid 1007); 1 Jun 2014 22:51:11 +0200 Date: Sun, 1 Jun 2014 22:51:11 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20140601205110.GM46558@Space.Net> References: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j9Tn6TqnhYfbUFc83nUxmepCbNo Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:51:20 -0000 Hi, On Sun, Jun 01, 2014 at 04:38:41PM -0400, Ted Lemon wrote: > On Jun 1, 2014, at 2:02 PM, joel jaeggli wrote: > > Assumption of the Existence of HE is a pretty dodgy proposition. > > Then we can't do multihoming without NAT. For multihoming *clients*, you don't need HE (or, specifically, HE doesn't solve the issue of *source* address failover anyway in it's current form). Server multihoming works without HE if you can afford to be patient, like, you're an SMTP client and it doesn't matter whether the TCP session connects in 10ms or 2 minutes, as long as it transmits the mail in question (which, incidentially, HE doesn't guarantee - it will give you "that address gave back SYN-ACK first" but no guarantees that the TCP path actually works for packets with data in) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sun Jun 1 15:23:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA271A00D7 for ; Sun, 1 Jun 2014 15:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RWl97qrvlrBk for ; Sun, 1 Jun 2014 15:23:49 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC5C1A00CF for ; Sun, 1 Jun 2014 15:23:49 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so2778051pde.0 for ; Sun, 01 Jun 2014 15:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LI9D76kfvoed5TlsGMoqUNeQE7tsf/N2ghilIMjOY3I=; b=Nn9E5vLI9ifzTM6hS4mau5TyK4QgbsWcvwYzxgD9l7DUllLwClxCDRRFf6HKTZWL5d WuMFMlgmnHI0TMMrJ6Bx7/ETbTaDkmLiuku7xiKpNNitsHhs8PmGyo9D5C4RSekh5ARi XM+L8+XaQWTDN5K7C19HEYvpkcVmkl6YUj7axOr7N892JJY140LuFbDBJepkcD7zo+4f OEeAUI/Z5rahw+5xRAJ21O7Xg+1s0mmRrquBv4wu7wvicVNp+xkvwr3MvHmv1Jfw0qRz WfLsfuM/VVvNavtXtNj7llxKxa+sydwAgceU6RCdgWa19MzyWIyyLT7TBvfmXtBg4s1R ZplA== X-Received: by 10.68.227.4 with SMTP id rw4mr35628391pbc.3.1401661424561; Sun, 01 Jun 2014 15:23:44 -0700 (PDT) Received: from [192.168.178.23] (158.198.69.111.dynamic.snap.net.nz. [111.69.198.158]) by mx.google.com with ESMTPSA id dz4sm54114615pab.47.2014.06.01.15.23.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 15:23:43 -0700 (PDT) Message-ID: <538BA7EC.1030801@gmail.com> Date: Mon, 02 Jun 2014 10:23:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> In-Reply-To: <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/46wGB0ev5shgXOzyRBYOPTBQ_9M Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 22:23:50 -0000 On 02/06/2014 08:38, Ted Lemon wrote: > On Jun 1, 2014, at 2:02 PM, joel jaeggli wrote: >> Assumption of the Existence of HE is a pretty dodgy proposition. > > Then we can't do multihoming without NAT. That's not what RFC 7157 says. Not even close. Brian From nobody Sun Jun 1 16:12:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8A1A00F5 for ; Sun, 1 Jun 2014 16:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 c8QMrdZwJBKZ for ; Sun, 1 Jun 2014 16:12:19 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B34F21A00ED for ; Sun, 1 Jun 2014 16:12:19 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 9829E3493BB; Sun, 1 Jun 2014 23:12:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9833A160067; Sun, 1 Jun 2014 23:17:14 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 68FE1160053; Sun, 1 Jun 2014 23:17:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 303E9171FD22; Mon, 2 Jun 2014 09:11:40 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> In-reply-to: Your message of "Sun, 01 Jun 2014 22:24:36 +0200." Date: Mon, 02 Jun 2014 09:11:40 +1000 Message-Id: <20140601231140.303E9171FD22@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S7Me0EGeFmtkG78c1HAK1x1Dibo Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 23:12:25 -0000 In message , Philip Homburg writes: > In your letter dated Sun, 1 Jun 2014 16:10:18 -0400 you wrote: > >On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti wrote: > >> Because...? > > > >Because any situation where you are multi-homed, if either home fails > >and your software can't try both to see which one is working, there's a > >good chance it will fail to connect. > > Nice how this thread evolves: > - Use PI space, it works (but is not really scalable) > - No, no, get with the program. Get multi-homed on PA. > - We don't actually have anything for servers and multi-homed PA. > - Every piece of software has to do HE because of how multi-homed PA fails. > > Great way of advertising IPv6. Every piece of client software should already support multi-homing. This is about supporting it *better* so there isn't the big delay when switching to the second address because the link at the other end is down. The stack should be choosing source addresses which have working outbound paths. Selecting destination addresses is up to the application. This is about making the error cases work better which quite frankly should have been done years ago for IPv4. The only ones that don't benefit from this is GLB developers. Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jun 1 18:01:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81761A0109 for ; Sun, 1 Jun 2014 18:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 jnWAiLXeHbrU for ; Sun, 1 Jun 2014 18:01:44 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C151A0107 for ; Sun, 1 Jun 2014 18:01:44 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id lx4so3885786iec.19 for ; Sun, 01 Jun 2014 18:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5+lJx3zpYcFtXTm91Xvul2kCjOm1Ng6/HJ8Rrh75JfQ=; b=CBErIB/SO1OSSxJZwx1pnG1ijvy/ytZxMY7FsiYHLglANhgni/dGEZ5rcCsSCMtHP0 tnG3nasXEWuIpRGxxJauEzAkI6ldsfPylae2VZCZzc4bN/aKTnzXyrc6jNKxchQI+NaP P2segkU9cFzcc71kX12HTCbC72ONRdFzV/BT0BaBfAsIdYdoXFMFad2AgHWTWaA3zGsL YnUpAgNwW9p0jv7kUlYuHCGV0CDSfBpeeaXMEAA8go+sYArQgkXwZi+wg07rlW8PgDY/ RpZwneecn8hoj0o7gFqmmSs9tiTbfZNBUxotXlpGgJJ9Yl4xCb6+xk6a/PXGbpi6O+bd t71Q== 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-type; bh=5+lJx3zpYcFtXTm91Xvul2kCjOm1Ng6/HJ8Rrh75JfQ=; b=OdqEwYR80UiehvyAJyOgeA12M7QCvhwe3mpXFUd0DHtutKOk9eVXf0PeFehkyTgmCA ElMD/VazfcHHYDDx3a5/Ef5WTRGsFAWpHlHyOySWZeCqPXGC0UtnTH1nAc0UfDthENfA pkIfp4tO6Hilw6t6Qtp9xI5kWs7ZpYrQBvCptSb13nfgitTh267HRyAo3DtD24E3/PrF s1CUHt0WAOnmf23bG/0pG9W8ZaGhabgGeNbsYoNoqKnkUfbitzGIYiCyguBcpcbS9hv9 2i6fpT3vX6y6dJ22N6wxakCjKVBoUAop3YTpkrRGL3oCJk2UY+UBS4zEmJlAf6PLSYjA EkIQ== X-Gm-Message-State: ALoCoQn8gnzjGXEnICo14bGRV1ztKzSzdozAInlR0wR1z0SthGezvsANpnCtzqW01+O75nzCaDp1 X-Received: by 10.50.110.98 with SMTP id hz2mr7232309igb.47.1401670899057; Sun, 01 Jun 2014 18:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Sun, 1 Jun 2014 18:01:18 -0700 (PDT) In-Reply-To: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> From: Lorenzo Colitti Date: Mon, 2 Jun 2014 10:01:18 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0111d16007f85604facff0ec Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/htd36JseBbFoNTLa5cYjv2ZTMDY Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:01:47 -0000 --089e0111d16007f85604facff0ec Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 5:10 AM, Ted Lemon wrote: > On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti wrote: > > Because...? > > Because any situation where you are multi-homed, if either home fails and > your software can't try both to see which one is working, there's a good > chance it will fail to connect. > And this problem is specific to IPv6 because...? --089e0111d16007f85604facff0ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 2, 2014 at 5:10 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti = <lorenzo@google.com> wrote:=
> Because...?

Because any situation where you are multi-homed, if either home fails and y= our software can't try both to see which one is working, there's a = good chance it will fail to connect.

And this problem is specific to IPv6 because...?=C2=A0
--089e0111d16007f85604facff0ec-- From nobody Sun Jun 1 18:06:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAFE1A00A6 for ; Sun, 1 Jun 2014 18:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 BNgwXrjo8-_J for ; Sun, 1 Jun 2014 18:06:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0ED21A010D for ; Sun, 1 Jun 2014 18:06:23 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0AE211B8204 for ; Sun, 1 Jun 2014 18:06:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B513519005C; Sun, 1 Jun 2014 18:06:18 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 18:06:18 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Sun, 1 Jun 2014 21:06:16 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SowCWzxoLXrp1dZS75mDPtIh8sU Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:06:26 -0000 On Jun 1, 2014, at 9:01 PM, Lorenzo Colitti wrote: > And this problem is specific to IPv6 because...?=20 IPv4 never claimed to provide ubiquitous support for multihoming. IPv6 = kind of does. From nobody Sun Jun 1 18:13:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B081A0107 for ; Sun, 1 Jun 2014 18:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 66Kn8sUW1EU1 for ; Sun, 1 Jun 2014 18:13:19 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF821A00A6 for ; Sun, 1 Jun 2014 18:13:19 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id uy17so2823345igb.9 for ; Sun, 01 Jun 2014 18:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jfWxGJ6MQevQSztXTYAcdb+dVkSlyWICuMGBwhsLOwU=; b=DENjpvG4ZPOFmoumHWQ1aPiG+oUB55zeQ/juT+49adwMQCRXTq5r1JbIixEO2c+VIo p49o/R21f/gEm3J0ZZtPFKDyyIfNZHvps6rQDsfKURuOdV4re4W2ORx+KERdj2vL/ti1 OWTLb9H7Mw51lZBwZStKrho+VXW0uvaHDm+Aq18lVkVKbuXrTrh4x3i88sR90cCWGivg 3blqXWy7006wcEAvSdI8M9WqNB8IBCWB5wNzSS62NiYq+eUHv1KqwI3MPJehj1eC68SV bg98PkT66KznI3Zh3bp5OPzHvgN003b3R4wdaFoJj9XIUsiIf4ZqbrSkiNzlCiPjMhQu xEgw== 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-type; bh=jfWxGJ6MQevQSztXTYAcdb+dVkSlyWICuMGBwhsLOwU=; b=lQWj4twRrPDiAypBKOpWA6fFMHbkAEtSBOEARRj3x5xIF4OdETui2jP8epgSy8Jubn HQm2TAHK3GySOrPNPWsPqgNIk3M3hRqUjLufauanQIqr9NER0lWzLGbv57zx4hPbPVT5 B+FZAnwjzQnYS3ZbC5pqOWHn5qExtkWta6MgW3a1DUHW9XdyDo4KMgLGDqsHhzZI4wZ+ qj5oMQRI99rsdTBbdgWJyJkqZYy3hQUrCmkaY0P37YMw0IFdbbcuzugofKwTnor6tDGM pRAXr/VcilG+Jiy9RERuwCnseClWvc3SyYS4GHiRuR3xwA336mhNdiWf6jyR3P9MTxig kw+Q== X-Gm-Message-State: ALoCoQnGdWM7DmMDUO2mo0iapqszcSc1hGeFXLP+bJj3H8+FAkW31g8mCvDbPrDa9uhvxp9NgT2z X-Received: by 10.42.85.19 with SMTP id o19mr32515590icl.34.1401671594067; Sun, 01 Jun 2014 18:13:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Sun, 1 Jun 2014 18:12:53 -0700 (PDT) In-Reply-To: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> From: Lorenzo Colitti Date: Mon, 2 Jun 2014 10:12:53 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf30363e8974e67404fad019e1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rIza-2kMGS0PW4bkY5ij0tvJnmk Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:13:22 -0000 --20cf30363e8974e67404fad019e1 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 10:06 AM, Ted Lemon wrote: > > And this problem is specific to IPv6 because...? > > IPv4 never claimed to provide ubiquitous support for multihoming. IPv6 > kind of does. > There is no such claim. The only difference between IPv4 and IPv6 with regard to multihoming is that IPv6 supports more than one IPv6 address on the same interface, whereas some IPv4 implementations don't. --20cf30363e8974e67404fad019e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 2, 2014 at 10:06 AM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
> And this problem is spe= cific to IPv6 because...?

IPv4 never claimed to provide ubiquitous support for multihoming. =C2= =A0 IPv6 kind of does.

There is no such cl= aim. The only difference between IPv4 and IPv6 with regard to multihoming i= s that IPv6 supports more than one IPv6 address on the same interface, wher= eas some IPv4 implementations don't.
--20cf30363e8974e67404fad019e1-- From nobody Sun Jun 1 18:19:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B161A0107 for ; Sun, 1 Jun 2014 18:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 FcPKJNo_9VaG for ; Sun, 1 Jun 2014 18:19:19 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F781A00A6 for ; Sun, 1 Jun 2014 18:19:19 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6591B1B81BC for ; Sun, 1 Jun 2014 18:19:14 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5AC5119005C; Sun, 1 Jun 2014 18:19:14 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 18:19:08 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Sun, 1 Jun 2014 21:19:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tJ4Ij9MF_estzYDNTx9TcfccCrM Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:19:20 -0000 On Jun 1, 2014, at 9:12 PM, Lorenzo Colitti wrote: > There is no such claim. The only difference between IPv4 and IPv6 with = regard to multihoming is that IPv6 supports more than one IPv6 address = on the same interface, whereas some IPv4 implementations don't. I would like multihoming to work, and I'd like it to work without NAT. = If you would like something else, that's okay. But my impression is = that I am not alone in thinking this is a key benefit of IPv6 over IPv4, = even if it's still not fully baked (RFC 7157 notwithstanding). From nobody Sun Jun 1 18:37:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4741A010C for ; Sun, 1 Jun 2014 18:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 bCiQDcHLoGAt for ; Sun, 1 Jun 2014 18:37:47 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CB01A010B for ; Sun, 1 Jun 2014 18:37:47 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rl12so3727539iec.7 for ; Sun, 01 Jun 2014 18:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Avu0ywqbFj21JGngiC16L7hvwn5FcFQl24nEhXtnjHs=; b=V15JtSn/Gz+GJbzVPrHRLeSa6zo92a6z9CyuIDnS2J2o4N6CrwXr/XQ3wZ5GvcRRMn bhh1rRQCUw89UYURrGjFrfFUQT+QH9oX0YqhrO+PBFqYG8Guo5qHWsZ6FNdtcn+aeZF/ fZ5ZgnZNJOrJM6Wrew4tdl17/7FFqx9k8JKiEEt+kBFjfjiDxBelhLEEn7svcy3ct2/t eJ5JKEt3WvOVoMnthO8SvUjjnl+rVVEC4/bw8h3J8lph84jUqD2ATBN03L3BxGD6vEm0 lFVl+f9+8SfwwwiQAsbmM9EjG5gVCrCoP5QvSHV0Fbmh1XoXxXgOZQ4OVTOVcSuOb6v0 MDpg== 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-type; bh=Avu0ywqbFj21JGngiC16L7hvwn5FcFQl24nEhXtnjHs=; b=c0ll4o+RAyfjuFrkHw2NWHhTqhoXDRLl5vthQhRDcN8WgJoLaDnvZlr0cUya5fKs78 8Pu/oV5SdFaJ3DL8s43Og4tPKQe7DPaabcd3N2Q+vpYPDEqkSSYtrAj3p4tMfqVYjYH7 ZpWRlXpQ5KivC6NmCfnbpQskReQ39d43mMrLSoH0N4YufoFJXb0awyj5C/OrZeGuj9Qi lE1osVOeUQGoDbzs2+uUX46KmVX0uubSzPeLpM69s/ROo8Y7FtK8c/g0MqYXaLUeRYet jrgvK8mJthbACAA38jll+aBsWNvuNZgr00mkpByaKW8Kj3ya7nuqVyeA7i7q/V9RQzaI BJyQ== X-Gm-Message-State: ALoCoQkxyuQmjPQUynXKWNtw8vICDkZEv68Q0HFib9YZPM56KTzjW1vbcm7uzDAkDuTQemlDM4iz X-Received: by 10.50.87.102 with SMTP id w6mr15739118igz.31.1401673061938; Sun, 01 Jun 2014 18:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Sun, 1 Jun 2014 18:37:21 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> From: Lorenzo Colitti Date: Mon, 2 Jun 2014 10:37:21 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=047d7bf18330f2d30f04fad07020 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jPIxINhClC4-M3Tl1GaZEdsr80U Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:37:48 -0000 --047d7bf18330f2d30f04fad07020 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 1, 2014 at 10:45 PM, Tim Chown wrote: > "As explained previously, while NPTv6 has been proposed for providing > > multi-homing support in networks, its use is not recommended in the > homenet architecture." > > > Perhaps something similar can be stated in this ULA draft. > Having a statement in there that NPTv6 is experimental and not recommended and not including use case that uses NPTv6 or NAT sounds good to me. But I don't know if there we can reach rough consensus on such a statement. --047d7bf18330f2d30f04fad07020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jun 1, 2014 at 10:45 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
"As explained previ= ously, while NPTv6 has been proposed for providing 
   multi-homing support in networks, its use is not recomme=
nded in the
   homenet architecture."

Perhaps some= thing similar can be stated in this ULA draft.

Having a statement in there that NPTv6 is experimenta= l and not recommended and not including use case that uses NPTv6 or NAT sou= nds good to me. But I don't know if there we can reach rough consensus = on such a statement.
--047d7bf18330f2d30f04fad07020-- From nobody Sun Jun 1 18:38:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485641A011A for ; Sun, 1 Jun 2014 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 xOT46ZBd_iag for ; Sun, 1 Jun 2014 18:38:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id C80401A010B for ; Sun, 1 Jun 2014 18:38:38 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 61C193493BD; Mon, 2 Jun 2014 01:38:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CA90D160068; Mon, 2 Jun 2014 01:44:03 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 94D8E160067; Mon, 2 Jun 2014 01:44:03 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 875B917236AC; Mon, 2 Jun 2014 11:38:29 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> In-reply-to: Your message of "Sun, 01 Jun 2014 21:06:16 -0400." Date: Mon, 02 Jun 2014 11:38:29 +1000 Message-Id: <20140602013829.875B917236AC@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/57eRy042k3sydLFJ376AOdu4dpg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:38:41 -0000 In message , Ted Lemon writes : > On Jun 1, 2014, at 9:01 PM, Lorenzo Colitti wrote: > > And this problem is specific to IPv6 because...? > > IPv4 never claimed to provide ubiquitous support for multihoming. IPv6 kind > of does. IPv6 adds multiple addresses on a interface. Multihoming support is transport family agnostic. Multihoming support is supposed to be done in IPv4 applications unless you have a very good reason to not support it or do you think SHOULD means it is a optional part of IPv4? RFC 1123 2.3 Applications on Multihomed hosts When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference. Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4. When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. The "specific destination address" is defined in the "IP Addressing" section of the companion RFC [INTRO:1]. Similarly, a server application that opens multiple TCP connections to the same client SHOULD use the same local IP address for all. All dual stack machines are multihomed. HE is basically about fast failover when the destination addresses are unreachable. This is not hard to do. From memory BSD 4.2 supported non blocking connect which is all that is required from the IP stack to do fast failover. Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jun 1 18:57:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815871A0125 for ; Sun, 1 Jun 2014 18:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 AMPu6LBDzZhl for ; Sun, 1 Jun 2014 18:56:59 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781A01A0021 for ; Sun, 1 Jun 2014 18:56:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8D47A1B8213 for ; Sun, 1 Jun 2014 18:56:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 575DE19005C; Sun, 1 Jun 2014 18:56:54 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 18:56:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <20140602013829.875B917236AC@rock.dv.isc.org> Date: Sun, 1 Jun 2014 21:56:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <99184212-DCBA-4280-BF86-6D4E15CBFAA6@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ncjPbu8pBlMzZymrOm3T5gMQLDI Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:57:00 -0000 On Jun 1, 2014, at 9:38 PM, Mark Andrews wrote: > Multihoming support is supposed to be done in IPv4 applications > unless you have a very good reason to not support it or do you think > SHOULD means it is a optional part of IPv4? Your quote from RFC 1123 is focused on incoming connections, not = outgoing connections. This is a different problem than what I'm = talking about. From nobody Sun Jun 1 18:59:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB941A013B for ; Sun, 1 Jun 2014 18:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 udTzz56ngI3q for ; Sun, 1 Jun 2014 18:59:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7D51A0129 for ; Sun, 1 Jun 2014 18:59:48 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s521xcIM085940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 01:59:41 GMT (envelope-from joelja@bogus.com) Message-ID: <538BDA84.6030800@bogus.com> Date: Sun, 01 Jun 2014 18:59:32 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Ted Lemon , Lorenzo Colitti References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> In-Reply-To: <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PjhS4Q7tPgxqFg9Aj3jffdGvGw9SGudv8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 02 Jun 2014 01:59:41 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N-hmHCbNhTlWJbQ9myyWteKWhzI Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 01:59:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PjhS4Q7tPgxqFg9Aj3jffdGvGw9SGudv8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/1/14, 6:19 PM, Ted Lemon wrote: > On Jun 1, 2014, at 9:12 PM, Lorenzo Colitti > wrote: >> There is no such claim. The only difference between IPv4 and IPv6 >> with regard to multihoming is that IPv6 supports more than one IPv6 >> address on the same interface, whereas some IPv4 implementations >> don't. >=20 > I would like multihoming to work, and I'd like it to work without > NAT. If you would like something else, that's okay. But my > impression is that I am not alone in thinking this is a key benefit > of IPv6 over IPv4, even if it's still not fully baked (RFC 7157 > notwithstanding). Ted I think you need rethink what you're claiming. for one rfc 6555 makes no claims about ipv6 address selection between multiple addresses. it in fact sets aside the issue of having more than the two address familes to chose from. I daresay if you have six v6 routes you probably don't want to make six requests and see which one is fastest as a general rule. you'remore likely to do ecmp if you simply treat all nexthops as though they were equivalent, which you might not want to do if they aren't (backup via LTE is probably not something you want to exercise all the time even if it's equivlant speed to your cable connection because it's more costly and has a datacap). source address selection based on nexthop is pretty straight forward. most unixes can do that. invalidating a nexthop when the route should no longer be used is propertly the domain of routing. This is not even a benifit of ipv6 in the sense that it can work in ipv4 as anyone with an appropriately configured router can attest (it's what the multihomed nat box actually does after all). 212.162.4.234 149.11.21.194 62.115.37.146 are all on same router for example. > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --PjhS4Q7tPgxqFg9Aj3jffdGvGw9SGudv8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOL2oQACgkQ8AA1q7Z/VrIXiQCfahh7ySN+EKefX2zsG0DeYDbL ZbwAn1awKMvsm0xtHcwOkW7n8c7lNnoH =GPcN -----END PGP SIGNATURE----- --PjhS4Q7tPgxqFg9Aj3jffdGvGw9SGudv8-- From nobody Sun Jun 1 19:10:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74B1A0155 for ; Sun, 1 Jun 2014 19:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 aOWN_oOoy_Tq for ; Sun, 1 Jun 2014 19:10:17 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB7F1A0150 for ; Sun, 1 Jun 2014 19:10:17 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F37031B81BC for ; Sun, 1 Jun 2014 19:10:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E8C8719005C; Sun, 1 Jun 2014 19:10:12 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 19:10:12 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <538BDA84.6030800@bogus.com> Date: Sun, 1 Jun 2014 22:10:10 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MbSr5BHmPZXKPh0J1KnTuISLiG8 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:10:19 -0000 On Jun 1, 2014, at 9:59 PM, joel jaeggli wrote: > Ted I think you need rethink what you're claiming. for one rfc 6555 > makes no claims about ipv6 address selection between multiple = addresses. > it in fact sets aside the issue of having more than the two address > familes to chose from. I daresay if you have six v6 routes you = probably > don't want to make six requests and see which one is fastest as a > general rule. How is this different than doing happy eyeballs between v4 and v6? Is = it different because you're sextuply multi-homed? I agree that that = begins to look a bit problematic, but the more usual two-provider case = is pretty much the same as regular happy eyeballs. > you'remore likely to do ecmp if you simply treat all > nexthops as though they were equivalent, which you might not want to = do > if they aren't (backup via LTE is probably not something you want to > exercise all the time even if it's equivlant speed to your cable > connection because it's more costly and has a datacap). Right, that's a problem. > source address selection based on nexthop is pretty straight forward. > most unixes can do that. invalidating a nexthop when the route should = no > longer be used is propertly the domain of routing. This is not even a > benifit of ipv6 in the sense that it can work in ipv4 as anyone with = an > appropriately configured router can attest (it's what the multihomed > nat box actually does after all). I've never operated one of these, but I'll take your word for it. The = fact that it works with IPv4 and NAT isn't very interesting to me. Correct me if I am wrong, but what you have written appears to be a more = detailed way of saying "happy eyeballs for multihoming won't happen, in = my opinion, and multihoming for connection originators probably won't = happen either, at least without NAT." If so, that's a fine opinion to = have, and may even be correct, but it's not an opinion I am willing to = just accept without trying to do better (according to my opinion as to = what's "better"). From nobody Sun Jun 1 19:28:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865A01A0284 for ; Sun, 1 Jun 2014 19:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 5laPYRINjU-3 for ; Sun, 1 Jun 2014 19:28:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7AF1A0155 for ; Sun, 1 Jun 2014 19:28:25 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s522SHux086041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 02:28:18 GMT (envelope-from joelja@bogus.com) Message-ID: <538BE13C.7050900@bogus.com> Date: Sun, 01 Jun 2014 19:28:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> In-Reply-To: <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S4mE1Owgvgg82nWr8fJ1g31bKJh5H04Ev" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 02 Jun 2014 02:28:19 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jwFuS6x5gxnQ56w5xlIAgbmEiII Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:28:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S4mE1Owgvgg82nWr8fJ1g31bKJh5H04Ev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/1/14, 7:10 PM, Ted Lemon wrote: > On Jun 1, 2014, at 9:59 PM, joel jaeggli wrote: >> Ted I think you need rethink what you're claiming. for one rfc >> 6555 makes no claims about ipv6 address selection between multiple >> addresses. it in fact sets aside the issue of having more than the >> two address familes to chose from. I daresay if you have six v6 >> routes you probably don't want to make six requests and see which >> one is fastest as a general rule. >=20 > How is this different than doing happy eyeballs between v4 and v6? > Is it different because you're sextuply multi-homed? I agree that > that begins to look a bit problematic, but the more usual > two-provider case is pretty much the same as regular happy eyeballs. >=20 >> you'remore likely to do ecmp if you simply treat all nexthops as >> though they were equivalent, which you might not want to do if they >> aren't (backup via LTE is probably not something you want to=20 >> exercise all the time even if it's equivlant speed to your cable=20 >> connection because it's more costly and has a datacap). >=20 > Right, that's a problem. >=20 >> source address selection based on nexthop is pretty straight >> forward. most unixes can do that. invalidating a nexthop when the >> route should no longer be used is propertly the domain of routing. >> This is not even a benifit of ipv6 in the sense that it can work in >> ipv4 as anyone with an appropriately configured router can attest >> (it's what the multihomed nat box actually does after all). >=20 > I've never operated one of these, but I'll take your word for it. > The fact that it works with IPv4 and NAT isn't very interesting to > me. >=20 > Correct me if I am wrong, but what you have written appears to be a > more detailed way of saying "happy eyeballs for multihoming won't > happen, in my opinion, and multihoming for connection originators > probably won't happen either, at least without NAT." nope that's not what I said. > If so, that's > a fine opinion to have, and may even be correct, but it's not an > opinion I am willing to just accept without trying to do better > (according to my opinion as to what's "better"). So don't asssume that every application needs to be aware of and test for which path is working, not only is that needless complexity pushed up into the stack. let your routers do their job and cease routing when their upstream connectivity is lacking. >=20 --S4mE1Owgvgg82nWr8fJ1g31bKJh5H04Ev Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOL4TwACgkQ8AA1q7Z/VrIyZACgi2CCBhdZ8NfkT8zyJ0DOu1Rq qPMAnRqa8m+IhxoHekAJyW6PvFUAAGi0 =QSpJ -----END PGP SIGNATURE----- --S4mE1Owgvgg82nWr8fJ1g31bKJh5H04Ev-- From nobody Sun Jun 1 19:30:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB601A028B for ; Sun, 1 Jun 2014 19:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 EbjK81mK2kip for ; Sun, 1 Jun 2014 19:30:35 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91CD1A028A for ; Sun, 1 Jun 2014 19:30:35 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC6591B81EB for ; Sun, 1 Jun 2014 19:30:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8B15D19005C; Sun, 1 Jun 2014 19:30:30 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 19:30:30 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <538BE13C.7050900@bogus.com> Date: Sun, 1 Jun 2014 22:30:28 -0400 Content-Transfer-Encoding: 7bit Message-ID: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KZKy0h7mS8A6Qkkd0Rnj3WjH3_M Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:30:37 -0000 On Jun 1, 2014, at 10:28 PM, joel jaeggli wrote: > So don't asssume that every application needs to be aware of and test > for which path is working, not only is that needless complexity pushed > up into the stack. let your routers do their job and cease routing when > their upstream connectivity is lacking. Right, but this doesn't actually work. From nobody Sun Jun 1 19:58:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF41A0127 for ; Sun, 1 Jun 2014 19:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 4kUtpkGjMzjR for ; Sun, 1 Jun 2014 19:58:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 648B91A011B for ; Sun, 1 Jun 2014 19:58:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id A951F34940E; Mon, 2 Jun 2014 02:58:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 646E7160069; Mon, 2 Jun 2014 03:04:08 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2CFA6160068; Mon, 2 Jun 2014 03:04:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A659C1723F0A; Mon, 2 Jun 2014 12:58:33 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bog us.com> In-reply-to: Your message of "Sun, 01 Jun 2014 22:30:28 -0400." Date: Mon, 02 Jun 2014 12:58:33 +1000 Message-Id: <20140602025833.A659C1723F0A@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P7MoP6Wct8Qr9k6UxbMX3V7Fozg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:58:44 -0000 In message , Ted Lemon writes : > On Jun 1, 2014, at 10:28 PM, joel jaeggli wrote: > > So don't asssume that every application needs to be aware of and test > > for which path is working, not only is that needless complexity pushed > > up into the stack. let your routers do their job and cease routing when > > their upstream connectivity is lacking. > > Right, but this doesn't actually work. Setting the prefix's preferred lifetime to 0 in RAs when the uplink goes and restoring it when the uplink works does work for non-broken stacks. Yes this is crude but so is advertising default. Withdrawing default is what routers should be doing when there isn't a working default. There is also nothing to prevent a stack trying multiple source addresses when it hasn't been explicitly bound to a source address by the application. The stack doesn't have to complete TCP handshakes if it doesn't need to. If all else fails the application layer is free to explictly try different source addresses. Hiding this detail in a library routine is not hard. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jun 1 20:19:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A0D1A0143 for ; Sun, 1 Jun 2014 20:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 zG80kqn_u1YT for ; Sun, 1 Jun 2014 20:19:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD7A1A0127 for ; Sun, 1 Jun 2014 20:19:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WrImm-0002xF-0R; Mon, 02 Jun 2014 03:19:44 +0000 Date: Sun, 01 Jun 2014 20:19:43 -0700 Message-ID: From: Randy Bush To: Philip Homburg In-Reply-To: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5uW0S016iP7al_GR62gGeIdil4I Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 03:19:52 -0000 > Nice how this thread evolves: > - Use PI space, it works (but is not really scalable) > - No, no, get with the program. Get multi-homed on PA. > - We don't actually have anything for servers and multi-homed PA. > - Every piece of software has to do HE because of how multi-homed PA > fails. you left out - discussion is completely irrelevant. we're talking about INTRAnet randy From nobody Sun Jun 1 20:41:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23251A0140 for ; Sun, 1 Jun 2014 20:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 99P869Sg_kKT for ; Sun, 1 Jun 2014 20:41:06 -0700 (PDT) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39AB1A0127 for ; Sun, 1 Jun 2014 20:41:05 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jun 2014 03:41:00 -0000 Received: from [98.138.101.132] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jun 2014 03:37:56 -0000 Received: from [98.139.214.32] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jun 2014 03:37:53 -0000 Received: from [98.139.212.205] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2014 03:37:53 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 02 Jun 2014 03:37:53 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 506972.67110.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 55214 invoked by uid 60001); 2 Jun 2014 03:37:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401680273; bh=cabBqbGlIhsoNLtgnqmMkbgvrNQLvh/+5Hp+Sp6YoCg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4+oYK24AUScZvr/ymbx8hHZWHUSTBowy6Yfk5e2JhaO29IHHP+WrbvxsUxZoI9cms1Hib7wTbsLYxDhDVRK3xR55ilYL/Z6TmKfEf9oyfzg7KrLVPpcCg5Bup8agk3HhKOnBKp1UaVEp2bahXRpmEiVJQfe/iCNDi6Pz8uwg7Bs= X-YMail-OSG: 7.EaSzoVM1mEsGISYiMDaKg0nnDjvVIlWV6ZQFsXNCs9tlj et3uKg0qFGaK4CyYQMKiuAjjYfMuFxcTsaJzfz_mbn4mAKIAHGggjjgMgib0 x0zbQNkwMgpQuP10tQlG2C9F8_TGOZ7PnevLfKK8OjT_.4Opajw_cvLstb4x JU8PtYSSJVEVcudk.xfLh4o1G_mvPMkqIF65teSC3InHW972spvj.hxjTaLW 0TOnzfiR6kAWJ8r85eNNtCvr9igwUgAhuhV_63.GLlW4zgHvK.DXCVyhX2_a Da7px0GilZTRE_JnJyQFGEEKgASyXQYu28rnsOIyfOlTKDNioMj5rozYoIz9 Qd8AJ2GxMr2AXoUEGan4g6l91dZcqYwFZHp0FAbLN_8eXNdrQJRP9z0IE1lc xK6AYYtrhxUni8Z08EgYTF6u6_9cCnmp1Nku_3MTr5s4ZB1mBAkW_IHybRbK aPLNjthFRip1B71cn5XvWYRSGxKlH5EVzGNYEU7mNVAOhvsi7tGPOGDSqdqt iSHO_aFK0nisQEyA3T6rUNlI9p7v5VGOQ_dNOtYuSe0lC4StCK66fxVRBnsc V Received: from [121.200.231.211] by web162202.mail.bf1.yahoo.com via HTTP; Sun, 01 Jun 2014 20:37:53 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIEFuZHJld3MgPG1hcmthQGlzYy5vcmc.Cj4gVG86IFRlZCBMZW1vbiA8dGVkLmxlbW9uQG5vbWludW0uY29tPgo.IENjOiBQaGlsaXAgSG9tYnVyZyA8cGNoLXY2b3BzLTNhQHUtMS5waGljb2guY29tPjsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IE1vbmRheSwgMiBKdW5lIDIwMTQgMTE6MzggQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQSSBbVUxBIGRyYWZ0IHJldmlzaW9uICMyIFJlZ2FyZGluZyBpc28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> Message-ID: <1401680273.47439.YahooMailNeo@web162202.mail.bf1.yahoo.com> Date: Sun, 1 Jun 2014 20:37:53 -0700 (PDT) From: Mark ZZZ Smith To: Mark Andrews , Ted Lemon In-Reply-To: <20140602013829.875B917236AC@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-GY7-BODMzLwWDDRVMy1ZjM9Je8 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 03:41:06 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark Andrews =0A> To: Ted Lemon =0A> Cc: Philip Homburg ; V6 Ops List =0A> Sent: Monday, 2 = June 2014 11:38 AM=0A> Subject: Re: [v6ops] PI [ULA draft revision #2 Regar= ding isolated networks]=0A> =0A> =0A> In message , Ted Lemon =0A> writes=0A> :=0A=0A=0A=0A> = =0A> All dual stack machines are multihomed.=A0 HE is basically about fast= =0A> failover when the destination addresses are unreachable.=A0 This is no= t=0A> hard to do.=A0 From memory BSD 4.2 supported non blocking connect=0A>= which is all that is required from the IP stack to do fast failover.=0A> = =0A=0AFred wrote a very interesting draft on this, in particular including = references to multihoming support/discussion earlier than RFC1123:=0A=0A"Ha= ppier Eyeballs"=0Ahttp://tools.ietf.org/html/draft-baker-happier-eyeballs-0= 0=0A=0A"Abstract=0A=0A=A0=A0 Multihoming in modern networks has problems wi= th differing quality of=0A=A0=A0 routes.=A0 This note generalizes the conce= pt of happy eyeballs across a=0A=A0=A0 variety of multihoming scenarios."= =0A=0A=0A> Mark=0A> =0A>> _______________________________________________= =0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/m= ailman/listinfo/v6ops=0A> -- =0A> Mark Andrews, ISC=0A> 1 Seymour St., Dund= as Valley, NSW 2117, Australia=0A> PHONE: +61 2 9871 4742=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 INTERNET: marka@isc.org=0A> =0A> =0A> ____________________= ___________________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> h= ttps://www.ietf.org/mailman/listinfo/v6ops=0A> From nobody Mon Jun 2 01:10:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572201A02BA for ; Mon, 2 Jun 2014 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 hyIzEUnALdiC for ; Mon, 2 Jun 2014 01:09:58 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC271A02C5 for ; Mon, 2 Jun 2014 01:09:56 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EBA2360B39 for ; Mon, 2 Jun 2014 10:09:49 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C246460AD5 for ; Mon, 2 Jun 2014 10:09:49 +0200 (CEST) Received: (qmail 14180 invoked by uid 1007); 2 Jun 2014 10:09:49 +0200 Date: Mon, 2 Jun 2014 10:09:49 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20140602080949.GO46558@Space.Net> References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Kt2tQJjfN_sPXVEpZ9JwsjjxZAg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:10:00 -0000 Hi, On Sun, Jun 01, 2014 at 10:10:10PM -0400, Ted Lemon wrote: > On Jun 1, 2014, at 9:59 PM, joel jaeggli wrote: > > Ted I think you need rethink what you're claiming. for one rfc 6555 > > makes no claims about ipv6 address selection between multiple addresses. > > it in fact sets aside the issue of having more than the two address > > familes to chose from. I daresay if you have six v6 routes you probably > > don't want to make six requests and see which one is fastest as a > > general rule. > > How is this different than doing happy eyeballs between v4 and v6? Is it different because you're sextuply multi-homed? I agree that that begins to look a bit problematic, but the more usual two-provider case is pretty much the same as regular happy eyeballs. Actually, implementation-wise, there is a huge difference between source A ---> talk to destination X, Y source A, B ---> talk to destination Z and it's time the IETF provides some answers how to handle the second case (which HE doesn't talk about, and even ietf-mif-happy-eyeballs-extension only addresses for the specific case where A and B are not on the same interface). 6724 will not help very much in the second case - it will ensure that "one of the GUAs" is used, but due to lack of further rules, will fall through to the "most bits match" rule - which is only the "best" path for some limited cases, like "talk to other hosts direclty in the A/B /32". Worse, if you pick source A and that does not work because ISP A has an issue, no getaddrinfo() / HE implementation will fall back to try source B (supposedly MacOS does, but I haven't verified that yet), as the whole topic of source address probing / source address failover is completely underspecified yet. As in "it's complicated, leave us alone with that stuff". (But I'm sure we can do a lengthy discussion whether this could be solved with RA or DHCPv6 options) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 01:17:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753FC1A02C7 for ; Mon, 2 Jun 2014 01:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 qqlyMb4gGmm4 for ; Mon, 2 Jun 2014 01:17:50 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A0B1A01AE for ; Mon, 2 Jun 2014 01:17:50 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C85F360AD5 for ; Mon, 2 Jun 2014 10:17:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8893360126 for ; Mon, 2 Jun 2014 10:17:43 +0200 (CEST) Received: (qmail 15852 invoked by uid 1007); 2 Jun 2014 10:17:43 +0200 Date: Mon, 2 Jun 2014 10:17:43 +0200 From: Gert Doering To: joel jaeggli Message-ID: <20140602081743.GP46558@Space.Net> References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r4XptB1irwxzaV4E" Content-Disposition: inline In-Reply-To: <538BE13C.7050900@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/30Kx19nz4LzWR9vnjKzkzBTP6eI Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:17:52 -0000 --r4XptB1irwxzaV4E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jun 01, 2014 at 07:28:12PM -0700, joel jaeggli wrote: > So don't asssume that every application needs to be aware of and test > for which path is working, not only is that needless complexity pushed > up into the stack. let your routers do their job and cease routing when > their upstream connectivity is lacking. Well. It might not have been your intention, but what you said is very clear "we're not going to make multihoming in the homenet case work". In the case host --> router --> ISP A ----> ISP C --------+ +------> ISP B ----> ISP D ------> ISP E --> target where "host" has source addresses A and B, and there is a problem at=20 ISP *C*, preventing connectivity via A->C->, how exactly is the homenet router "router" supposed to *know* that, or even solve it? Assuming "as long as connectivity to ISP A is there, the whole Internet will be reachable via ISP A" is completely ignoring reality. Blackhole issues happen (where even BGP to the customer router won't help you)... OTOH, proper source address failover on "host" to source address B would very nicely solve this whole category of connectivity issues - and (by enforcing halfway symmetric return traffic via ISP B) would actually solve it *better* than BGP routing, which might need manual fiddling with the router to remove "ISP C" from the path. (IETF is complaining about lack of operator input. Here is operator input. Don't ignore it, otherwise operators get bored and find solutions outside IETF space, like, with NAT) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --r4XptB1irwxzaV4E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4wzJ99WwGXkzn/FAQIywQ/+OdBb7U1YXjS7gz+gPbBCCVQ5WiONKiJN w1dOkfO9e0Re9Ss1n6Rsud3Ad4zSIQrAaMBSAVBbwhTil1hqGnRx1i5demKM2msA /W2PT4owTHKzfjcH4nFbow9nVQDTx0pdAfFTj3bPsX3WY6bhmGbm0c5NzSCZ6PHP dQ4Lq9K2HFfy4GVD5MvkDWHRFoZZLjVQKBWeYRAGaty+e4QS/UVNFV7diXmURuGg +wg7Z92gJpwWg1iEqmWLgynMRwteEHSC6kWMi0q5qEbkGfdbkqQmoiXcQWqjZQJO 1Du9p5ryGE3GuP6cVXcOvBxfeu+IK24ULaOXQuSUSauK4HpX8jPwocmPg4Pt9kux TePNPSAquLhS2fqGEhT/in6qDDRahUHRmjdEV02HaHjD+smxEP3LDeFmLEMWg1sM nie2spDtB51bykKxeYJ9n8AEjU291ChO77ZwyYr+7e3M1FneM/sA954EosgJUp9c Qg8UNiqcHT3emI2vtFVW+fj9gIB2H5SOXCP2qqVPnDk9/RiJB3oMXoaedGQlDYP6 B9byAZtb+/oUu+sML1XIn894c7iqMxZ+ar9pGgCnucB2ei9aSq/Lp+P1EP0TJfwr rZbppMmxadJlm0g/3bAQNg/pdGjVjlaRGZ+k/squOIPuPgXQ7Yp8hktpEmF6gPQm fniVBQUgPCY= =Lonf -----END PGP SIGNATURE----- --r4XptB1irwxzaV4E-- From nobody Mon Jun 2 01:19:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B531A01AE for ; Mon, 2 Jun 2014 01:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 IalqHKwJ9MYi for ; Mon, 2 Jun 2014 01:19:00 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73841A02BA for ; Mon, 2 Jun 2014 01:18:59 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8E6F3602C8 for ; Mon, 2 Jun 2014 10:18:53 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 572B760126 for ; Mon, 2 Jun 2014 10:18:53 +0200 (CEST) Received: (qmail 15933 invoked by uid 1007); 2 Jun 2014 10:18:53 +0200 Date: Mon, 2 Jun 2014 10:18:53 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20140602081853.GQ46558@Space.Net> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602025833.A659C1723F0A@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602025833.A659C1723F0A@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YuzXdos0gCuL9ed7mvTA8PZwjQs Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:19:00 -0000 Hi, On Mon, Jun 02, 2014 at 12:58:33PM +1000, Mark Andrews wrote: > There is also nothing to prevent a stack trying multiple source > addresses when it hasn't been explicitly bound to a source address > by the application. Well, yes, nothing *prevents* this. But given lack of IETF guidance on this, stack implementors do not seem to be keenly interested in actually implementing this. (Does BIND do this...?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 01:30:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F511A0105 for ; Mon, 2 Jun 2014 01:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 lUyyRr77b-Em for ; Mon, 2 Jun 2014 01:30:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C541A008B for ; Mon, 2 Jun 2014 01:30:52 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AEEA760AED for ; Mon, 2 Jun 2014 10:30:46 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 61C5B60129 for ; Mon, 2 Jun 2014 10:30:46 +0200 (CEST) Received: (qmail 20689 invoked by uid 1007); 2 Jun 2014 10:30:46 +0200 Date: Mon, 2 Jun 2014 10:30:46 +0200 From: Gert Doering To: Mark ZZZ Smith Message-ID: <20140602083046.GR46558@Space.Net> References: <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <1401680273.47439.YahooMailNeo@web162202.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401680273.47439.YahooMailNeo@web162202.mail.bf1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/et2M-A1rlaIrhNLREuBULkBAv5k Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:30:55 -0000 Hi, On Sun, Jun 01, 2014 at 08:37:53PM -0700, Mark ZZZ Smith wrote: > "Happier Eyeballs" > http://tools.ietf.org/html/draft-baker-happier-eyeballs-00 Thanks. I forgot about that one, and only found the mif draft, which focuses on "multiple interfaces". *This* draft is actually a very nice starting point, listing the issues and providing some thoughts how to tackle them. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 02:50:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4EF1A02FC for ; Mon, 2 Jun 2014 02:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 WLemhglwNy62 for ; Mon, 2 Jun 2014 02:49:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A132A1A02F1 for ; Mon, 2 Jun 2014 02:49:57 -0700 (PDT) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 2 Jun 2014 09:49:50 +0000 Message-ID: <032301cf7e47$98aebd00$4001a8c0@gateway.2wire.net> From: t.petch To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> <053501cf7c28$c53d51e0$4001a8c0@gateway.2wire.net> <99F0392C-6E88-42E7-850B-5027841B98DD@delong.com> Date: Mon, 2 Jun 2014 10:11:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA0030.eurprd07.prod.outlook.com (10.141.45.158) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0230B09AC4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(377454003)(13464003)(92726001)(77156001)(19580395003)(83322001)(77982001)(86362001)(62236002)(42186004)(101416001)(88136002)(19580405001)(87976001)(33646001)(47776003)(80022001)(102836001)(79102001)(81686999)(44716002)(20776003)(85852003)(89996001)(83072002)(64706001)(76176999)(50986999)(66066001)(81816999)(76482001)(50226001)(84392001)(93916002)(46102001)(23746002)(74662001)(62966002)(61296002)(21056001)(14496001)(81342001)(104166001)(87286001)(99396002)(74502001)(4396001)(50466002)(81542001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB055; H:AMXPRD0310HT003.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bmPh2PtQVoOPA98SPH094M5gKT8 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 09:50:07 -0000 ----- Original Message ----- From: "Owen DeLong" To: "t.petch" Cc: "Tore Anderson" ; "Brian E Carpenter" ; "V6 Ops List" Sent: Friday, May 30, 2014 6:18 PM > >> Yes, we need to change the fundamental way we deal with routing and come >> up >> with a more scalable solution than the current everyone knows every >> prefix >> model. >> > > Owen, > > yes, and that is what the RRG did. It came up with two solutions and, > being an IRTF and not an IETF WG, one solution was declared appropriate > while the other (LISP) is being developed by the IETF:-) Not sure why your mailer can’t do quoting correctly, but I’ve fixed it here for you. Sorry about that, my mailer doesn't cope with quoted-printable so if we could if we could just eliminate all those funny European characters and live with USASCII - sigh, perhaps not Meanwhile ... > > The key to both is that while the number of prefixes is likely to grow > beyond the capacity of routers, the number of locations involved is > likely to remain much smaller so that routing will be based on > locations, with a mapping from prefix to location prior to routing. LISP is way over-complicated for the problem space in question, though it’s probably the right general idea. In reality, what is needed is a simpler solution probably related to doing the IDR portion of routing on destination ASN. Unfortunately, we don’t have a good way in the current protocol to encode the destination ASN onto the packet. My thinking is that a revised 44 octet header would do the trick and that during the transition process, having routers that border between 44-octet header capable zones and non-44-octet header capable zones would perform the header replacement. Unfortunately, this has PMTU-D issues which I haven’t figured out how to address yet. ... I commend RFC 6115 to you, although the I-Ds that led up to it are perhaps better. And there is the RRG list archive (which makes v6ops look like a low volume list:-). A lot of options were explored, ILNP got the WG chair's recommendation, LISP became an IETF WG; I liked SEAL (and am always glad to read what Fred has to say) and I think that Ivip never got the attention it deserved. Between the IAB report in 2006 and the RFC in 2011, a lot of work went into this area, with results as above. Multi-homing, PI v. PA, PMTUD, tunnels, NAT, IPv6 rate of migration, DFZ churn, the impact of 2B cell phones on IPv6, network API, ... all of life is there and I suspect that revisting the topic will bring little new (pace a revision of the predicted chip capacity and hence a longer life for BGP4)) Tom Petch Owen > > All in the RRG archives. > > Tom Petch > > However, at any likely growth rate, if we actually start working on the > problem > instead of simply inflicting limitations and calling it handled, then we > have > time to address the issue in IPv6. Hopefully the RRG will wake up and > start > addressing this issue. For now, it is out of scope for v6ops as I > understand > the WG charter. > >> And I think that every SME who has lost business with the > unreliability >> of their ISP will want multi-homing and will think that with IPv6 and > PI >> the constraints have gone, and the number of such SMEs can only > approach >> 10M over time. > > All the more reason this issue needs to get addressed instead of > ignored. > >> So, Brian is spot on, and just as the IETF did little about IPv4 >> addresses running out until the event loomed large, so I expect > history >> to repeat itself with the growth of PI in IPv6. > > He’s somewhat right about the problem. He’s absolutely wrong in > believing that > the current limitations are a solution. > > Owen > From nobody Mon Jun 2 04:51:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220881A0305 for ; Mon, 2 Jun 2014 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 43gnUWMZm0pY for ; Mon, 2 Jun 2014 04:50:59 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076721A01C7 for ; Mon, 2 Jun 2014 04:50:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EC6B71B8213 for ; Mon, 2 Jun 2014 04:50:53 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CF6B619005C; Mon, 2 Jun 2014 04:50:53 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 04:50:53 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <20140602080949.GO46558@Space.Net> Date: Mon, 2 Jun 2014 07:50:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7B79C377-CCCF-4B52-9C46-150CAEB447C7@nominum.com> References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <20140602080949.GO46558@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Lja6rUwHhe0gzCgYrA_91I0SZLA Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 11:51:00 -0000 On Jun 2, 2014, at 4:09 AM, Gert Doering wrote: > source A ---> talk to destination X, Y > source A, B ---> talk to destination Z Thank you for explaining that--I was talking about case 2, but I didn't = make it explicit, and I think people thought I was talking about case 1. The MIF happy eyeballs document will probably be updated according to = the MPVD architecture document when that's done (hopefully soon).= From nobody Mon Jun 2 05:45:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9521A0245 for ; Mon, 2 Jun 2014 05:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 V9XIS1q0LG4L for ; Mon, 2 Jun 2014 05:45:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BF31A023B for ; Mon, 2 Jun 2014 05:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1401713122; x=1402922722; h=date:from:message-id:to:subject:cc; bh=Y2WHWsMeT25LUHaPo358l0c08N094iw4lR4VyNC5gDU=; b=CYIKCNLjqPB2gHG1uC+Bk/XRcXtEWH8rzWQrrExlbknuVwpYKbMGdGXQ oi+WWPT5gvtpCflcnxnxDprboFwtDcy7FCVjmom/CsXTdGylAO9JghUvy OmdzuU2xm15yoVPs8VSuHgtOp/1a++wBQWxkhfHEYm5jbQC7cW/wwDpwv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAQAK5wjFOtJV2P/2dsb2JhbABZgwdSrXUBlSwDBAKBERZ0gyU8NIkiAQ3UVBeOUh2EKgSKJZEZkW+DWA X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="329805156" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jun 2014 12:45:21 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s52CjKqY022228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 12:45:21 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s52CjI3U000421; Mon, 2 Jun 2014 05:45:19 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s52CjH9t000368; Mon, 2 Jun 2014 05:45:17 -0700 (PDT) Date: Mon, 2 Jun 2014 05:45:17 -0700 (PDT) From: Fred Baker Message-Id: <201406021245.s52CjH9t000368@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V_M2HfEjJc_Df8J0Kon2ga4D_dE Cc: draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-jaeggli-v6ops-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:45:28 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-jaeggli-v6ops-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Mon Jun 2 06:35:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86751A0331 for ; Mon, 2 Jun 2014 06:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 dn1kUvK21iLd for ; Mon, 2 Jun 2014 06:35:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA31A0325 for ; Mon, 2 Jun 2014 06:35:18 -0700 (PDT) Received: from [10.53.146.217] ([88.128.80.30]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s52DT8a8026155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 06:29:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s52DT8a8026155 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401715751; bh=wFI9Bji3twDmunt7CeGwJcOnru0=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=z88aN5gyA4gxAtTwwMwW79PRG83ZZOIw7v2IQbRgTMKTjZlk07k+5/ny5WaYhnlhx V8Ku6KAU5FFHVtv1+6vUtLBMUo93P4SO0oQOqnaTnYL2Zt0fuROL2PcNORdC/OWy0E crGRBohHY6LmJjg1zr4p38yQNfLJXUT57I8DNPQc= References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5C274637-D63B-491E-8426-AEFDD106FB96@delong.com> X-Mailer: iPad Mail (11D201) From: Owen DeLong Date: Mon, 2 Jun 2014 14:29:07 +0100 To: Ted Lemon X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 02 Jun 2014 06:29:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/698uOIDHGW13mUrCNiQgCNzBUxo Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 13:35:21 -0000 > On Jun 2, 2014, at 2:19 AM, Ted Lemon wrote: >=20 >> On Jun 1, 2014, at 9:12 PM, Lorenzo Colitti wrote: >> There is no such claim. The only difference between IPv4 and IPv6 with re= gard to multihoming is that IPv6 supports more than one IPv6 address on the s= ame interface, whereas some IPv4 implementations don't. >=20 > I would like multihoming to work, and I'd like it to work without NAT. I= f you would like something else, that's okay. But my impression is that I a= m not alone in thinking this is a key benefit of IPv6 over IPv4, even if it'= s still not fully baked (RFC 7157 notwithstanding). Multihoming works just fine without NAT as is. I run a network at home which= is multihomed in both IPv4 and IPv6 without NAT. Multihoming is not what is actually being discussed here. As Lorenzo pointed= out this discussion seems to be limited to the (pathological) case of multi= homing which involves a separate selection of source address for each upstre= am which is, for the most part, unique to IPv6 and does, indeed, pose additi= onal challenges not present in traditional multihoming. Owen From nobody Mon Jun 2 07:33:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042F51A0336 for ; Mon, 2 Jun 2014 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 u-E2n3XSXI4S for ; Mon, 2 Jun 2014 07:33:28 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB88E1A033D for ; Mon, 2 Jun 2014 07:33:28 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7F47360B34 for ; Mon, 2 Jun 2014 16:33:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 520386038F for ; Mon, 2 Jun 2014 16:33:21 +0200 (CEST) Received: (qmail 97517 invoked by uid 1007); 2 Jun 2014 16:33:21 +0200 Date: Mon, 2 Jun 2014 16:33:21 +0200 From: Gert Doering To: Owen DeLong Message-ID: <20140602143321.GZ46558@Space.Net> References: <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <5C274637-D63B-491E-8426-AEFDD106FB96@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C274637-D63B-491E-8426-AEFDD106FB96@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2ICX_lQGZotbnNJR_xkGUw3t4Nk Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:33:31 -0000 Hi, On Mon, Jun 02, 2014 at 02:29:07PM +0100, Owen DeLong wrote: > Multihoming works just fine without NAT as is. I run a network at home which is multihomed in both IPv4 and IPv6 without NAT. > > Multihoming is not what is actually being discussed here. As Lorenzo pointed out this discussion seems to be limited to the (pathological) case of multihoming which involves a separate selection of source address for each upstream which is, for the most part, unique to IPv6 and does, indeed, pose additional challenges not present in traditional multihoming. It would be really helpful if you could label your soapbox properly, and if you talk about "BGP based multihoming with PI addresses", then please *label* it as such. The term "multihoming" does not imply more than "multihoming", in particular, it does not require a specific technology or addressing policy to be used. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 08:08:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0D21A021F for ; Mon, 2 Jun 2014 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 5EQEPmPvHuK7 for ; Mon, 2 Jun 2014 08:08:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3492E1A0141 for ; Mon, 2 Jun 2014 08:08:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 835273493A0; Mon, 2 Jun 2014 15:08:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B19A160067; Mon, 2 Jun 2014 15:13:40 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 257B6160057; Mon, 2 Jun 2014 15:13:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 179BC1734B4E; Tue, 3 Jun 2014 01:08:03 +1000 (EST) To: Gert Doering From: Mark Andrews References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602025833.A659C1723F0A@rock.dv.isc.org> <20140602081853.GQ46558@Space.Net> In-reply-to: Your message of "Mon, 02 Jun 2014 10:18:53 +0200." <20140602081853.GQ46558@Space.Net> Date: Tue, 03 Jun 2014 01:08:03 +1000 Message-Id: <20140602150803.179BC1734B4E@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HigpXShuHn-j6QS5JDMsIJ1wDrU Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:08:43 -0000 In message <20140602081853.GQ46558@Space.Net>, Gert Doering writes: > Hi, > > On Mon, Jun 02, 2014 at 12:58:33PM +1000, Mark Andrews wrote: > > There is also nothing to prevent a stack trying multiple source > > addresses when it hasn't been explicitly bound to a source address > > by the application. > > Well, yes, nothing *prevents* this. But given lack of IETF guidance on > this, stack implementors do not seem to be keenly interested in actually > implementing this. > > (Does BIND do this...?) We don't automatically try multiple source addresses per family but you can specify different sources addresses for different destination addresses. At this point multiple PA prefixes are not common yet. ULA + PA (or PI) just works at the moment. That said I would most probable implement it something like , , , , , assume S1 and S2 are from different PA prefixes. On top of detecting network failures nameservers also have to deal with broken nameservers / firewalls that drop queries because they don't like something in the query despite it being perfectly in spec. Then there is RRL processing which drops queries if the server sees excesive traffic as part of amplication mitigation. > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 2 08:14:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3CF1A0362 for ; Mon, 2 Jun 2014 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 1lo_DQ3qPwtb for ; Mon, 2 Jun 2014 08:14:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E461A0141 for ; Mon, 2 Jun 2014 08:14:22 -0700 (PDT) Received: from mbp.local ([172.56.41.86]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s52FDOY9090835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 15:13:27 GMT (envelope-from joelja@bogus.com) Message-ID: <538C93E9.7080405@bogus.com> Date: Mon, 02 Jun 2014 08:10:33 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Gert Doering References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> In-Reply-To: <20140602081743.GP46558@Space.Net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6a42B977ADTBKBhMAn6FPrXE6JTncCaJg" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 02 Jun 2014 15:14:17 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BAJmcxEDGLTe68Y7c7wQcGT4xRg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:14:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6a42B977ADTBKBhMAn6FPrXE6JTncCaJg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/2/14, 1:17 AM, Gert Doering wrote: > Hi, >=20 > On Sun, Jun 01, 2014 at 07:28:12PM -0700, joel jaeggli wrote: >> So don't asssume that every application needs to be aware of and test >> for which path is working, not only is that needless complexity pushed= >> up into the stack. let your routers do their job and cease routing whe= n >> their upstream connectivity is lacking. >=20 > Well. It might not have been your intention, but what you said is very= > clear "we're not going to make multihoming in the homenet case work". No sorry I did not. What I said is that I believe you're pushing an expectation of a certain amount of complexity onto hosts in the interests of measurement and detection of topological corner cases. some hosts might choose to do that in the interest of improved connectivity, the expectation that they all should is onerous, you be should have an expection that devices and applications will work in the absence of HE. having a router invalidate itself as a nexthop because it has detected that it's paritioned from a provider or the internet seems like an incredibly basic concession that you'd want to have happen even were everything HE enabled. > In the case >=20 > host --> router --> ISP A ----> ISP C --------+ > +------> ISP B ----> ISP D ------> ISP E --> target >=20 > where "host" has source addresses A and B, and there is a problem at=20 > ISP *C*, preventing connectivity via A->C->, how exactly is the homenet= > router "router" supposed to *know* that, or even solve it? It doesn't. > Assuming "as long as connectivity to ISP A is there, the whole Internet= > will be reachable via ISP A" is completely ignoring reality. Blackhole= > issues happen (where even BGP to the customer router won't help you)...= yes, bgp multihoming doesn't solve it either. that has not rendered it unsuitable for use. >=20 > OTOH, proper source address failover on "host" to source address B woul= d > very nicely solve this whole category of connectivity issues - and (by > enforcing halfway symmetric return traffic via ISP B) would actually so= lve > it *better* than BGP routing, which might need manual fiddling with the= > router to remove "ISP C" from the path. >=20 > (IETF is complaining about lack of operator input. Here is operator in= put. > Don't ignore it, otherwise operators get bored and find solutions outsi= de > IETF space, like, with NAT) >=20 > Gert Doering > -- NetMaster >=20 --6a42B977ADTBKBhMAn6FPrXE6JTncCaJg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOMk+oACgkQ8AA1q7Z/VrJNoQCbBEa2eaUQvAtXy9FJVaRtvA/h yhYAn1bEIo7RZ9YKTnFhIOsxlvt0DLV6 =B/4S -----END PGP SIGNATURE----- --6a42B977ADTBKBhMAn6FPrXE6JTncCaJg-- From nobody Mon Jun 2 08:26:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363601A0380 for ; Mon, 2 Jun 2014 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 2RH9FJNiTxIQ for ; Mon, 2 Jun 2014 08:26:49 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213731A0382 for ; Mon, 2 Jun 2014 08:26:48 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 479AE60B3F for ; Mon, 2 Jun 2014 17:26:42 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2252160B34 for ; Mon, 2 Jun 2014 17:26:42 +0200 (CEST) Received: (qmail 6952 invoked by uid 1007); 2 Jun 2014 17:26:42 +0200 Date: Mon, 2 Jun 2014 17:26:42 +0200 From: Gert Doering To: joel jaeggli Message-ID: <20140602152642.GB46558@Space.Net> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538C93E9.7080405@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+X7K3ZbSRJxCtaUy" Content-Disposition: inline In-Reply-To: <538C93E9.7080405@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mcVo6tudjXGVcWm_Kv4RgQVXdOA Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:26:52 -0000 --+X7K3ZbSRJxCtaUy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jun 02, 2014 at 08:10:33AM -0700, joel jaeggli wrote: > > Well. It might not have been your intention, but what you said is very > > clear "we're not going to make multihoming in the homenet case work". >=20 > No sorry I did not. What I said is that I believe you're pushing an > expectation of a certain amount of complexity onto hosts in the > interests of measurement and detection of topological corner cases. some > hosts might choose to do that in the interest of improved connectivity, > the expectation that they all should is onerous, you be should have an > expection that devices and applications will work in the absence of HE. >=20 > having a router invalidate itself as a nexthop because it has detected > that it's paritioned from a provider or the internet seems like an > incredibly basic concession that you'd want to have happen even were > everything HE enabled. You seem to be using a different Internet than I do, which seem to consist of "the only way things can break is if my CPE loses contact to it's ISP, which is always easily detectable, but as soon as the packet reaches the ISP, it will be 100 percent reliably transported and answered, all the time". My Internet, unfortunately, seems to have less boolean cases where packets just disappear when being sent into certain directions, without even adjacent devices noticing, much less "devices 10 hops away". > > In the case > >=20 > > host --> router --> ISP A ----> ISP C --------+ > > +------> ISP B ----> ISP D ------> ISP E --> target > >=20 > > where "host" has source addresses A and B, and there is a problem at=20 > > ISP *C*, preventing connectivity via A->C->, how exactly is the homenet > > router "router" supposed to *know* that, or even solve it? >=20 > It doesn't. Thanks for acknowledging that. > > Assuming "as long as connectivity to ISP A is there, the whole Internet > > will be reachable via ISP A" is completely ignoring reality. Blackhole > > issues happen (where even BGP to the customer router won't help you)... >=20 > yes, bgp multihoming doesn't solve it either. that has not rendered it > unsuitable for use. BGP multihoming has it's uses, but I think all but Owen agree that it's not going to solve the "billions of leaf networks without IT knowledge" case. Multi-Address multihoming has the potential to be a radical improvement for "leaf networks without IT knowledge". =20 Especially for cases that BGP based multihoming will not handle well today,= =20 like "black hole problems due to people's MPLS stuff running amock",=20 "stateful firewalls in the packet path that do not handle asymmetric=20 traffic well", "selection of the ISP used by the user, not by the CPE=20 router", etc. It's certainly not a replacement for BGP based multihoming for "networks with lots of servers and qualified IT staff". Just to avoid that particular avenue of ratholing. > > (IETF is complaining about lack of operator input. Here is operator in= put. > > Don't ignore it, otherwise operators get bored and find solutions outsi= de > > IETF space, like, with NAT) Maybe I should include this in of my signature when writing to IETF lists... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --+X7K3ZbSRJxCtaUy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4yXsd9WwGXkzn/FAQLU1A/+IqTKjyUJDqR4qA2quzqwwHKhfQJT7xJe WlGXYa3vxO9FHbqEF61o3GOh5IApEiAtUHqRlvs1kwhPnrQNdzA5URgbCev1c0z1 gD9MqlSEFs6pkZQI9B8FwyrYYXkNfkWEgyqzljVvFtTARg/kirflkHx0F5LlhNqk pY2lWLz4qcyRSaPgZZA2FPG7nZwUdhzQ1Fa8pSbnAyUhyKCIKu5UJ559/L9CxLqz LXnom3O9/ru8n3bxTd//+bxpCzkEIi5kh5iWO25zQB+EzVJidYkGar/5OYf4Sub9 sZkbzEBed8S1XLvgEfBArZgJPRQh5wf4zpl+zcNoM3LDFQVYFGz8JSSN2ySq3+PG f5wSbAirRTjGgjN8dFKtL/K1+5r9aXmBTKApqkNVQZLTXN4C0TPDxzn8uFmc7iUy XtRJe1U5OsZaPDxya+uD/DslIcglZTYykHvwX6Utq+vSePpUGV1Yl01I6lv2aGLQ NKPZJjwGIQ6Xa/14ajjCJSkeoxPPybyZFk1+WrEZYF00Bi0ZrchRWpKrEoen2nt3 4meRePPiaW36iBNep8Q3dzctG904sxXOu0Fhy+i2mKBgGxMbGaLJce4louZed9Mu lompadI8W+S1Um///6VjL5jUAynJCR5MOnAr+AqysDuCnyJVsCs4fs/F4uqASi4X jOZLZJAizCE= =KZqL -----END PGP SIGNATURE----- --+X7K3ZbSRJxCtaUy-- From nobody Mon Jun 2 09:12:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03D31A0265 for ; Mon, 2 Jun 2014 09:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 OTkXYrR3pjjy for ; Mon, 2 Jun 2014 09:12:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69511A0350 for ; Mon, 2 Jun 2014 09:12:26 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s52GCJn7093078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 16:12:20 GMT (envelope-from joelja@bogus.com) Message-ID: <538CA255.7070205@bogus.com> Date: Mon, 02 Jun 2014 09:12:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Gert Doering References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538C93E9.7080405@bogus.com> <20140602152642.GB46558@Space.Net> In-Reply-To: <20140602152642.GB46558@Space.Net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrLPAwVapurT22uSgKD2qLunWMHsVATT9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 02 Jun 2014 16:12:21 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iazhbkuTw4J40BCTv7kE19CrvHg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:12:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nrLPAwVapurT22uSgKD2qLunWMHsVATT9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/2/14, 8:26 AM, Gert Doering wrote: >> yes, bgp multihoming doesn't solve it either. that has not rendered it= >> unsuitable for use. >=20 > BGP multihoming has it's uses, but I think all but Owen agree that it's= > not going to solve the "billions of leaf networks without IT knowledge"= > case. Right, nor are we suggesting it is. Lets say it, the attachment costs, borne individually and collectively make it entirely unsuitable for this.= > Multi-Address multihoming has the potential to be a radical improvement= > for "leaf networks without IT knowledge". =20 You and I agree on this. Where I disagree is that the devices attached to network should be assumed to bear the cost of fine grained decision making. We should not assume that they all should, and multihomed homenets should function reasonably well even if they do not. --nrLPAwVapurT22uSgKD2qLunWMHsVATT9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOMolUACgkQ8AA1q7Z/VrJ9SACfYJ46RfqH3lTtYhJ/ReCELNsA vMgAoIxHl/Mk9YZjH9CFO+Olbm4OUKcL =QQEO -----END PGP SIGNATURE----- --nrLPAwVapurT22uSgKD2qLunWMHsVATT9-- From nobody Mon Jun 2 09:28:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2301A039B for ; Mon, 2 Jun 2014 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 KANMMwGcvwlm for ; Mon, 2 Jun 2014 09:28:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id EF8631A037C for ; Mon, 2 Jun 2014 09:28:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WrV6L-0000BcC; Mon, 2 Jun 2014 18:28:45 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140601231140.303E9171FD22@rock.dv.isc.org> In-reply-to: Your message of "Mon, 02 Jun 2014 09:11:40 +1000 ." <20140601231140.303E9171FD22@rock.dv.isc.org> Date: Mon, 02 Jun 2014 18:28:45 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XktbPhnrifrYNBNqjPpfxZmadeE Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:28:54 -0000 In your letter dated Mon, 02 Jun 2014 09:11:40 +1000 you wrote: >Every piece of client software should already support multi-homing. >This is about supporting it *better* so there isn't the big delay >when switching to the second address because the link at the other >end is down. The stack should be choosing source addresses which >have working outbound paths. Selecting destination addresses is >up to the application. > >This is about making the error cases work better which quite frankly >should have been done years ago for IPv4. The only ones that don't >benefit from this is GLB developers. I'd like to see IPv6 deployed sooner rather than later. And in my experience, everywhere where IPv6 is different from IPv4 it causes problems and extra delays. So if you say 'every piece of client software should already support multi-homing' then that is simply not true in the IPv4 world. At least while giving reasonable performance. If all IPv4 software supported multi-homing properly, then there was no need for happy eyeballs. And many of the features that discussed in the context of happy eyeballs were not implemented in a large scale before. As a result, there also no standard API for doing HE. The Berkeley socket interface is still the same because in practice, eveybody is not doing multi-homed. Doing HE with minimal overhead is very tricky. It is very easy for most client systems to take a full matrix of source and destination addresses and connect to all of them. I'm quite sure that most operators of server systems would completely hate that approach. Simply put, the more things we come up with that have to be done before someone can deplay IPv6, the longer it will take. From nobody Mon Jun 2 09:37:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC981A0260 for ; Mon, 2 Jun 2014 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 O7L4FCIMqi7C for ; Mon, 2 Jun 2014 09:37:08 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECA51A025D for ; Mon, 2 Jun 2014 09:37:08 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D71631B8208 for ; Mon, 2 Jun 2014 09:37:02 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8F64219005C; Mon, 2 Jun 2014 09:37:02 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 09:37:02 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> Date: Mon, 2 Jun 2014 12:37:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i58NKDsswD1SHa3-nlosRyWbXhQ Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:37:10 -0000 On Jun 1, 2014, at 4:38 PM, Ted Lemon wrote: > On Jun 1, 2014, at 2:02 PM, joel jaeggli wrote: >> Assumption of the Existence of HE is a pretty dodgy proposition. > Then we can't do multihoming without NAT. This rather badly qualified comment appears to have generated a lot of = discussion, so to head off further discussion I'd like to clarify a few = points. First, if you are multihomed, and both paths are working, then a host = that does nothing special will work. Second, if one connection goes = out, and the routing updates, then an application that just retries when = it doesn't get a connection will get a connection; for applications for = which delays on the order of the time it takes for routing to update are = harmless, redundant multihoming will work with no changes. So the statement I made was false when interpreted in this context. I = know that it's false, and you don't need to keep arguing with me to = convince me it's false. I'm sorry for having been sufficiently = unspecific that people thought I meant my statement was true for the = above cases. The cases I care about are in fact edge cases. They don't happen all = the time, and depending on the application they may or may not be = important. I care about them because I've been affected by failures, = and I'd like to be able to say how to get these cases right without = resorting to the use of NAT or NPT. I'd like for there to be better = tools for application developers to use so that they can address these = edge cases relatively cheaply; possibly even more cheaply than they now = do network programming that doesn't address these edge cases. If you = don't care about these edge cases, you will have little concern for = this, and will not consider dealing with these edge cases important. I, and no doubt most participants on this mailing list, am deeply = uninterested in hearing "it works okay for me, so your edge cases don't = matter" I am also not interested in trying to get you to say "I care = deeply about these edge cases." It's okay with me if you don't care = about them, and don't consider it important that they be addressed. = You don't need to respond to this message with yet another assertion = that there is no problem here--it won't convince me, and what I want to = do about this probably won't affect your application anyway. If you are interested in thinking about this problem, the place to = discuss it is probably the MIF working group--it's related to the work = that's being done there, although it's not the entirety of that work. = If you are not interested, please let's just let this drop. I'm sorry = for the troll--I didn't intend it to be a troll, but I could have = phrased it in a way that was less trollish. I will try to do better = next time. From nobody Mon Jun 2 09:41:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721E51A03A2 for ; Mon, 2 Jun 2014 09:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 C-GBipTN_akY for ; Mon, 2 Jun 2014 09:41:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841F91A03AF for ; Mon, 2 Jun 2014 09:41:52 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DB9B7603FB for ; Mon, 2 Jun 2014 18:41:45 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A7610602E6 for ; Mon, 2 Jun 2014 18:41:45 +0200 (CEST) Received: (qmail 18076 invoked by uid 1007); 2 Jun 2014 18:41:45 +0200 Date: Mon, 2 Jun 2014 18:41:45 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140602164145.GC46558@Space.Net> References: <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140601231140.303E9171FD22@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KOqCFJ5TK2mOBzr6qoFXwrOKsxs Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:41:53 -0000 Hi, On Mon, Jun 02, 2014 at 06:28:45PM +0200, Philip Homburg wrote: > Simply put, the more things we come up with that have to be done before someone > can deplay IPv6, the longer it will take. Strictly speaking, the bits of this discussion that turn around leaf-site multihoming are not relevant to "being able to deply IPv6". They are relevant to "build a solution for millions of barber-shop style SMEs and pure home networks that like to have two ISPs because internet is important", but this is not something happening *now* but "in the next few years". What we have now works about as well as IPv4 - but we can make it better. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 09:49:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573FD1A03AF for ; Mon, 2 Jun 2014 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 ZtupGGRUgubK for ; Mon, 2 Jun 2014 09:49:25 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CC16C1A0360 for ; Mon, 2 Jun 2014 09:49:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WrVQF-0000BcC; Mon, 2 Jun 2014 18:49:19 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> In-reply-to: Your message of "Mon, 2 Jun 2014 10:17:43 +0200 ." <20140602081743.GP46558@Space.Net> Date: Mon, 02 Jun 2014 18:49:13 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YGbY63ylOfUmt2szjO-RidqeUjo Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:49:26 -0000 In your letter dated Mon, 2 Jun 2014 10:17:43 +0200 you wrote: >On Sun, Jun 01, 2014 at 07:28:12PM -0700, joel jaeggli wrote: >> So don't asssume that every application needs to be aware of and test >> for which path is working, not only is that needless complexity pushed >> up into the stack. let your routers do their job and cease routing when >> their upstream connectivity is lacking. > >Well. It might not have been your intention, but what you said is very >clear "we're not going to make multihoming in the homenet case work". > >In the case > > host --> router --> ISP A ----> ISP C --------+ > +------> ISP B ----> ISP D ------> ISP E --> target > >where "host" has source addresses A and B, and there is a problem at=20 >ISP *C*, preventing connectivity via A->C->, how exactly is the homenet >router "router" supposed to *know* that, or even solve it? > >OTOH, proper source address failover on "host" to source address B would >very nicely solve this whole category of connectivity issues - and (by >enforcing halfway symmetric return traffic via ISP B) would actually solve >it *better* than BGP routing, which might need manual fiddling with the >router to remove "ISP C" from the path. One philosophical question is whether it is the host or network that is responsible for dealing with such brokenness? The nice thing about the IPv4 architecture is the split between the network and the transport layer on the hosts: the network transports packets from source to destination, occasionally dropping packets, reordering them and in extreme cases duplicating them. The host transport layer retransmits and reorders packets and filters out duplicates. Host do not know about the network, they just pass packets to the default router (or other routers in case of ICMP redirects). Making the host resposible for good source address selection in case network failures violates that model. If we make the router responsible dealing with failures, then it helps to separate mechanism from policy. I think it would already help enormously if routers could inform hosts in a standard way what prefixes do and do not work. One option is to play tricks with the preference lifetime RAs. But how does that work in the context of DHCPv6? How do we update DNS? For policy, even if you would have to tell a router manually that link is broken, it would help already enormously if entire site would then reconfigure automatically. Detecting a broken uplink can be added easily and is a very common cause of failure. Beyond that, many different types of pluggable detectors are possible. If for me, say, github is important, then having a module that can poll a website regularly would do the trick. Beyond that having an SNMP interface would allow a separate measurement device to inform routers about what has failed. From nobody Mon Jun 2 09:52:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113381A0360 for ; Mon, 2 Jun 2014 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 F_jhlaOYCDvM for ; Mon, 2 Jun 2014 09:52:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2CE1A0350 for ; Mon, 2 Jun 2014 09:52:24 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0EE6D1B81C7 for ; Mon, 2 Jun 2014 09:52:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 07D9519005C; Mon, 2 Jun 2014 09:52:19 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 09:52:18 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 2 Jun 2014 12:52:17 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c3a4G0r-NFErB8No6RRmiO2cu90 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:52:25 -0000 On Jun 2, 2014, at 12:49 PM, Philip Homburg = wrote: > One philosophical question is whether it is the host or network that = is > responsible for dealing with such brokenness? It doesn't have to be one or the other. The network can take care of = what it can take care of, and that's important. But the host can do = things the network can't. Thinking of this as a big philosophical = question that we have to settle once and for all is a recipe for endless = debate. From nobody Mon Jun 2 09:57:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5B31A025A for ; Mon, 2 Jun 2014 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 lNobUffRdv3j for ; Mon, 2 Jun 2014 09:57:39 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28161A023A for ; Mon, 2 Jun 2014 09:57:38 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9D83060B3F for ; Mon, 2 Jun 2014 18:57:31 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5D2A46038F for ; Mon, 2 Jun 2014 18:57:31 +0200 (CEST) Received: (qmail 20342 invoked by uid 1007); 2 Jun 2014 18:57:31 +0200 Date: Mon, 2 Jun 2014 18:57:31 +0200 From: Gert Doering To: joel jaeggli Message-ID: <20140602165731.GE46558@Space.Net> References: <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538C93E9.7080405@bogus.com> <20140602152642.GB46558@Space.Net> <538CA255.7070205@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wbuTI+YEd0REWzbC" Content-Disposition: inline In-Reply-To: <538CA255.7070205@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4pHjFpOTPVYd7BE1XCK3HBIIFY0 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:57:40 -0000 --wbuTI+YEd0REWzbC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jun 02, 2014 at 09:12:05AM -0700, joel jaeggli wrote: > On 6/2/14, 8:26 AM, Gert Doering wrote: >=20 > > Multi-Address multihoming has the potential to be a radical improvement > > for "leaf networks without IT knowledge". =20 >=20 > You and I agree on this. This is good :-) > Where I disagree is that the devices attached to network should be > assumed to bear the cost of fine grained decision making. We should not > assume that they all should, and multihomed homenets should function > reasonably well even if they do not. OK, I do also agree (as this is a "should be assumed"). There's multiple aspects to it. - if the network devices do not care, and just follow 6724 rules, and the CPEs will handle "basic" failures right (detect ISP down, assign prefix with preferred lifetime =3D 0), they will generally just work, but the source address =3D ISP selection will not generally be optimal (whatever that means in the specific case - latency, throughput,=20 price?), and certain failure cases might involve user action ("plug the pull to ISP A"). - if the network devices *do* care, and we get a bit more work done, the user experience can be improved =20 - give the user (!) control over ISP selection, like in "I want my bittorrent to use my cable ISP, and my web surfing to use the DSL line" - I think this is a major benefit compared to solutions with a single prefix and a CPE-controlled policy, because for the normal end user, the CPE is a magic box that is not touched or configured (Owen is not a normal end user). - handle black-holing failure cases that only affect the packet path for one of the available prefixes, but for the one that might be selected by 6724 to point out what is obvious to me, but might not be for someone reading this: - this is NOT about "managed environments". In an "enterprise" network that has IT staff and policies set by "management" regarding ISP usage, the enterprise admins will NOT want the end systems to control policy - so there, "single prefix, CPE controls policy" is a more adequate=20 solution. Which might imply NATs, or proxies, etc. - enterprisey stuff, according to that specific network's needs. - and that implies that there is not "one" solution for multihomed leaf si= tes thanks :) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --wbuTI+YEd0REWzbC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4ys+99WwGXkzn/FAQKzPw//fEA86VkvYnrebgUxYpQluC6zhep3I9o+ +iv3M23Syr4ZFWTxpbWitSkZxgtDfHYrg1tgl7hni8++s/Ku/q/Bg+7euVzRbY/T V27M9B4o3vVC14aFBYdb08qR42TuAHsRrzl1bBWx6EW/7YVt0j4hx3cqTEo4TY1w hZDTDaWHCdiQ+iN0ALDGTJL+/+PFXP5sspdyGjoSOBv83q3NysygvU6eie5i+eDa AtaXhpkmn8Y78DW+OT/PnBWiR+D7fBoSVk/PVkGnSDRYYuNRhVwx5DvjgBVA7z0/ kQcvfV+6TzPtz66FupAM8TyND2cwwjrHgi6o1yFyf/GHdWr72C0Mecu9nAAdWpKU JMsvsxDqXd/jLj5KGypKxHQwdayagDkf3qj/nP2bCU5xxDx+SlmO8iKQ7zEHgi6C mfYYI3/iUDjmW2dcI+5G0Y7o5DQkuceSa8aF0a5t1HX8F1Zdd4Dfwlzm1L2UIg5U l10BuIw0MoBqojJ1kA3XzdnmgvtFa2O9LYAYv0uPGhZUWGpH91Cm+qV5jyI9S2vp hodCJLWd59EX2L2NM05mmIfj2+TTpHxqG7QX6rzwHExB1n3UNmy80u2PBgXWCZe5 IFyaEFDKxBnKeaUxkal2hl0FEZ/Jh35Fz1vOc2O1703GFqNC9//t7oXt4J6gMbSX KV/Nqh3NLxw= =xTdM -----END PGP SIGNATURE----- --wbuTI+YEd0REWzbC-- From nobody Mon Jun 2 10:49:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1109A1A0320 for ; Mon, 2 Jun 2014 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 GO4KHxUePiZQ for ; Mon, 2 Jun 2014 10:49:12 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B941A01ED for ; Mon, 2 Jun 2014 10:49:11 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B2A6160B32 for ; Mon, 2 Jun 2014 19:49:04 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 733E96038F for ; Mon, 2 Jun 2014 19:49:04 +0200 (CEST) Received: (qmail 32207 invoked by uid 1007); 2 Jun 2014 19:49:04 +0200 Date: Mon, 2 Jun 2014 19:49:04 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140602174904.GF46558@Space.Net> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3ZdUzTbr01LY-dq3lwn5UuRCh18 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:49:14 -0000 Hi, On Mon, Jun 02, 2014 at 06:49:13PM +0200, Philip Homburg wrote: > One philosophical question is whether it is the host or network that is > responsible for dealing with such brokenness? I'm not so much concerned about philosophy, I'm an engineer. > The nice thing about the IPv4 architecture is the split between the network > and the transport layer on the hosts: the network transports packets from > source to destination, occasionally dropping packets, reordering them and > in extreme cases duplicating them. > > The host transport layer retransmits and reorders packets and filters out > duplicates. Host do not know about the network, they just pass packets to > the default router (or other routers in case of ICMP redirects). > > Making the host resposible for good source address selection in case network > failures violates that model. This theory is very nice. Unfortunately, it's, uh, theory, and today's Internet does not really know very much about this. It *does* know about budget ISPs that are too cheap to pay engineers to properly monitor their network, about de-coupled control and data planes that advertise reachability but sink the data packets, extremely overloaded links between ISPs fighting (de-)peering wars, and other unfriendlyness. > If we make the router responsible dealing with failures, then it helps to > separate mechanism from policy. In the failure scenario I described, there is no (reasonable) way a home router can know that "ISP C" has messed up their MPLS network (again!) and it's no use sending packets out ISP A to reach host Z. Even if it knew, other targets might work perfectly well via ISP A, while yet other parts are broken via ISP B. So "withdraw a prefix as soon as something is broken upstream" will usually give you "zero working prefixes", given that something is always broken somewhere. [..] > For policy, even if you would have to tell a router manually that link is > broken, it would help already enormously if entire site would then reconfigure > automatically. Please understand that it's not "the link" that is broken, or even "ISP A" - these cases are trivial, and reconfiguring the site is also quite trivial, except - to some extent - for externally published DNS records. [..] > Beyond that, many different types of pluggable detectors are possible. > If for me, say, github is important, then having a module that can poll a > website regularly would do the trick. Yeah. I can easily see *end users* do that, or router vendors update their gear two years after it has been solved to monitor the Next Big Thing on the Internet. The *host* knows where it wants to connect to, and that it has multiple options in case one doesn't work. Coming back to your example and extending it a bit: what do you do if github is broken via ISP A, while netflix is broken via ISP B? If you can solve that with prefix announcements, I'm all ears. Until then, I maintain that "dual prefixes with source address failover *plus* a way to present the prefix selection to the application(!) user" is a more workable way in that scenario. (There are a number of ways such a "magic CPE" could achieve the end result with dirty tricks, like involving NPT66 to circumvent non-working paths, but I can't see a way to make it work without resolving to those) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jun 2 13:43:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9959A1A0463 for ; Mon, 2 Jun 2014 13:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 K-fA75HUIznU for ; Mon, 2 Jun 2014 13:43:02 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8AC1A0448 for ; Mon, 2 Jun 2014 13:43:02 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id g10so3778141pdj.22 for ; Mon, 02 Jun 2014 13:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hzl66tLzM1iHiEqlcTwd/k9JIVJUD9b+itAuEEpuVag=; b=rZboS3PHXq280qv2LopfN8h7nMcNLjhz7ux8mIOqz+KXpEC9VdCUGNo3glEqZ/IXMF z47EK0lX+XvAH7eXQGrHAtCatbh9j0wVUVqlaS0c6jsCEQ8onmEIKGaiVFx04zU1ZKE7 O3Kr5z/B0JeDkSK+fAu+oW7CqxuD0TGBGW2t/8PUh/5MsLZrIrOfhwppdqMLZkEMH/qZ /GHQ809PoUT6uf3QNgkDTS+zb3u+g94vPA+hGBuC9UailBaJCeCS6l7D9vy3nyGy0oxv gK4nUuhBNinXLz7RwRXeNQLmJ0AgXriw5ji0Cy9tneya/jwXV0LmXQgCPwov2U61VZHA +UfQ== X-Received: by 10.66.144.104 with SMTP id sl8mr32909890pab.81.1401741776855; Mon, 02 Jun 2014 13:42:56 -0700 (PDT) Received: from [192.168.178.23] (190.192.69.111.dynamic.snap.net.nz. [111.69.192.190]) by mx.google.com with ESMTPSA id iv2sm21969785pbc.19.2014.06.02.13.42.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 13:42:56 -0700 (PDT) Message-ID: <538CE1CF.9030002@gmail.com> Date: Tue, 03 Jun 2014 08:42:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> In-Reply-To: <20140602081743.GP46558@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WSiOKu_C3h1O61Qggg6ysEDO7mQ Cc: Philip Homburg , V6 Ops List Subject: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:43:03 -0000 On 02/06/2014 20:17, Gert Doering wrote: ... > OTOH, proper source address failover on "host" to source address B would > very nicely solve this whole category of connectivity issues - and (by > enforcing halfway symmetric return traffic via ISP B) would actually solve > it *better* than BGP routing, which might need manual fiddling with the > router to remove "ISP C" from the path. I know that shim6 isn't popular around here, but if you actually want to achieve this effect - for any transport protocol, and any application protocol, unmodified - run linshim6 at both ends. > (IETF is complaining about lack of operator input. Here is operator input. > Don't ignore it, otherwise operators get bored and find solutions outside > IETF space, like, with NAT) Not to pretend that shim6 doesn't have operational issues too (like needing SADR and tolerant firewalls). Brian > > Gert Doering > -- NetMaster > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 2 13:47:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D711A0425 for ; Mon, 2 Jun 2014 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 RANGhq8bNFKV for ; Mon, 2 Jun 2014 13:47:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA09D1A0410 for ; Mon, 2 Jun 2014 13:47:36 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5063960B3F for ; Mon, 2 Jun 2014 22:47:30 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2098C60B36 for ; Mon, 2 Jun 2014 22:47:30 +0200 (CEST) Received: (qmail 77514 invoked by uid 1007); 2 Jun 2014 22:47:30 +0200 Date: Mon, 2 Jun 2014 22:47:30 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20140602204730.GH46558@Space.Net> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FU0ddqmMGjnLUeuc" Content-Disposition: inline In-Reply-To: <538CE1CF.9030002@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S-tnqyZFJcgHJs0bupZfINcWVYg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:47:38 -0000 --FU0ddqmMGjnLUeuc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jun 03, 2014 at 08:42:55AM +1200, Brian E Carpenter wrote: > On 02/06/2014 20:17, Gert Doering wrote: > ... > > OTOH, proper source address failover on "host" to source address B would > > very nicely solve this whole category of connectivity issues - and (by > > enforcing halfway symmetric return traffic via ISP B) would actually so= lve > > it *better* than BGP routing, which might need manual fiddling with the > > router to remove "ISP C" from the path. >=20 > I know that shim6 isn't popular around here, but if you actually > want to achieve this effect - for any transport protocol, and > any application protocol, unmodified - run linshim6 at both ends. I've heard very good results about failover tests with shim6 (much faster convergence than BGP). =20 I'm not convinced we particularily *need* it, though, as - as far as I=20 understood - shim6 will primarily serve to ensure session survivability,=20 while in most scenarios, sessions are so shortlived that "oh, ISP broken, use other one" will be a matter of clicking reload in the browser... Or will it also take care of selective non-reachability at session setup ("something in the ISP A path to Z broken")? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --FU0ddqmMGjnLUeuc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4zi4d9WwGXkzn/FAQI0HQ//d5dmxGZ4wow+WWn/vsH2LbLWK5Zw2IZN KiJv2GTpP6H6PiGTdoYbIKShew/lIGCxpXk/kSq3rddbNmgtYHJVtQGOXItoBTd1 vwNcPwvg6cRBJVNL64HKdj37uoU+ROjydEwlyg29aq52mIXLKBjZxi0WGRADZ23b SGgt+A6icPZkOWHaaD7n67eWVDiodnlZIKpJM6CG5dQqJ/qqzhFkZFfAvbaL4hzR 8xVphOjPkrE2DEZax3PO3L7iiuBD0MAAtCj+9zKPEPvTnGyQpesc/Sc52Co6mZ73 omPzonFSHUgir8xD9VkZusOMWiVwZXsEPYqvGxil6PdblqB9fmJSNGM733KTUZ4R 4nUAlh+3kDp/ITjWsfgepYHilbXwWspUcqSwfkHHlKnIGF26pOwRY0ITNHtRWmSY WT1GGboP/1NI2xV0uWY16p0yEAslYuiBh4Wypbo5Qkp8IWAeL9fqcDxy81Ztjx8A GGCHFfsGKUCnHr8YkZe85gbd8iJp9nLBUH8CNnKuLwKHwHSa8/zUMmPxmvYkgwY7 DqUMGj7JSLU0j+/2FjmCoWNtQMIZp4CXdsjz4uotrAAlFpR1N8ZwBTKPhnvLuzSD 5nL+exrv+ZwkocpCm7q9Y7kvcoLWhZSYQiikuRn+yXgj7k1Ad7VzlMiJeaL9+NDh 096y8RfdRuA= =dPJU -----END PGP SIGNATURE----- --FU0ddqmMGjnLUeuc-- From nobody Mon Jun 2 13:57:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56FD1A043E for ; Mon, 2 Jun 2014 13:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 GR8mHGLgdLbH for ; Mon, 2 Jun 2014 13:57:11 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D098A1A0425 for ; Mon, 2 Jun 2014 13:57:11 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8C9631B8204 for ; Mon, 2 Jun 2014 13:57:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 812D219005C; Mon, 2 Jun 2014 13:57:06 -0700 (PDT) Received: from [10.1.10.98] (173.162.205.174) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 13:57:06 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <20140602204730.GH46558@Space.Net> Date: Mon, 2 Jun 2014 16:57:03 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [173.162.205.174] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YpxYnxFw99TR99-jrrcTnz_neI4 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:57:13 -0000 On Jun 2, 2014, at 4:47 PM, Gert Doering wrote: > I'm not convinced we particularily *need* it, though, as - as far as I=20= > understood - shim6 will primarily serve to ensure session = survivability,=20 > while in most scenarios, sessions are so shortlived that "oh, ISP = broken, > use other one" will be a matter of clicking reload in the browser... The long-lived connection I'd be most interested in would be a download = or a video stream. TBH, I don't know the state of the art on streaming = and multiply homed devices, though. I know that there are techniques = that spread streams across flows, but I don't know if they spread flows = across links without operator intervention on a dual-homed home network.= From nobody Mon Jun 2 14:27:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4C1A044F for ; Mon, 2 Jun 2014 14:27:32 -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, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 kvIc8FKdGiil for ; Mon, 2 Jun 2014 14:27:30 -0700 (PDT) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1003A1A0448 for ; Mon, 2 Jun 2014 14:27:29 -0700 (PDT) Received: from [66.196.81.174] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2014 21:27:24 -0000 Received: from [98.139.212.223] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2014 21:27:23 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 02 Jun 2014 21:27:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 854209.97641.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 92631 invoked by uid 60001); 2 Jun 2014 21:27:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401744443; bh=RQRHbi+2haTEsiA1YIbjkpp792eUh1sxPP7K+urVCIM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NA5RdEh4X24LiOIb/FWl4SshT+j6Y7j6Ou5IYAnDAA+TV9+in8wemcVR7Os3SVZgQ+9/QWVmHNqtS+1KvNW9ZUNNeb3O0hHY+J65g2PQNaNUUEWnZQX+e+U66kNj08mpAQkewXCXV4c4T54rYxZZ50Nh7VY/KRwDpJnB/zfS8FU= X-YMail-OSG: m.XqazsVM1nP.S5QrLhwFKKJYLTM40UzSNKJ8VBk_2qTUi6 BSPpYkhE45HoXRrqOfTDBXHFWJTDMp3HDL2CDuHksg59idOx_1zaoIK9di2u tE0BaKd4cEa8F75MGfzHxCt9ruloBNUiIZbfUnP7jrI3eDChX2v6eElI7Cto puHIDzpKyBhWFtVzUFFpeo2T3nenBk1xrqYJg68_pYw21g3f7u1vadDXFd2Q 4Imn7OyS9QTqzGbzHggkrbuutX1QKq6r32IYy9KaP7XkXs9S7lrqgUyumTUH 37yJOXJCNHzFZA.WtmjaUW3MboPxEkuAZVeAZcP4zgv1GJeLAnUXFMoDoHVT NP1tDp8_SmVd7_WYcpqEsYfwM3y5CIfwrGy8tFwoVmwhnDgKMaWqYBEoYQLK PypqEVNpH_Pne9Kn5_7M6k8PfEB_4cQqa.KjbnALspYH8uf4qWwKKqUbNIA_ 6D.KpHw2A.Rc9u23_ijyvtcd1iSRVqczcyZdXADePM.hAjoQE1Pcm0zY0isJ 0HvVAdn.mRWvkVsTfjSv9K.w._1NxyGCQ76nQtmfSXGXpsTvHVDhJcud6Izq 3BNbWlkr6eC9GtWtendgxecHs.OjyKW7iFbGPAIyWukssmBy46QHZ7SM- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Mon, 02 Jun 2014 14:27:23 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBQaGlsaXAgSG9tYnVyZyA8cGNoLXY2b3BzLTNhQHUtMS5waGljb2guY29tPgo.IFRvOiBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFR1ZXNkYXksIDMgSnVuZSAyMDE0IDI6MjggQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQSSBbVUxBIGRyYWZ0IHJldmlzaW9uICMyIFJlZ2FyZGluZyBpc29sYXRlZCBuZXR3b3Jrc10KPiAKPiBJbiB5b3VyIGxldHRlciBkYXRlZCBNb24sIDAyIEp1biAyMDE0IDA5OjEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140601231140.303E9171FD22@rock.dv.isc.org> Message-ID: <1401744443.72735.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Mon, 2 Jun 2014 14:27:23 -0700 (PDT) From: Mark ZZZ Smith To: Philip Homburg , V6 Ops List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rTf5nU_9mjLw17n9O9or0-FltB8 Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 21:27:32 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Philip Homburg =0A> To: V6 Ops List =0A> Cc: =0A> Sent= : Tuesday, 3 June 2014 2:28 AM=0A> Subject: Re: [v6ops] PI [ULA draft revis= ion #2 Regarding isolated networks]=0A> =0A> In your letter dated Mon, 02 J= un 2014 09:11:40 +1000 you wrote:=0A>> Every piece of client software shoul= d already support multi-homing.=0A>> This is about supporting it *better* s= o there isn't the big delay=0A>> when switching to the second address becau= se the link at the other=0A>> end is down.=A0 The stack should be choosing = source addresses which=0A>> have working outbound paths.=A0 Selecting desti= nation addresses is=0A>> up to the application.=0A>> =0A>> This is about ma= king the error cases work better which quite frankly=0A>> should have been = done years ago for IPv4.=A0 The only ones that don't=0A>> benefit from this= is GLB developers.=0A> =0A> I'd like to see IPv6 deployed sooner rather th= an later. And in my =0A> experience,=0A> everywhere where IPv6 is different= from IPv4 it causes problems and extra=0A> delays.=0A>=A0=0A=0ASo if IPv6 = was no different to IPv4 ... it'd be IPv4. So naturally, no matter how simi= lar or different to IPv4 IPv6 was made, there was always going to be additi= onal complexity when deploying it in parallel with IPv4.=0A=0A> So if you s= ay 'every piece of client software should already support=0A=0A> multi-homi= ng' then that is simply not true in the IPv4 world. At least while=0A> givi= ng reasonable performance.=0A>=A0=0A=0AI think that is actually an observat= ion on how ubiquitous, reliable and reliably operated IPv4 is. The parallel= HE approach clearly makes just as much sense for IPv4 instead of attemptin= g each A RR IPv4 address sequentially after a timeout.=0A=0AIn some ways th= e it is surprising that the HE approach hasn't be necessary under IPv4. Goo= gle seem to consider that they need to facilitate IPv4 redundancy in this w= ay, as a query for A records for google.com returns 16 different A records.= I doubt they'd be doing that unless they had some evidence that it is usef= ul to some portion of end-users. They are shuffling the addresses around on= each query, however they could do that but still only return one.=0A=0A=0A= Another way to think of the HE technique is that it is a variation of recov= ery from TCP SYN packet loss. Traditional recovery took place "horizontally= ", within a single TCP connection. HE recovery is taking place "vertically"= , across multiple different TCP connections (and possibly different layer 3= protocols.)=0A=0A> If all IPv4 software supported multi-homing properly, t= hen there was no need =0A> for happy eyeballs. And many of the features tha= t discussed in the context=0A> of happy eyeballs were not implemented in a = large scale before.=0A> =0A> As a result, there also no standard API for do= ing HE. The Berkeley socket=0A> interface is still the same because in prac= tice, eveybody is not doing=0A> multi-homed. =0A> =0A> Doing HE with minima= l overhead is very tricky. It is very easy for most=0A> client systems to t= ake a full matrix of source and destination addresses and=0A> connect to al= l of them. I'm quite sure that most operators of server systems=0A> would c= ompletely hate that approach.=0A>=A0=0A=0ASo I think if you made them think= about it, they'd probably change their mind. The servers exist to serve, a= nd therefore anything that provides better service to the clients is certai= nly worth considering, if not implementing. They will consequently earn a r= eputation as being a reliable and high performing server operator.=0A=0AThe= y might probably also want to consider Multipath TCP at the same time, for = the same reasons - better server/service performance and reliability. HE + = MPTCP would provide more of both.=0A=0A=0A=0A> Simply put, the more things = we come up with that have to be done before someone=0A> can deplay IPv6, th= e longer it will take.=0A> =0A> =0A> =0A> _________________________________= ______________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/v6ops=0A> From nobody Mon Jun 2 16:11:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49B1A03C4 for ; Mon, 2 Jun 2014 16:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7mjgmY39jT8k for ; Mon, 2 Jun 2014 16:11:27 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3853F1A03A0 for ; Mon, 2 Jun 2014 16:11:27 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so1655346pad.29 for ; Mon, 02 Jun 2014 16:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CsLUPyPfMQ3pWAM7O1CY7QoOzuxDYjq8j9yjhZiH/VI=; b=a9zT2kqN7ilbsFmQHVOGHpMpm1hUV4rUHx/Ck7WD4VqsFdU3WErFmsslLbfwB/P13H NQbRRGW3qA0YGShuEw0a7IxBCU6ZnoL9xjm6/COI27yjaMVJVFUxgsVcrfgAx3gwQ3EG GfqyG02XhAmjTLt48MeHTBhr9z4i1gfib3tsjKAxc+2rO/4hcVJ2vM2//EQb+/pzN2xx 2AM0iaofvxRoQTa4CVKRYPNlMoGx1FwY1BIJ+ribSdwxckKmQ01VX6Ps/cyTVHN/8M/o YFbAvMdE2UGZ7auJ35+FF1/GAtTDWSvJeL5jZGuYUIXfT8lQ5HDShRA3NWyTDQ5t1tQC 048w== X-Received: by 10.68.178.131 with SMTP id cy3mr45188394pbc.146.1401750681712; Mon, 02 Jun 2014 16:11:21 -0700 (PDT) Received: from [192.168.178.23] (190.192.69.111.dynamic.snap.net.nz. [111.69.192.190]) by mx.google.com with ESMTPSA id au4sm22306271pbc.10.2014.06.02.16.11.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 16:11:21 -0700 (PDT) Message-ID: <538D0499.3000406@gmail.com> Date: Tue, 03 Jun 2014 11:11:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> In-Reply-To: <20140602204730.GH46558@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YZ1PDm5L9cfv0ymIncjeq1lpDNg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:11:30 -0000 On 03/06/2014 08:47, Gert Doering wrote: > Hi, > > On Tue, Jun 03, 2014 at 08:42:55AM +1200, Brian E Carpenter wrote: >> On 02/06/2014 20:17, Gert Doering wrote: >> ... >>> OTOH, proper source address failover on "host" to source address B would >>> very nicely solve this whole category of connectivity issues - and (by >>> enforcing halfway symmetric return traffic via ISP B) would actually solve >>> it *better* than BGP routing, which might need manual fiddling with the >>> router to remove "ISP C" from the path. >> I know that shim6 isn't popular around here, but if you actually >> want to achieve this effect - for any transport protocol, and >> any application protocol, unmodified - run linshim6 at both ends. > > I've heard very good results about failover tests with shim6 (much faster > convergence than BGP). > > I'm not convinced we particularily *need* it, though, as - as far as I > understood - shim6 will primarily serve to ensure session survivability, > while in most scenarios, sessions are so shortlived that "oh, ISP broken, > use other one" will be a matter of clicking reload in the browser... > > Or will it also take care of selective non-reachability at session setup > ("something in the ISP A path to Z broken")? > No. One of the design features of shim6 is *not* to create any overhead for short-lived sessions, which means that by definition it only wakes up after the first packets of a session have flowed. I think that there are some very interesting ideas in shim6, but it could be that it needs some redesign at this point in history, espicially given the experience and thinking around MPTCP and Happy Eyeballs. Brian From nobody Mon Jun 2 16:40:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786E1A03E7 for ; Mon, 2 Jun 2014 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TIME=2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 nK8vWHbz5K0n for ; Mon, 2 Jun 2014 16:40:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A11A03D6 for ; Mon, 2 Jun 2014 16:40:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id AA656349479; Mon, 2 Jun 2014 23:40:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1E848160067; Mon, 2 Jun 2014 23:45:22 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B5D08160057; Mon, 2 Jun 2014 23:45:21 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 47DF017375B9; Tue, 3 Jun 2014 09:39:43 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> In-reply-to: Your message of "Mon, 02 Jun 2014 12:37:01 -0400." Date: Tue, 03 Jun 2014 09:39:43 +1000 Message-Id: <20140602233943.47DF017375B9@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MNxSgcL9w9azj9PN5nw573fCORE Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:40:24 -0000 Border NAT (IPv4) and depreferencing a prefix + SADR (IPv6) are equivalent in terms of failure reachability. Depreferencing a prefix + SADR (IPv6) just moves the source address selection from the NAT to the host. This is what most homes will get to because there is unlikely to be more than link up/down on the upstream links. If you add BGP then external reachability can be added to the source address selection of border NAT. But if you are up to running BGP then PI is the way to go. Extending HE to do multiple source addresses (one per prefix) within a adddress family will give pretty much the same robustness as running BGP at the cost of some embryonic connections if the initial attempt doesn't work. Mark In message , Ted Lemon writes : > On Jun 1, 2014, at 4:38 PM, Ted Lemon wrote: > > On Jun 1, 2014, at 2:02 PM, joel jaeggli wrote: > >> Assumption of the Existence of HE is a pretty dodgy proposition. > > Then we can't do multihoming without NAT. > > This rather badly qualified comment appears to have generated a lot of discus > sion, so to head off further discussion I'd like to clarify a few points. > > First, if you are multihomed, and both paths are working, then a host that do > es nothing special will work. Second, if one connection goes out, and the r > outing updates, then an application that just retries when it doesn't get a c > onnection will get a connection; for applications for which delays on the ord > er of the time it takes for routing to update are harmless, redundant multiho > ming will work with no changes. > > So the statement I made was false when interpreted in this context. I know > that it's false, and you don't need to keep arguing with me to convince me it > 's false. I'm sorry for having been sufficiently unspecific that people tho > ught I meant my statement was true for the above cases. > > The cases I care about are in fact edge cases. They don't happen all the ti > me, and depending on the application they may or may not be important. I ca > re about them because I've been affected by failures, and I'd like to be able > to say how to get these cases right without resorting to the use of NAT or N > PT. I'd like for there to be better tools for application developers to use > so that they can address these edge cases relatively cheaply; possibly even > more cheaply than they now do network programming that doesn't address these > edge cases. If you don't care about these edge cases, you will have little > concern for this, and will not consider dealing with these edge cases importa > nt. > > I, and no doubt most participants on this mailing list, am deeply unintereste > d in hearing "it works okay for me, so your edge cases don't matter" I am a > lso not interested in trying to get you to say "I care deeply about these edg > e cases." It's okay with me if you don't care about them, and don't conside > r it important that they be addressed. You don't need to respond to this me > ssage with yet another assertion that there is no problem here--it won't conv > ince me, and what I want to do about this probably won't affect your applicat > ion anyway. > > If you are interested in thinking about this problem, the place to discuss it > is probably the MIF working group--it's related to the work that's being don > e there, although it's not the entirety of that work. If you are not intere > sted, please let's just let this drop. I'm sorry for the troll--I didn't in > tend it to be a troll, but I could have phrased it in a way that was less tro > llish. I will try to do better next time. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 2 20:38:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415A81A0073 for ; Mon, 2 Jun 2014 20:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 P-4xoL6FfFuW for ; Mon, 2 Jun 2014 20:38:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B261A0074 for ; Mon, 2 Jun 2014 20:38:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT78392; Tue, 03 Jun 2014 03:38:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 04:37:39 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 04:38:22 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 11:38:18 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: Revised texts for ULA #3 NPTv6 Use Case Thread-Index: AQHPft1CJ+GB1E45A0C5tdmrqNI6GQ== Date: Tue, 3 Jun 2014 03:38:18 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Iv81w75A_OH45rUeZcVgELX4F_w Cc: "v6ops-chairs@tools.ietf.org" Subject: [v6ops] Revised texts for ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 03:38:37 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhciBhbGwsDQoNCkJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9uLCBJIHByb3Bvc2Ugc29t ZSByZXZpc2VkIHRleHRzIGFzIHRoZSBmb2xsb3dpbmcuDQpQbGVhc2UgY29tbWVudCB0byBzZWUg d2hldGhlciB3ZSBjYW4gYWNoaWV2ZSBjb25zZW5zdXMgb24gdGhpcyBpc3N1ZS4NCg0KTWFueSB0 aGFua3MhDQoNClJldmlzZWQgdGV4dHMgaW4gU2VjdGlvbiAzLjIuMToNCuKAnG8gIFVzaW5nIE5l dHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uDQoNCiAgIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9u IChOUFR2NikgW1JGQzYyOTZdIGlzIGFuIGV4cGVyaW1lbnRhbA0KICAgc3BlY2lmaWNhdGlvbiB0 aGF0IHByb3ZpZGVzIGEgc3RhdGVsZXNzIG9uZSB0byBvbmUgbWFwcGluZyBiZXR3ZWVuDQogIGlu dGVybmFsIGFkZHJlc3NlcyBhbmQgZXh0ZXJuYWwgYWRkcmVzc2VzLiBbUkZDNjI5Nl0gY29uc2lk ZXJzIHRyYW5zbGF0aW5nDQpVTEEgcHJlZml4ZXMgaW50byBHVUEgcHJlZml4ZXMgYXMgYSB1c2Ug Y2FzZS4gQWx0aG91Z2ggTlBUdjYgaXMgbm90IGV4YWN0bHkNCnRoZSBzYW1lIHdpdGggdGhlIHRy YWRpdGlvbmFsIHN0YXRlZnVsIE5BVC9OQVBUICh3aGljaCBpcyBkaXNjb3VyYWdlZCBpbg0KW1JG QzU5MDJdKSwgaXQgYWxzbyBpbnRyb2R1Y2VzIHNvbWUgc2ltaWxhciBhZGRpdGlvbmFsIGNvbXBs ZXhpdHkgb24gbWFueQ0KYXBwbGljYXRpb25zLCB3aGljaCBtaWdodCBjYXVzZSBhcHBsaWNhdGlv bnMgYnJlYWsuDQoNClNvIGluIGdlbmVyYWwsIHRoaXMgZG9jdW1lbnQgZG9lc27igJl0IGVuY291 cmFnZSB0byB1c2UgVUxBK05QVHY2IChob3dldmVyLA0Kc29tZSBvcGVyYXRpb25hbCBjb25zaWRl cmF0aW9ucyBhcmUgcHJvdmlkZWQgYmVsb3cgZm9yIHRoZSBvbmVzIHdobyBpbnNpc3QgdG8NCnVz ZSBVTEErTlBUdjYgZm9yIHNvbWUgcmVhc29uKS4gVGhpcyBkb2N1bWVudCBjb25zaWRlcnMgVUxB K0dVQSBhcyBhIGJldHRlcg0KYXBwcm9hY2ggdG8gY29ubmVjdCB0byB0aGUgZ2xvYmFsIG5ldHdv cmsgd2hlbiBVTEFzIGFyZSBleHBlY3RlZCB0byBiZSByZXRhaW5lZC4NClVMQStHVUEgaXMgZGlz Y3Vzc2VkIGluIGRldGFpbCBpbiBTZWN0aW9uIDMuMi4yIGJlbG93LuKAnQ0KDQoNCk9yaWdpbmFs IHRleHRzOg0K4oCcbyAgVXNpbmcgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24NCg0KICAgTmV0 d29yayBQcmVmaXggVHJhbnNsYXRpb24gKE5QVHY2KSBbUkZDNjI5Nl0gaXMgYW4gZXhwZXJpbWVu dGFsDQogICBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBzdGF0ZWxlc3Mgb25lIHRvIG9u ZSBtYXBwaW5nIGJldHdlZW4NCiAgaW50ZXJuYWwgYWRkcmVzc2VzIGFuZCBleHRlcm5hbCBhZGRy ZXNzZXMuDQoNCiAgIEluIHNvbWUgdmVyeSBjb25zdHJhaW5lZCBzaXR1YXRpb25zKGZvciBleGFt cGxlLCBpbiB0aGUgc2Vuc29ycyksIHRoZQ0KICAgbmV0d29yayBuZWVkcyBVTEEgYXMgdGhlIG9u LWRlbWFuZCBhbmQgc3RhYmxlIGFkZHJlc3Npbmcgd2hpY2gNCiAgIGRvZXNuJ3QgbmVlZCBtdWNo IGNvZGUgdG8gc3VwcG9ydCBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtcyBsaWtlDQogICBE SENQIG9yIGZ1bGwgTkQgKE5vdGU6IHN1cmVseSBpdCBuZWVkcyBTTEFBQykuIElmIHRoZSBuZXR3 b3JrIGFsc28NCiAgIG5lZWRzIHRvIGNvbm5lY3QgdG8gdGhlIG91dHNpZGUsIHRoZW4gdGhlcmUg Y2FuIGJlIGFuIE5QVHY2IGdhdGV3YXkNCiAgIHdoaWNoIGlzIG5vdCBzdWJqZWN0IHRvIGV4dHJl bWUgcmVzb3VyY2UgY29uc3RyYWludHMuIEVzcGVjaWFsbHkgd2hlbg0KICAgYSBsaWdodHdlaWdo dCBpc29sYXRlZCBuZXR3b3JrIG5lZWRzIHRvIGFkZCBJbnRlcm5ldCBjb25uZWN0aXZpdHksDQog ICB0aGlzIGlzIHF1aXRlIGEgc3RyYWlnaHRmb3J3YXJkIGFuZCBlZmZpY2llbnQgd2F5Lg0KDQog ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludGVuZCB0byBlbmNvdXJhZ2UgdGhlIFVMQSBiaW5k aW5nIHdpdGggTlBUdjYNCiAgIG1vZGVsLCBzaW5jZSBpbiBbUkZDNTkwMl0gdGhlIElBQiBoYWQg YWxyZWFkeSBnYXZlIG9waW5pb25zIG9uIElQdjYNCiAgIE5BVDsgYnV0IHRoaXMgZG9jdW1lbnQg Y29uc2lkZXJzIGl0IGFzIGFuIGVmZmVjdGl2ZSBhcHByb2FjaCBpbiBzb21lDQogICBzcGVjaWZp YyBzaXR1YXRpb25zIGFzIGRlc2NyaWJlZCBhYm92ZS7igJ0NCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCFbaWYg IXN1cHBvcnRBbm5vdGF0aW9uc10+PHN0eWxlIGlkPSJkeW5Db20iIHR5cGU9InRleHQvY3NzIj48 IS0tIC0tPjwvc3R5bGU+PHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+PCEtLQ0KZnVuY3Rp b24gbXNvQ29tbWVudFNob3coYW5jaG9yX2lkLCBjb21faWQpDQp7DQoJaWYobXNvQnJvd3NlckNo ZWNrKCkpIA0KCQl7DQoJCWMgPSBkb2N1bWVudC5hbGwoY29tX2lkKTsNCgkJYSA9IGRvY3VtZW50 LmFsbChhbmNob3JfaWQpOw0KCQlpZiAobnVsbCAhPSBjICYmIG51bGwgPT0gYy5sZW5ndGggJiYg bnVsbCAhPSBhICYmIG51bGwgPT0gYS5sZW5ndGgpDQoJCQl7DQoJCQl2YXIgY3cgPSBjLm9mZnNl dFdpZHRoOw0KCQkJdmFyIGNoID0gYy5vZmZzZXRIZWlnaHQ7DQoJCQl2YXIgYXcgPSBhLm9mZnNl dFdpZHRoOw0KCQkJdmFyIGFoID0gYS5vZmZzZXRIZWlnaHQ7DQoJCQl2YXIgeCAgPSBhLm9mZnNl dExlZnQ7DQoJCQl2YXIgeSAgPSBhLm9mZnNldFRvcDsNCgkJCXZhciBlbCA9IGE7DQoJCQl3aGls ZSAoZWwudGFnTmFtZSAhPSAiQk9EWSIpIA0KCQkJCXsNCgkJCQllbCA9IGVsLm9mZnNldFBhcmVu dDsNCgkJCQl4ID0geCArIGVsLm9mZnNldExlZnQ7DQoJCQkJeSA9IHkgKyBlbC5vZmZzZXRUb3A7 DQoJCQkJfQ0KCQkJdmFyIGJ3ID0gZG9jdW1lbnQuYm9keS5jbGllbnRXaWR0aDsNCgkJCXZhciBi aCA9IGRvY3VtZW50LmJvZHkuY2xpZW50SGVpZ2h0Ow0KCQkJdmFyIGJzbCA9IGRvY3VtZW50LmJv ZHkuc2Nyb2xsTGVmdDsNCgkJCXZhciBic3QgPSBkb2N1bWVudC5ib2R5LnNjcm9sbFRvcDsNCgkJ CWlmICh4ICsgY3cgKyBhaCAvIDIgPiBidyArIGJzbCAmJiB4ICsgYXcgLSBhaCAvIDIgLSBjdyA+ PSBic2wgKSANCgkJCQl7IGMuc3R5bGUubGVmdCA9IHggKyBhdyAtIGFoIC8gMiAtIGN3OyB9DQoJ CQllbHNlIA0KCQkJCXsgYy5zdHlsZS5sZWZ0ID0geCArIGFoIC8gMjsgfQ0KCQkJaWYgKHkgKyBj aCArIGFoIC8gMiA+IGJoICsgYnN0ICYmIHkgKyBhaCAvIDIgLSBjaCA+PSBic3QgKSANCgkJCQl7 IGMuc3R5bGUudG9wID0geSArIGFoIC8gMiAtIGNoOyB9DQoJCQllbHNlIA0KCQkJCXsgYy5zdHls ZS50b3AgPSB5ICsgYWggLyAyOyB9DQoJCQljLnN0eWxlLnZpc2liaWxpdHkgPSAidmlzaWJsZSI7 DQp9CX0JfQ0KZnVuY3Rpb24gbXNvQ29tbWVudEhpZGUoY29tX2lkKSANCnsNCglpZihtc29Ccm93 c2VyQ2hlY2soKSkNCgkJew0KCQljID0gZG9jdW1lbnQuYWxsKGNvbV9pZCk7DQoJCWlmIChudWxs ICE9IGMgJiYgbnVsbCA9PSBjLmxlbmd0aCkNCgkJew0KCQljLnN0eWxlLnZpc2liaWxpdHkgPSAi aGlkZGVuIjsNCgkJYy5zdHlsZS5sZWZ0ID0gLTEwMDA7DQoJCWMuc3R5bGUudG9wID0gLTEwMDA7 DQoJCX0gfSANCn0NCmZ1bmN0aW9uIG1zb0Jyb3dzZXJDaGVjaygpDQp7DQoJbXMgPSBuYXZpZ2F0 b3IuYXBwVmVyc2lvbi5pbmRleE9mKCJNU0lFIik7DQoJdmVycyA9IG5hdmlnYXRvci5hcHBWZXJz aW9uLnN1YnN0cmluZyhtcyArIDUsIG1zICsgNik7DQoJaWU0ID0gKG1zID4gMCkgJiYgKHBhcnNl SW50KHZlcnMpID49IDQpOw0KCXJldHVybiBpZTQ7DQp9DQppZiAobXNvQnJvd3NlckNoZWNrKCkp DQp7DQoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb21hbmNob3Ii LCJiYWNrZ3JvdW5kOiBpbmZvYmFja2dyb3VuZCIpOw0KCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5 bkNvbS5hZGRSdWxlKCIubXNvY29tb2ZmIiwiZGlzcGxheTogbm9uZSIpOw0KCWRvY3VtZW50LnN0 eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0IiwidmlzaWJpbGl0eTogaGlkZGVu Iik7DQoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJw b3NpdGlvbjogYWJzb2x1dGUiKTsNCglkb2N1bWVudC5zdHlsZVNoZWV0cy5keW5Db20uYWRkUnVs ZSgiLm1zb2NvbXR4dCIsInRvcDogLTEwMDAiKTsNCglkb2N1bWVudC5zdHlsZVNoZWV0cy5keW5D b20uYWRkUnVsZSgiLm1zb2NvbXR4dCIsImxlZnQ6IC0xMDAwIik7DQoJZG9jdW1lbnQuc3R5bGVT aGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJ3aWR0aDogMzMlIik7DQoJZG9jdW1l bnQuc3R5bGVTaGVldHMuZHluQ29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJiYWNrZ3JvdW5kOiBp bmZvYmFja2dyb3VuZCIpOw0KCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIu bXNvY29tdHh0IiwiY29sb3I6IGluZm90ZXh0Iik7DQoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHlu Q29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJib3JkZXItdG9wOiAxcHQgc29saWQgdGhyZWVkbGln aHRzaGFkb3ciKTsNCglkb2N1bWVudC5zdHlsZVNoZWV0cy5keW5Db20uYWRkUnVsZSgiLm1zb2Nv bXR4dCIsImJvcmRlci1yaWdodDogMnB0IHNvbGlkIHRocmVlZHNoYWRvdyIpOw0KCWRvY3VtZW50 LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0IiwiYm9yZGVyLWJvdHRvbTog MnB0IHNvbGlkIHRocmVlZHNoYWRvdyIpOw0KCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5h ZGRSdWxlKCIubXNvY29tdHh0IiwiYm9yZGVyLWxlZnQ6IDFwdCBzb2xpZCB0aHJlZWRsaWdodHNo YWRvdyIpOw0KCWRvY3VtZW50LnN0eWxlU2hlZXRzLmR5bkNvbS5hZGRSdWxlKCIubXNvY29tdHh0 IiwicGFkZGluZzogM3B0IDNwdCAzcHQgM3B0Iik7DQoJZG9jdW1lbnQuc3R5bGVTaGVldHMuZHlu Q29tLmFkZFJ1bGUoIi5tc29jb210eHQiLCJ6LWluZGV4OiAxMDAiKTsNCn0NCi8vIC0tPjwvc2Ny aXB0PjwhW2VuZGlmXT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4u SFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8i Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9uLCBJIHByb3Bvc2Ugc29t ZSByZXZpc2VkIHRleHRzIGFzIHRoZSBmb2xsb3dpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBjb21tZW50IHRvIHNlZSB3aGV0aGVyIHdlIGNh biBhY2hpZXZlIGNvbnNlbnN1cyBvbiB0aGlzIGlzc3VlLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk1hbnkgdGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SZXZpc2VkIHRleHRzIGluIFNlY3Rpb24gMy4yLjE6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxvJm5ic3A7IFVzaW5nIE5ldHdvcmsgUHJlZml4 IFRyYW5zbGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBUdjYpIFtSRkM2Mjk2XSBpcyBhbiBl eHBlcmltZW50YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBzdGF0ZWxlc3Mgb25lIHRv IG9uZSBtYXBwaW5nIGJldHdlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwO2ludGVybmFsIGFkZHJlc3NlcyBhbmQgZXh0ZXJuYWwgYWRkcmVz c2VzLiBbUkZDNjI5Nl0gY29uc2lkZXJzIHRyYW5zbGF0aW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVMQSBw cmVmaXhlcyBpbnRvIEdVQSBwcmVmaXhlcyBhcyBhIHVzZSBjYXNlLiBBbHRob3VnaCBOUFR2NiBp cyBub3QgZXhhY3RseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHNhbWUgd2l0aCB0aGUgdHJhZGl0aW9uYWwg c3RhdGVmdWwgTkFUL05BUFQgKHdoaWNoIGlzIGRpc2NvdXJhZ2VkIGluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b UkZDNTkwMl0pLCBpdCBhbHNvIGludHJvZHVjZXMgc29tZSBzaW1pbGFyIGFkZGl0aW9uYWwgY29t cGxleGl0eSBvbiBtYW55DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFwcGxpY2F0aW9ucywgd2hpY2ggbWlnaHQg Y2F1c2UgYXBwbGljYXRpb25zIGJyZWFrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TbyBpbiBnZW5lcmFsLCB0aGlzIGRvY3VtZW50IGRvZXNu4oCZdCBlbmNvdXJhZ2UgdG8gdXNl IFVMQSYjNDM7TlBUdjYgKGhvd2V2ZXIsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNvbWUgb3BlcmF0aW9uYWwg Y29uc2lkZXJhdGlvbnMgYXJlIHByb3ZpZGVkIGJlbG93IGZvciB0aGUgb25lcyB3aG8gaW5zaXN0 IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj51c2UgVUxBJiM0MztOUFR2NiBmb3Igc29tZSByZWFzb24pLiBUaGlz IGRvY3VtZW50IGNvbnNpZGVycyBVTEEmIzQzO0dVQSBhcyBhIGJldHRlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ YXBwcm9hY2ggdG8gY29ubmVjdCB0byB0aGUgZ2xvYmFsIG5ldHdvcmsgd2hlbiBVTEFzIGFyZSBl eHBlY3RlZCB0byBiZSByZXRhaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVMQSYjNDM7R1VBIGlzIGRpc2N1 c3NlZCBpbiBkZXRhaWwgaW4gU2VjdGlvbiAzLjIuMiBiZWxvdy7igJ08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PcmlnaW5hbCB0ZXh0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPuKAnG8mbmJzcDsgVXNpbmcgTmV0d29yayBQcmVmaXggVHJhbnNsYXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IE5ldHdv cmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFR2NikgW1JGQzYyOTZdIGlzIGFuIGV4cGVyaW1lbnRh bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IHNwZWNpZmljYXRpb24gdGhhdCBwcm92aWRlcyBhIHN0YXRlbGVzcyBvbmUgdG8gb25lIG1hcHBp bmcgYmV0d2VlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7aW50ZXJuYWwgYWRkcmVzc2VzIGFuZCBleHRlcm5hbCBhZGRyZXNzZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJbiBzb21lIHZlcnkg Y29uc3RyYWluZWQgc2l0dWF0aW9ucyhmb3IgZXhhbXBsZSwgaW4gdGhlIHNlbnNvcnMpLCB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBu ZXR3b3JrIG5lZWRzIFVMQSBhcyB0aGUgb24tZGVtYW5kIGFuZCBzdGFibGUgYWRkcmVzc2luZyB3 aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IGRvZXNuJ3QgbmVlZCBtdWNoIGNvZGUgdG8gc3VwcG9ydCBhZGRyZXNzIGFzc2lnbm1lbnQg bWVjaGFuaXNtcyBsaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgREhDUCBvciBmdWxsIE5EIChOb3RlOiBzdXJlbHkgaXQgbmVlZHMgU0xB QUMpLiBJZiB0aGUgbmV0d29yayBhbHNvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbmVlZHMgdG8gY29ubmVjdCB0byB0aGUgb3V0c2lkZSwg dGhlbiB0aGVyZSBjYW4gYmUgYW4gTlBUdjYgZ2F0ZXdheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGlzIG5vdCBzdWJqZWN0IHRv IGV4dHJlbWUgcmVzb3VyY2UgY29uc3RyYWludHMuIEVzcGVjaWFsbHkgd2hlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGEgbGlnaHR3ZWln aHQgaXNvbGF0ZWQgbmV0d29yayBuZWVkcyB0byBhZGQgSW50ZXJuZXQgY29ubmVjdGl2aXR5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHRo aXMgaXMgcXVpdGUgYSBzdHJhaWdodGZvcndhcmQgYW5kIGVmZmljaWVudCB3YXkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGludGVuZCB0byBlbmNvdXJhZ2UgdGhlIFVMQSBiaW5kaW5nIHdpdGggTlBUdjY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtb2Rl bCwgc2luY2UgaW4gW1JGQzU5MDJdIHRoZSBJQUIgaGFkIGFscmVhZHkgZ2F2ZSBvcGluaW9ucyBv biBJUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgTkFUOyBidXQgdGhpcyBkb2N1bWVudCBjb25zaWRlcnMgaXQgYXMgYW4gZWZmZWN0aXZl IGFwcHJvYWNoIGluIHNvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBzcGVjaWZpYyBzaXR1YXRpb25zIGFzIGRlc2NyaWJlZCBhYm92ZS7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6Y29tbWVudC1saXN0Ij48IVtpZiAhc3VwcG9y dEFubm90YXRpb25zXT4NCjxociBjbGFzcz0ibXNvY29tb2ZmIiBhbGlnbj0ibGVmdCIgc2l6ZT0i MSIgd2lkdGg9IjMzJSI+DQo8IVtlbmRpZl0+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5nkgeml506mbxchi_-- From nobody Mon Jun 2 21:54:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C511A0097 for ; Mon, 2 Jun 2014 21:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 yNCuPec0d_PM for ; Mon, 2 Jun 2014 21:54:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 064271A0092 for ; Mon, 2 Jun 2014 21:54:20 -0700 (PDT) Received: from [192.168.6.108] ([213.55.105.113]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s534pQJ5031343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 21:51:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s534pQJ5031343 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401771094; bh=+tJAc+lbg5LRhqpxImw1/STqCLA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cYsmhjeAT27g2w9AZU1bMm5SHp8SZVE9b/My14hDg5MGivkJGw5nq0xlttHeFGN2s 6lHFDWS/Ooe2JMJRo3JWtB4lwf6G5vNuJkpiInlkAbE1VgGt48qZlnTJK2s7FEHHpo sYW6FVmb7W/aqIhUeYBHWcNNxr825AXeRp3f7ZCo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <20140602143321.GZ46558@Space.Net> Date: Mon, 2 Jun 2014 21:51:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <5C274637-D63B-491E-8426-AEFDD106FB96@delong.com> <20140602143321.GZ46558@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 02 Jun 2014 21:51:34 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qwLTn7lra7hPCFmj0P7Es31ugM0 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 04:54:22 -0000 On Jun 2, 2014, at 7:33 AM, Gert Doering wrote: > Hi, >=20 > On Mon, Jun 02, 2014 at 02:29:07PM +0100, Owen DeLong wrote: >> Multihoming works just fine without NAT as is. I run a network at = home which is multihomed in both IPv4 and IPv6 without NAT. >>=20 >> Multihoming is not what is actually being discussed here. As Lorenzo = pointed out this discussion seems to be limited to the (pathological) = case of multihoming which involves a separate selection of source = address for each upstream which is, for the most part, unique to IPv6 = and does, indeed, pose additional challenges not present in traditional = multihoming. >=20 > It would be really helpful if you could label your soapbox properly, = and > if you talk about "BGP based multihoming with PI addresses", then = please > *label* it as such. >=20 > The term "multihoming" does not imply more than "multihoming", in = particular, > it does not require a specific technology or addressing policy to be = used. I didn=92t say it did. Owen From nobody Mon Jun 2 22:35:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C30C1A00BF for ; Mon, 2 Jun 2014 22:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 Nt82Dq39a2Og for ; Mon, 2 Jun 2014 22:35:39 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 030B21A0031 for ; Mon, 2 Jun 2014 22:35:38 -0700 (PDT) Received: from [192.168.6.108] ([213.55.105.113]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s535VN7v032401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 22:31:36 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s535VN7v032401 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401773503; bh=pRo2rj7hOf8mEYoIZztfYRcfn3Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=XJr7Ij4qPWaRtjaoNPU0LMXmhTw/I1uoTn1U5pr72P06FZ/sN+iXDPcy+WkA6d3Gk NNvfj1MCXNIkN1MoFRWNcLtqZq5SsfrcMyjDqofkMMe3Ht8UaZrd2vfhX6ugOYsnub y1zcA6QQ3ydXEFfsZO+0aLsP7YjcaMrC9QW3JvA0= Content-Type: multipart/alternative; boundary="Apple-Mail=_E1C8B33B-122D-4874-BE7E-3F575E932D73" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> Date: Mon, 2 Jun 2014 22:31:20 -0700 Message-Id: <56A2ED2A-E4D6-49FE-BC1E-8BC337CE4273@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 02 Jun 2014 22:31:43 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qV4drkkJzbE8LgERNxhiu16FOF8 Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Revised texts for ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 05:35:41 -0000 --Apple-Mail=_E1C8B33B-122D-4874-BE7E-3F575E932D73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a major improvement. Owen On Jun 2, 2014, at 8:38 PM, Liubing (Leo) = wrote: > Hi Dear all, > =20 > Based on recent discussion, I propose some revised texts as the = following. > Please comment to see whether we can achieve consensus on this issue. > =20 > Many thanks! > =20 > Revised texts in Section 3.2.1: > =93o Using Network Prefix Translation > =20 > Network Prefix Translation (NPTv6) [RFC6296] is an experimental > specification that provides a stateless one to one mapping between > internal addresses and external addresses. [RFC6296] considers = translating > ULA prefixes into GUA prefixes as a use case. Although NPTv6 is not = exactly > the same with the traditional stateful NAT/NAPT (which is discouraged = in > [RFC5902]), it also introduces some similar additional complexity on = many > applications, which might cause applications break. > =20 > So in general, this document doesn=92t encourage to use ULA+NPTv6 = (however, > some operational considerations are provided below for the ones who = insist to > use ULA+NPTv6 for some reason). This document considers ULA+GUA as a = better > approach to connect to the global network when ULAs are expected to be = retained. > ULA+GUA is discussed in detail in Section 3.2.2 below.=94 > =20 > =20 > Original texts: > =93o Using Network Prefix Translation > =20 > Network Prefix Translation (NPTv6) [RFC6296] is an experimental > specification that provides a stateless one to one mapping between > internal addresses and external addresses. > =20 > In some very constrained situations(for example, in the sensors), = the > network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms = like > DHCP or full ND (Note: surely it needs SLAAC). If the network also > needs to connect to the outside, then there can be an NPTv6 gateway > which is not subject to extreme resource constraints. Especially = when > a lightweight isolated network needs to add Internet connectivity, > this is quite a straightforward and efficient way. > =20 > This document does not intend to encourage the ULA binding with = NPTv6 > model, since in [RFC5902] the IAB had already gave opinions on IPv6 > NAT; but this document considers it as an effective approach in = some > specific situations as described above.=94 > =20 > =20 > =20 > =20 --Apple-Mail=_E1C8B33B-122D-4874-BE7E-3F575E932D73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is a major improvement.

Owen

On Jun 2, 2014, at 8:38 PM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:

Hi Dear all,
 
Based on recent discussion, I propose some revised = texts as the following.
Please comment to see whether we = can achieve consensus on this issue.
 
Many thanks!
 
Revised texts in Section = 3.2.1:
=E2=80=9Co  Using Network Prefix = Translation
 
   = Network Prefix Translation (NPTv6) [RFC6296] is an = experimental
   specification that = provides a stateless one to one mapping = between
  internal addresses and external = addresses. [RFC6296] considers translating
ULA = prefixes into GUA prefixes as a use case. Although NPTv6 is not = exactly
the same with the = traditional stateful NAT/NAPT (which is discouraged = in
[RFC5902]), it also = introduces some similar additional complexity on = many
applications, which might = cause applications break.
 
So in general, this = document doesn=E2=80=99t encourage to use ULA+NPTv6 = (however,
some operational = considerations are provided below for the ones who insist = to
use ULA+NPTv6 for some = reason). This document considers ULA+GUA as a = better
approach to connect to = the global network when ULAs are expected to be = retained.
ULA+GUA is discussed in = detail in Section 3.2.2 below.=E2=80=9D
 
 
Original = texts:
=E2=80=9Co  Using Network Prefix = Translation
 
   = Network Prefix Translation (NPTv6) [RFC6296] is an = experimental
   specification that = provides a stateless one to one mapping = between
  internal addresses and external = addresses.
 
   = In some very constrained situations(for example, in the sensors), = the
   network needs ULA as the on-demand and = stable addressing which
   doesn't need much = code to support address assignment mechanisms = like
   DHCP or full ND (Note: surely it needs = SLAAC). If the network also
   needs to connect to = the outside, then there can be an NPTv6 = gateway
   which is not subject to extreme resource = constraints. Especially when
   a lightweight = isolated network needs to add Internet = connectivity,
   this is quite a = straightforward and efficient way.
 
   This document does not intend to = encourage the ULA binding with NPTv6
   = model, since in [RFC5902] the IAB had already gave opinions on = IPv6
   NAT; but this document considers it as = an effective approach in some
   specific situations = as described above.=E2=80=9D
 
 
 
 

= --Apple-Mail=_E1C8B33B-122D-4874-BE7E-3F575E932D73-- From nobody Tue Jun 3 00:24:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84D1A0119 for ; Tue, 3 Jun 2014 00:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 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.651, SPF_NEUTRAL=0.779] autolearn=ham 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 9uNMuZtdLevi for ; Tue, 3 Jun 2014 00:24:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563341A003A for ; Tue, 3 Jun 2014 00:24:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s537NYu4013674; Tue, 3 Jun 2014 08:23:35 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s537NYu4013674 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401780220; bh=y4cz78crfuFOxqW8st3BiFEvIxc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=FdDrEyNQHcLxWvjdaz3nG26hfdl4cpISnj5QKbmQC19TXuKyTEVQcrPsxbLCpchQy ljXg/+U9uttB24jFjgWBTsfKMKjdUOaTrWlv7RM+nHNptLHwCsHgYDoapMAgKYbKVe nLypVDn0jp5VEI2Etrl4Zdg/A/y2/6XYXBCXmhCc= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q528NY0546007479zX ret-id none; Tue, 03 Jun 2014 08:23:40 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s537NTV8017692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 08:23:32 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_3F6D0597-ED39-48F7-834B-43A9F069A921" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> Date: Tue, 3 Jun 2014 08:23:29 +0100 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> <02F13E3B-20C7-4383-ADDD-948951D23D0A@ecs.soton.ac.uk> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q528NY054600747900; tid=q528NY0546007479zX; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=8:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s537NYu4013674 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QDSIZDSsQyPsCA1uv5tWx2VOWVo Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] {Disarmed} Revised texts for ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:24:13 -0000 --Apple-Mail=_3F6D0597-ED39-48F7-834B-43A9F069A921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 With a slight tidy up of language that could be: "o Using Network Prefix Translation =20 Network Prefix Translation (NPTv6) [RFC6296] is an experimental specification that provides a stateless one to one mapping between internal addresses and external addresses. The specification considers = translating ULA prefixes into GUA prefixes as a use case. Although NPTv6 works = differently to traditional stateful NAT/NAPT (which is discouraged in [RFC5902]), it = also introduces some similar additional complexity to applications, which = might cause=20 applications to break. =20 Thus this document does not recommend the use of ULA+NPTv6. If an = operator does choose to use this approach, some operational considerations are = provided=20 below. Rather, this document considers ULA+GUA as a better approach to = connect=20 to the global network when ULAs are expected to be retained. The use of = ULA+GUA=20 is discussed in detail in Section 3.2.2 below.=94 =20 There=92s certain a case to remove the =93If an operator=94 sentence = altogether. I think there=92s also some NPTv6 text in 3.2.1 that needs updating = Bing. Tim On 3 Jun 2014, at 04:38, Liubing (Leo) wrote: > Hi Dear all, > =20 > Based on recent discussion, I propose some revised texts as the = following. > Please comment to see whether we can achieve consensus on this issue. > =20 > Many thanks! > =20 > Revised texts in Section 3.2.1: > =93o Using Network Prefix Translation > =20 > Network Prefix Translation (NPTv6) [RFC6296] is an experimental > specification that provides a stateless one to one mapping between > internal addresses and external addresses. [RFC6296] considers = translating > ULA prefixes into GUA prefixes as a use case. Although NPTv6 is not = exactly > the same with the traditional stateful NAT/NAPT (which is discouraged = in > [RFC5902]), it also introduces some similar additional complexity on = many > applications, which might cause applications break. > =20 > So in general, this document doesn=92t encourage to use ULA+NPTv6 = (however, > some operational considerations are provided below for the ones who = insist to > use ULA+NPTv6 for some reason). This document considers ULA+GUA as a = better > approach to connect to the global network when ULAs are expected to be = retained. > ULA+GUA is discussed in detail in Section 3.2.2 below.=94 > =20 > =20 > Original texts: > =93o Using Network Prefix Translation > =20 > Network Prefix Translation (NPTv6) [RFC6296] is an experimental > specification that provides a stateless one to one mapping between > internal addresses and external addresses. > =20 > In some very constrained situations(for example, in the sensors), = the > network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms = like > DHCP or full ND (Note: surely it needs SLAAC). If the network also > needs to connect to the outside, then there can be an NPTv6 gateway > which is not subject to extreme resource constraints. Especially = when > a lightweight isolated network needs to add Internet connectivity, > this is quite a straightforward and efficient way. > =20 > This document does not intend to encourage the ULA binding with = NPTv6 > model, since in [RFC5902] the IAB had already gave opinions on IPv6 > NAT; but this document considers it as an effective approach in = some > specific situations as described above.=94 > =20 > =20 > =20 > =20 --Apple-Mail=_3F6D0597-ED39-48F7-834B-43A9F069A921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 With a = slight tidy up of language that could be:

"o  Using Network Prefix Translation
 
   Network Prefix Translation (NPTv6) = [RFC6296] is an experimental
   specification that = provides a stateless one to one mapping = between
  internal addresses and external = addresses. The specification considers = translating
ULA prefixes into GUA = prefixes as a use case. Although NPTv6 works = differently
to traditional stateful = NAT/NAPT (which is discouraged in [RFC5902]), it also
introduces some similar additional complexity = to applications, which might cause 
applications to break.
 
Thus this document does = not recommend the use of ULA+NPTv6. If an = operator
does choose to use this = approach, some operational considerations are = provided 
below. Rather, this document considers ULA+GUA as a = better approach = to connect 
to the global network when ULAs are expected to be retained. = The use of ULA+GUA 
is discussed in detail in Section 3.2.2 = below.=E2=80=9D
 
There=E2=80=99s certain a case to = remove the =E2=80=9CIf an operator=E2=80=9D sentence = altogether.

I think there=E2=80=99s also some = NPTv6 text in 3.2.1 that needs updating Bing.

Tim

On 3 = Jun 2014, at 04:38, Liubing (Leo) <leo.liubing@huawei.com> = wrote:

Hi Dear all,

 

Based on recent discussion, I propose some revised = texts as the following.

Please comment to see whether we can achieve = consensus on this issue.

 

Many thanks!

 

Revised texts in Section = 3.2.1:

=E2=80=9Co  Using Network Prefix = Translation

 

   Network Prefix Translation (NPTv6) = [RFC6296] is an experimental

   specification that provides a = stateless one to one mapping between

  internal addresses and external = addresses. [RFC6296] considers translating

ULA prefixes into GUA prefixes as a use case. = Although NPTv6 is not exactly

the same with the traditional stateful NAT/NAPT = (which is discouraged in

[RFC5902]), it also introduces some similar = additional complexity on many

applications, which might cause applications = break.

 

So in general, this document doesn=E2=80=99t = encourage to use ULA+NPTv6 (however,

some operational considerations are provided below = for the ones who insist to

use ULA+NPTv6 for some reason). This document = considers ULA+GUA as a better

approach to connect to the global network when = ULAs are expected to be retained.

ULA+GUA is discussed in detail in Section 3.2.2 = below.=E2=80=9D

 

 

Original texts:

=E2=80=9Co  Using Network Prefix = Translation

 

   Network Prefix Translation (NPTv6) = [RFC6296] is an experimental

   specification that provides a = stateless one to one mapping between

  internal addresses and external = addresses.

 

   In some very constrained = situations(for example, in the sensors), the

   network needs ULA as the on-demand = and stable addressing which

   doesn't need much code to support = address assignment mechanisms like

   DHCP or full ND (Note: surely it = needs SLAAC). If the network also

   needs to connect to the outside, then = there can be an NPTv6 gateway

   which is not subject to extreme = resource constraints. Especially when

   a lightweight isolated network needs = to add Internet connectivity,

   this is quite a straightforward and = efficient way.

 

   This document does not intend to = encourage the ULA binding with NPTv6

   model, since in [RFC5902] the IAB had = already gave opinions on IPv6

   NAT; but this document considers it = as an effective approach in some

   specific situations as described = above.=E2=80=9D

 

 

 

 


= --Apple-Mail=_3F6D0597-ED39-48F7-834B-43A9F069A921-- From nobody Tue Jun 3 00:34:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94081A0117 for ; Tue, 3 Jun 2014 00:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham 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 03bfGfigZaQ7 for ; Tue, 3 Jun 2014 00:34:17 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 10B331A0043 for ; Tue, 3 Jun 2014 00:34:17 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7E6A618344E; Tue, 3 Jun 2014 09:34:06 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 7E6A618344E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401780846; bh=lKreGv6wYwvthRCoIdMcg1mQSjaZqrdx1LO7m6z+pEY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BR2Luqp4pba5C9n5UF6wNQvAFIIRpxfDSz2TVFuziwTDav/ja1Q6zkvur48Xwk70Q Kia7wLytk3mEOvI8LvYOHOihG0K+fcaNHHHDIWJnGt4JlV2EX+oiETreOvUL7fYjpf ak6xnSp5Nmj7eSx5iBwcDQgKLnOSh0Sc9A/eYqM8= Message-ID: <538D7A71.6070906@uclouvain.be> Date: Tue, 03 Jun 2014 09:34:09 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gert Doering , Brian E Carpenter References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> In-Reply-To: <20140602204730.GH46558@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 7E6A618344E.A36CE X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Cps1AmPQCR1oQZszPvguaCsfE6w Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:34:20 -0000 Gert, Brian, > > On Tue, Jun 03, 2014 at 08:42:55AM +1200, Brian E Carpenter wrote: >> On 02/06/2014 20:17, Gert Doering wrote: >> ... >>> OTOH, proper source address failover on "host" to source address B would >>> very nicely solve this whole category of connectivity issues - and (by >>> enforcing halfway symmetric return traffic via ISP B) would actually solve >>> it *better* than BGP routing, which might need manual fiddling with the >>> router to remove "ISP C" from the path. >> >> I know that shim6 isn't popular around here, but if you actually >> want to achieve this effect - for any transport protocol, and >> any application protocol, unmodified - run linshim6 at both ends. Having worked actively with both shim6 and Multipath TCP and supervised their implementation in the Linux kernel, I'm convinced that solving the problem in the transport layer is much better than in the network layer. Multipath TCP can deal with the case that you discuss and we'd be happy to perform tests with the Multipath TCP implementation in the Linux kernel (see http://www.multipath-tcp.org ) > I've heard very good results about failover tests with shim6 (much faster > convergence than BGP). shim6 would converge faster, but Multipath TCP is even better. It gives you many additional features that cannot be provided by shim6 alone. Multipath TCP gets continuous feedback about the quality of the Internet paths that it uses. It can detect failures and move traffic away from congested links. With a network-level solution like shim6 or LISP, one hides the changes in the path to the transport protocol. This is not a good idea because the congestion control scheme sends packets over paths that it cannot control. > I'm not convinced we particularily *need* it, though, as - as far as I > understood - shim6 will primarily serve to ensure session survivability, > while in most scenarios, sessions are so shortlived that "oh, ISP broken, > use other one" will be a matter of clicking reload in the browser... There are many short sessions, but most of the traffic is transported in very long TCP flows. Furthermore, the deployent of SPDY will increase the lifetime of the TCP connections. > Or will it also take care of selective non-reachability at session setup > ("something in the ISP A path to Z broken")? Multipath TCP could be tuned to do that. There are many use cases where Multipath TCP would provide lots of benefits for failover, traffic engineering, ... Feel free to bring this operator input to the mptcp mailing list Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Tue Jun 3 00:57:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B961A015B for ; Tue, 3 Jun 2014 00:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 PHN4Z6axmNLF for ; Tue, 3 Jun 2014 00:57:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E2C1A0114 for ; Tue, 3 Jun 2014 00:57:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT98580; Tue, 03 Jun 2014 07:56:57 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:56:13 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:56:56 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 15:56:51 +0800 From: "Liubing (Leo)" To: Tim Chown Thread-Topic: {Disarmed} Revised texts for ULA #3 NPTv6 Use Case Thread-Index: AQHPft1CJ+GB1E45A0C5tdmrqNI6GZtedZeAgACNzfA= Date: Tue, 3 Jun 2014 07:56:50 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B9ADB@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B99F5@nkgeml506-mbx.china.huawei.com> <02F13E3B-20C7-4383-ADDD-948951D23D0A@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B9ADBnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/l-RKUMrmkizxtwGhPXmUjk4ZTxI Cc: v6ops WG Subject: Re: [v6ops] {Disarmed} Revised texts for ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:57:08 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B9ADBnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSB0ZXh0IHJlZmluaW5nLg0KSeKAmWxsIHdv cmsgdGhyb3VnaCB0aGUgZG9jdW1lbnQgYW5kIG1ha2UgdGhlIE5QVHY2IGRlc2NyaXB0aW9uIGNv bnNpc3RlbnQgd2hlbiBkbyB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5n DQoNCkZyb206IFRpbSBDaG93biBbbWFpbHRvOnRqY0BlY3Muc290b24uYWMudWtdDQpTZW50OiBU dWVzZGF5LCBKdW5lIDAzLCAyMDE0IDM6MjMgUE0NClRvOiBMaXViaW5nIChMZW8pDQpDYzogdjZv cHMgV0c7IHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTG9yZW56byBDb2xpdHRpOyBPd2Vu IERlTG9uZzsgVGVkIExlbW9uOyBCcmlhbiBFIENhcnBlbnRlcjsgTGVlIEhvd2FyZA0KU3ViamVj dDogUmU6IHtEaXNhcm1lZH0gUmV2aXNlZCB0ZXh0cyBmb3IgVUxBICMzIE5QVHY2IFVzZSBDYXNl DQoNCldpdGggYSBzbGlnaHQgdGlkeSB1cCBvZiBsYW5ndWFnZSB0aGF0IGNvdWxkIGJlOg0KDQoi byAgVXNpbmcgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24NCg0KICAgTmV0d29yayBQcmVmaXgg VHJhbnNsYXRpb24gKE5QVHY2KSBbUkZDNjI5Nl0gaXMgYW4gZXhwZXJpbWVudGFsDQogICBzcGVj aWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBzdGF0ZWxlc3Mgb25lIHRvIG9uZSBtYXBwaW5nIGJl dHdlZW4NCiAgaW50ZXJuYWwgYWRkcmVzc2VzIGFuZCBleHRlcm5hbCBhZGRyZXNzZXMuIFRoZSBz cGVjaWZpY2F0aW9uIGNvbnNpZGVycyB0cmFuc2xhdGluZw0KVUxBIHByZWZpeGVzIGludG8gR1VB IHByZWZpeGVzIGFzIGEgdXNlIGNhc2UuIEFsdGhvdWdoIE5QVHY2IHdvcmtzIGRpZmZlcmVudGx5 DQp0byB0cmFkaXRpb25hbCBzdGF0ZWZ1bCBOQVQvTkFQVCAod2hpY2ggaXMgZGlzY291cmFnZWQg aW4gW1JGQzU5MDJdKSwgaXQgYWxzbw0KaW50cm9kdWNlcyBzb21lIHNpbWlsYXIgYWRkaXRpb25h bCBjb21wbGV4aXR5IHRvIGFwcGxpY2F0aW9ucywgd2hpY2ggbWlnaHQgY2F1c2UNCmFwcGxpY2F0 aW9ucyB0byBicmVhay4NCg0KVGh1cyB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHJlY29tbWVuZCB0 aGUgdXNlIG9mIFVMQStOUFR2Ni4gSWYgYW4gb3BlcmF0b3INCmRvZXMgY2hvb3NlIHRvIHVzZSB0 aGlzIGFwcHJvYWNoLCBzb21lIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGFyZSBwcm92aWRl ZA0KYmVsb3cuIFJhdGhlciwgdGhpcyBkb2N1bWVudCBjb25zaWRlcnMgVUxBK0dVQSBhcyBhIGJl dHRlciBhcHByb2FjaCB0byBjb25uZWN0DQp0byB0aGUgZ2xvYmFsIG5ldHdvcmsgd2hlbiBVTEFz IGFyZSBleHBlY3RlZCB0byBiZSByZXRhaW5lZC4gVGhlIHVzZSBvZiBVTEErR1VBDQppcyBkaXNj dXNzZWQgaW4gZGV0YWlsIGluIFNlY3Rpb24gMy4yLjIgYmVsb3cu4oCdDQoNClRoZXJl4oCZcyBj ZXJ0YWluIGEgY2FzZSB0byByZW1vdmUgdGhlIOKAnElmIGFuIG9wZXJhdG9y4oCdIHNlbnRlbmNl IGFsdG9nZXRoZXIuDQoNCkkgdGhpbmsgdGhlcmXigJlzIGFsc28gc29tZSBOUFR2NiB0ZXh0IGlu IDMuMi4xIHRoYXQgbmVlZHMgdXBkYXRpbmcgQmluZy4NCg0KVGltDQoNCk9uIDMgSnVuIDIwMTQs IGF0IDA0OjM4LCBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPG1haWx0bzps ZW8ubGl1YmluZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQoNCg0KSGkgRGVhciBhbGwsDQoNCkJhc2Vk IG9uIHJlY2VudCBkaXNjdXNzaW9uLCBJIHByb3Bvc2Ugc29tZSByZXZpc2VkIHRleHRzIGFzIHRo ZSBmb2xsb3dpbmcuDQpQbGVhc2UgY29tbWVudCB0byBzZWUgd2hldGhlciB3ZSBjYW4gYWNoaWV2 ZSBjb25zZW5zdXMgb24gdGhpcyBpc3N1ZS4NCg0KTWFueSB0aGFua3MhDQoNClJldmlzZWQgdGV4 dHMgaW4gU2VjdGlvbiAzLjIuMToNCuKAnG8gIFVzaW5nIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0 aW9uDQoNCiAgIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFR2NikgW1JGQzYyOTZdIGlz IGFuIGV4cGVyaW1lbnRhbA0KICAgc3BlY2lmaWNhdGlvbiB0aGF0IHByb3ZpZGVzIGEgc3RhdGVs ZXNzIG9uZSB0byBvbmUgbWFwcGluZyBiZXR3ZWVuDQogIGludGVybmFsIGFkZHJlc3NlcyBhbmQg ZXh0ZXJuYWwgYWRkcmVzc2VzLiBbUkZDNjI5Nl0gY29uc2lkZXJzIHRyYW5zbGF0aW5nDQpVTEEg cHJlZml4ZXMgaW50byBHVUEgcHJlZml4ZXMgYXMgYSB1c2UgY2FzZS4gQWx0aG91Z2ggTlBUdjYg aXMgbm90IGV4YWN0bHkNCnRoZSBzYW1lIHdpdGggdGhlIHRyYWRpdGlvbmFsIHN0YXRlZnVsIE5B VC9OQVBUICh3aGljaCBpcyBkaXNjb3VyYWdlZCBpbg0KW1JGQzU5MDJdKSwgaXQgYWxzbyBpbnRy b2R1Y2VzIHNvbWUgc2ltaWxhciBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgb24gbWFueQ0KYXBwbGlj YXRpb25zLCB3aGljaCBtaWdodCBjYXVzZSBhcHBsaWNhdGlvbnMgYnJlYWsuDQoNClNvIGluIGdl bmVyYWwsIHRoaXMgZG9jdW1lbnQgZG9lc27igJl0IGVuY291cmFnZSB0byB1c2UgVUxBK05QVHY2 IChob3dldmVyLA0Kc29tZSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyBhcmUgcHJvdmlkZWQg YmVsb3cgZm9yIHRoZSBvbmVzIHdobyBpbnNpc3QgdG8NCnVzZSBVTEErTlBUdjYgZm9yIHNvbWUg cmVhc29uKS4gVGhpcyBkb2N1bWVudCBjb25zaWRlcnMgVUxBK0dVQSBhcyBhIGJldHRlcg0KYXBw cm9hY2ggdG8gY29ubmVjdCB0byB0aGUgZ2xvYmFsIG5ldHdvcmsgd2hlbiBVTEFzIGFyZSBleHBl Y3RlZCB0byBiZSByZXRhaW5lZC4NClVMQStHVUEgaXMgZGlzY3Vzc2VkIGluIGRldGFpbCBpbiBT ZWN0aW9uIDMuMi4yIGJlbG93LuKAnQ0KDQoNCk9yaWdpbmFsIHRleHRzOg0K4oCcbyAgVXNpbmcg TmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24NCg0KICAgTmV0d29yayBQcmVmaXggVHJhbnNsYXRp b24gKE5QVHY2KSBbUkZDNjI5Nl0gaXMgYW4gZXhwZXJpbWVudGFsDQogICBzcGVjaWZpY2F0aW9u IHRoYXQgcHJvdmlkZXMgYSBzdGF0ZWxlc3Mgb25lIHRvIG9uZSBtYXBwaW5nIGJldHdlZW4NCiAg aW50ZXJuYWwgYWRkcmVzc2VzIGFuZCBleHRlcm5hbCBhZGRyZXNzZXMuDQoNCiAgIEluIHNvbWUg dmVyeSBjb25zdHJhaW5lZCBzaXR1YXRpb25zKGZvciBleGFtcGxlLCBpbiB0aGUgc2Vuc29ycyks IHRoZQ0KICAgbmV0d29yayBuZWVkcyBVTEEgYXMgdGhlIG9uLWRlbWFuZCBhbmQgc3RhYmxlIGFk ZHJlc3Npbmcgd2hpY2gNCiAgIGRvZXNuJ3QgbmVlZCBtdWNoIGNvZGUgdG8gc3VwcG9ydCBhZGRy ZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtcyBsaWtlDQogICBESENQIG9yIGZ1bGwgTkQgKE5vdGU6 IHN1cmVseSBpdCBuZWVkcyBTTEFBQykuIElmIHRoZSBuZXR3b3JrIGFsc28NCiAgIG5lZWRzIHRv IGNvbm5lY3QgdG8gdGhlIG91dHNpZGUsIHRoZW4gdGhlcmUgY2FuIGJlIGFuIE5QVHY2IGdhdGV3 YXkNCiAgIHdoaWNoIGlzIG5vdCBzdWJqZWN0IHRvIGV4dHJlbWUgcmVzb3VyY2UgY29uc3RyYWlu dHMuIEVzcGVjaWFsbHkgd2hlbg0KICAgYSBsaWdodHdlaWdodCBpc29sYXRlZCBuZXR3b3JrIG5l ZWRzIHRvIGFkZCBJbnRlcm5ldCBjb25uZWN0aXZpdHksDQogICB0aGlzIGlzIHF1aXRlIGEgc3Ry YWlnaHRmb3J3YXJkIGFuZCBlZmZpY2llbnQgd2F5Lg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMg bm90IGludGVuZCB0byBlbmNvdXJhZ2UgdGhlIFVMQSBiaW5kaW5nIHdpdGggTlBUdjYNCiAgIG1v ZGVsLCBzaW5jZSBpbiBbUkZDNTkwMl0gdGhlIElBQiBoYWQgYWxyZWFkeSBnYXZlIG9waW5pb25z IG9uIElQdjYNCiAgIE5BVDsgYnV0IHRoaXMgZG9jdW1lbnQgY29uc2lkZXJzIGl0IGFzIGFuIGVm ZmVjdGl2ZSBhcHByb2FjaCBpbiBzb21lDQogICBzcGVjaWZpYyBzaXR1YXRpb25zIGFzIGRlc2Ny aWJlZCBhYm92ZS7igJ0NCg0KDQoNCg0KDQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B9ADBnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpI LUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFRpbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmtzIGEgbG90IGZvciB0aGUgdGV4dCByZWZpbmluZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlsbCB3b3JrIHRocm91Z2ggdGhl IGRvY3VtZW50IGFuZCBtYWtlIHRoZSBOUFR2NiBkZXNjcmlwdGlvbiBjb25zaXN0ZW50IHdoZW4g ZG8gdGhlIG5leHQgdmVyc2lvbi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGltIENob3duIFttYWlsdG86 dGpjQGVjcy5zb3Rvbi5hYy51a10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDAz LCAyMDE0IDM6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk8YnI+DQo8Yj5DYzo8 L2I+IHY2b3BzIFdHOyB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IExvcmVuem8gQ29saXR0 aTsgT3dlbiBEZUxvbmc7IFRlZCBMZW1vbjsgQnJpYW4gRSBDYXJwZW50ZXI7IExlZSBIb3dhcmQ8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHtEaXNhcm1lZH0gUmV2aXNlZCB0ZXh0cyBmb3IgVUxB ICMzIE5QVHY2IFVzZSBDYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2l0 aCBhIHNsaWdodCB0aWR5IHVwIG9mIGxhbmd1YWdlIHRoYXQgY291bGQgYmU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+byZuYnNwOyBVc2luZyBO ZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBOZXR3b3JrIFByZWZpeCBUcmFuc2xh dGlvbiAoTlBUdjYpIFtSRkM2Mjk2XSBpcyBhbiBleHBlcmltZW50YWw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gdGhhdCBwcm92aWRlcyBhIHN0 YXRlbGVzcyBvbmUgdG8gb25lIG1hcHBpbmcgYmV0d2Vlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDtpbnRlcm5hbCBhZGRyZXNzZXMgYW5kIGV4dGVybmFsIGFkZHJlc3Nl cy4gVGhlIHNwZWNpZmljYXRpb24gY29uc2lkZXJzIHRyYW5zbGF0aW5nPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVMQSBwcmVmaXhlcyBpbnRv IEdVQSBwcmVmaXhlcyBhcyBhIHVzZSBjYXNlLiBBbHRob3VnaCBOUFR2NiB3b3JrcyBkaWZmZXJl bnRseTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij50byB0cmFkaXRpb25hbCBzdGF0ZWZ1bCBOQVQvTkFQVCAod2hpY2ggaXMgZGlzY291cmFnZWQg aW4mbmJzcDtbUkZDNTkwMl0pLCBpdCBhbHNvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmludHJvZHVjZXMgc29tZSBzaW1pbGFyIGFkZGl0aW9u YWwgY29tcGxleGl0eSB0byZuYnNwO2FwcGxpY2F0aW9ucywgd2hpY2ggbWlnaHQgY2F1c2UmbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ YXBwbGljYXRpb25zIHRvIGJyZWFrLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh1cyB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHJlY29t bWVuZCB0aGUgdXNlIG9mIFVMQSYjNDM7TlBUdjYuIElmIGFuIG9wZXJhdG9yPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZG9lcyBjaG9vc2UgdG8g dXNlIHRoaXMgYXBwcm9hY2gsJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c29tZQ0KIG9wZXJhdGlvbmFsIGNvbnNpZGVy YXRpb25zIGFyZSBwcm92aWRlZCZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iZWxvdy4gUmF0aGVyLCB0aGlzIGRvY3VtZW50IGNvbnNp ZGVycyBVTEEmIzQzO0dVQSBhcyBhIGJldHRlciZuYnNwO2FwcHJvYWNoIHRvIGNvbm5lY3QmbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ dG8gdGhlIGdsb2JhbCBuZXR3b3JrIHdoZW4gVUxBcyBhcmUgZXhwZWN0ZWQgdG8gYmUgcmV0YWlu ZWQuIFRoZSB1c2Ugb2YmbmJzcDtVTEEmIzQzO0dVQSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5pcyBkaXNjdXNzZWQgaW4gZGV0YWls IGluIFNlY3Rpb24gMy4yLjIgYmVsb3cu4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZeKAmXMgY2VydGFpbiBhIGNhc2Ug dG8gcmVtb3ZlIHRoZSDigJxJZiBhbiBvcGVyYXRvcuKAnSBzZW50ZW5jZSBhbHRvZ2V0aGVyLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0 aGluayB0aGVyZeKAmXMgYWxzbyBzb21lIE5QVHY2IHRleHQgaW4gMy4yLjEgdGhhdCBuZWVkcyB1 cGRhdGluZyBCaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGltPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAzIEp1biAyMDE0LCBh dCAwNDozOCwgTGl1YmluZyAoTGVvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlby5saXViaW5nQGh1 YXdlaS5jb20iPmxlby5saXViaW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IaSBEZWFyIGFsbCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJh c2VkIG9uIHJlY2VudCBkaXNjdXNzaW9uLCBJIHByb3Bvc2Ugc29tZSByZXZpc2VkIHRleHRzIGFz IHRoZSBmb2xsb3dpbmcuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGNvbW1lbnQgdG8gc2VlIHdoZXRo ZXIgd2UgY2FuIGFjaGlldmUgY29uc2Vuc3VzIG9uIHRoaXMgaXNzdWUuDQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hbnkgdGhhbmtzITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmV2aXNlZCB0ZXh0cyBpbiBTZWN0aW9uIDMuMi4xOjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxvJm5i c3A7IFVzaW5nIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24gKE5QVHY2 KSBbUkZDNjI5Nl0gaXMgYW4gZXhwZXJpbWVudGFsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBz cGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBzdGF0ZWxlc3Mgb25lIHRvIG9uZSBtYXBwaW5n IGJldHdlZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7aW50ZXJuYWwgYWRkcmVzc2VzIGFuZCBl eHRlcm5hbCBhZGRyZXNzZXMuIFtSRkM2Mjk2XSBjb25zaWRlcnMgdHJhbnNsYXRpbmcNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5VTEEgcHJlZml4ZXMgaW50byBHVUEg cHJlZml4ZXMgYXMgYSB1c2UgY2FzZS4gQWx0aG91Z2ggTlBUdjYgaXMgbm90IGV4YWN0bHk8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHNhbWUgd2l0aCB0aGUgdHJh ZGl0aW9uYWwgc3RhdGVmdWwgTkFUL05BUFQgKHdoaWNoIGlzIGRpc2NvdXJhZ2VkIGluPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltSRkM1OTAyXSksIGl0IGFsc28gaW50 cm9kdWNlcyBzb21lIHNpbWlsYXIgYWRkaXRpb25hbCBjb21wbGV4aXR5IG9uIG1hbnkNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hcHBsaWNhdGlvbnMsIHdoaWNoIG1p Z2h0IGNhdXNlIGFwcGxpY2F0aW9ucyBicmVhay48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvIGluIGdlbmVyYWwsIHRoaXMgZG9jdW1lbnQgZG9lc27igJl0IGVuY291cmFnZSB0byB1c2Ug VUxBJiM0MztOUFR2NiAoaG93ZXZlciwNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50 OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5zb21lIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGFyZSBwcm92aWRlZCBiZWxv dyBmb3IgdGhlIG9uZXMgd2hvIGluc2lzdCB0bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj51c2UgVUxBJiM0MztOUFR2NiBmb3Igc29tZSByZWFzb24pLiBUaGlzIGRvY3Vt ZW50IGNvbnNpZGVycyBVTEEmIzQzO0dVQSBhcyBhIGJldHRlcjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5hcHByb2FjaCB0byBjb25uZWN0IHRvIHRoZSBnbG9iYWwgbmV0 d29yayB3aGVuIFVMQXMgYXJlIGV4cGVjdGVkIHRvIGJlIHJldGFpbmVkLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5VTEEmIzQzO0dVQSBpcyBkaXNjdXNzZWQgaW4gZGV0 YWlsIGluIFNlY3Rpb24gMy4yLjIgYmVsb3cu4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3JpZ2luYWwgdGV4dHM6PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnG8m bmJzcDsgVXNpbmcgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb248L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBU djYpIFtSRkM2Mjk2XSBpcyBhbiBleHBlcmltZW50YWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IHNwZWNpZmljYXRpb24gdGhhdCBwcm92aWRlcyBhIHN0YXRlbGVzcyBvbmUgdG8gb25lIG1hcHBp bmcgYmV0d2Vlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDtpbnRlcm5hbCBhZGRyZXNzZXMgYW5k IGV4dGVybmFsIGFkZHJlc3Nlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBJbiBzb21lIHZlcnkgY29uc3RyYWluZWQgc2l0dWF0aW9ucyhmb3IgZXhhbXBsZSwg aW4gdGhlIHNlbnNvcnMpLCB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgbmVl ZHMgVUxBIGFzIHRoZSBvbi1kZW1hbmQgYW5kIHN0YWJsZSBhZGRyZXNzaW5nIHdoaWNoPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBkb2Vzbid0IG5lZWQgbXVjaCBjb2RlIHRvIHN1cHBvcnQgYWRk cmVzcyBhc3NpZ25tZW50IG1lY2hhbmlzbXMgbGlrZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg REhDUCBvciBmdWxsIE5EIChOb3RlOiBzdXJlbHkgaXQgbmVlZHMgU0xBQUMpLiBJZiB0aGUgbmV0 d29yayBhbHNvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBuZWVkcyB0byBjb25uZWN0IHRvIHRo ZSBvdXRzaWRlLCB0aGVuIHRoZXJlIGNhbiBiZSBhbiBOUFR2NiBnYXRld2F5PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyB3aGljaCBpcyBub3Qgc3ViamVjdCB0byBleHRyZW1lIHJlc291cmNlIGNv bnN0cmFpbnRzLiBFc3BlY2lhbGx5IHdoZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGEgbGln aHR3ZWlnaHQgaXNvbGF0ZWQgbmV0d29yayBuZWVkcyB0byBhZGQgSW50ZXJuZXQgY29ubmVjdGl2 aXR5LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhpcyBpcyBxdWl0ZSBhIHN0cmFpZ2h0Zm9y d2FyZCBhbmQgZWZmaWNpZW50IHdheS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludGVuZCB0byBlbmNvdXJhZ2UgdGhl IFVMQSBiaW5kaW5nIHdpdGggTlBUdjY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1vZGVsLCBz aW5jZSBpbiBbUkZDNTkwMl0gdGhlIElBQiBoYWQgYWxyZWFkeSBnYXZlIG9waW5pb25zIG9uIElQ djY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IE5BVDsgYnV0IHRoaXMgZG9jdW1lbnQgY29uc2lk ZXJzIGl0IGFzIGFuIGVmZmVjdGl2ZSBhcHByb2FjaCBpbiBzb21lPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBzcGVjaWZpYyBzaXR1YXRpb25zIGFzIGRlc2NyaWJlZCBhYm92ZS7igJ08L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B9ADBnkgeml506mbxchi_-- From nobody Tue Jun 3 06:05:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D0C1A0263 for ; Tue, 3 Jun 2014 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 QFL4Tnb32G8h for ; Tue, 3 Jun 2014 06:05:31 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05F01A0236 for ; Tue, 3 Jun 2014 06:05:30 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 99C0760A8F for ; Tue, 3 Jun 2014 15:05:22 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5B2DD60182 for ; Tue, 3 Jun 2014 15:05:22 +0200 (CEST) Received: (qmail 62248 invoked by uid 1007); 3 Jun 2014 15:05:22 +0200 Date: Tue, 3 Jun 2014 15:05:22 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20140603130522.GQ46558@Space.Net> References: <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> <20140602233943.47DF017375B9@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602233943.47DF017375B9@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lsnibZx0NeI67QpjY-p01WDEWq0 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:05:34 -0000 Hi, On Tue, Jun 03, 2014 at 09:39:43AM +1000, Mark Andrews wrote: > Extending HE to do multiple source addresses (one per prefix) within > a adddress family will give pretty much the same robustness as > running BGP at the cost of some embryonic connections if the initial > attempt doesn't work. It will give you *better* robustness than BGP, because BGP can not send your packets around dataplane failures where control plane still advertises reachability. I find this very important to point out, again and again :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jun 3 06:25:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036BC1A026A for ; Tue, 3 Jun 2014 06:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham 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 eZM1vSjyLgiv for ; Tue, 3 Jun 2014 06:25:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CDDEA1A01F6 for ; Tue, 3 Jun 2014 06:25:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Wrohy-0000DxC; Tue, 3 Jun 2014 15:24:54 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> <20140602233943.47DF017375B9@rock.dv.isc.org> <20140603130522.GQ46558@Space.Net> In-reply-to: Your message of "Tue, 3 Jun 2014 15:05:22 +0200 ." <20140603130522.GQ46558@Space.Net> Date: Tue, 03 Jun 2014 15:24:53 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8xJglkmgFeCsgKWp4BvUn6041Fs Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:25:03 -0000 In your letter dated Tue, 3 Jun 2014 15:05:22 +0200 you wrote: >On Tue, Jun 03, 2014 at 09:39:43AM +1000, Mark Andrews wrote: >> Extending HE to do multiple source addresses (one per prefix) within >> a adddress family will give pretty much the same robustness as >> running BGP at the cost of some embryonic connections if the initial >> attempt doesn't work. > >It will give you *better* robustness than BGP, because BGP can not send >your packets around dataplane failures where control plane still advertises >reachability. > >I find this very important to point out, again and again :-) The good news is that in a network that provides hosts with just one prefix this feature should be harmless. But I'm not holding my breath for getting any kind of wide spread implementation of such a feature. From nobody Tue Jun 3 13:17:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F891A0360 for ; Tue, 3 Jun 2014 13:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 j-8Gf5pmiTqd for ; Tue, 3 Jun 2014 13:17:18 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1BE1A036A for ; Tue, 3 Jun 2014 13:16:51 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id p10so5075464pdj.35 for ; Tue, 03 Jun 2014 13:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SkyEpErs8aj9hhmXQ1QIrBngpOyE+5poP+8Dx4oPo7k=; b=OHT/ixt0Xh2Nl3MlBven/W0wcI7OYPbOe2i0cMXHYEaInyhvmj7KkODSUSAVue1bNe 0nocweQ6jc98o+XvMl4+1zyEEJsVCKXEAX5Ce2v7lmNb0R9XsJxOUTvMXSpeNWx17MZL 7+bzIrgEDwx2AekpchpPBSt3lcUbHucoCOn5DjySzYrr7kyk4jJs7Ur4OU8QN7XTFiAl 8AGkhC2COj4jsKp5Ydq7sYjl6QRM1o/jOjGw/wrEi5xPGBc7hkUPp+0pk86qHWIVJmFs bLG9j4QsXTvwbyxy8ApX5MCKLBM048sdJNCAKhs3XkoPl6UKP5Mtui1ARzUcJ6t6BCTX KJGA== X-Received: by 10.68.164.67 with SMTP id yo3mr55000273pbb.104.1401826605645; Tue, 03 Jun 2014 13:16:45 -0700 (PDT) Received: from [192.168.178.23] (17.200.69.111.dynamic.snap.net.nz. [111.69.200.17]) by mx.google.com with ESMTPSA id fe2sm779136pbc.68.2014.06.03.13.16.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 13:16:45 -0700 (PDT) Message-ID: <538E2D2E.4020903@gmail.com> Date: Wed, 04 Jun 2014 08:16:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> In-Reply-To: <538D7A71.6070906@uclouvain.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dOIjLi9Vi06HZ8RE1En1Jeahs7g Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:17:30 -0000 Olivier, On 03/06/2014 19:34, Olivier Bonaventure wrote: > Gert, Brian, >> >> On Tue, Jun 03, 2014 at 08:42:55AM +1200, Brian E Carpenter wrote: >>> On 02/06/2014 20:17, Gert Doering wrote: >>> ... >>>> OTOH, proper source address failover on "host" to source address B >>>> would >>>> very nicely solve this whole category of connectivity issues - and (by >>>> enforcing halfway symmetric return traffic via ISP B) would actually >>>> solve >>>> it *better* than BGP routing, which might need manual fiddling with the >>>> router to remove "ISP C" from the path. >>> >>> I know that shim6 isn't popular around here, but if you actually >>> want to achieve this effect - for any transport protocol, and >>> any application protocol, unmodified - run linshim6 at both ends. > > Having worked actively with both shim6 and Multipath TCP and supervised > their implementation in the Linux kernel, I'm convinced that solving the > problem in the transport layer is much better than in the network layer. > Multipath TCP can deal with the case that you discuss and we'd be happy > to perform tests with the Multipath TCP implementation in the Linux > kernel (see http://www.multipath-tcp.org ) But, of course, the great advantage of shim6, as you know, is that it applies to all transport layers. MPTCP is very elegant but only works for TCP applications. So we have a bit of a dilemma in this area. It's not a v6ops issue though. Brian > > >> I've heard very good results about failover tests with shim6 (much faster >> convergence than BGP). > > shim6 would converge faster, but Multipath TCP is even better. It gives > you many additional features that cannot be provided by shim6 alone. > Multipath TCP gets continuous feedback about the quality of the Internet > paths that it uses. It can detect failures and move traffic away from > congested links. With a network-level solution like shim6 or LISP, one > hides the changes in the path to the transport protocol. This is not a > good idea because the congestion control scheme sends packets over paths > that it cannot control. > > >> I'm not convinced we particularily *need* it, though, as - as far as I >> understood - shim6 will primarily serve to ensure session survivability, >> while in most scenarios, sessions are so shortlived that "oh, ISP broken, >> use other one" will be a matter of clicking reload in the browser... > > There are many short sessions, but most of the traffic is transported in > very long TCP flows. Furthermore, the deployent of SPDY will increase > the lifetime of the TCP connections. > >> Or will it also take care of selective non-reachability at session setup >> ("something in the ISP A path to Z broken")? > > Multipath TCP could be tuned to do that. There are many use cases where > Multipath TCP would provide lots of benefits for failover, traffic > engineering, ... Feel free to bring this operator input to the mptcp > mailing list > > > > Olivier > > From nobody Tue Jun 3 13:25:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4201A0378 for ; Tue, 3 Jun 2014 13:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 K_EmWP-lBCpT for ; Tue, 3 Jun 2014 13:24:58 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAA41A0373 for ; Tue, 3 Jun 2014 13:24:58 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wn1so6640199obc.13 for ; Tue, 03 Jun 2014 13:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YiDnSkjb+zXsZdJDx3ph7LJ7YvgRnDNxk9gq/9jRgog=; b=0boscl7y4oQgHa090Fz7wyd0g30bG4xfyGABOjsXTXq5AAM71L0uzJUEyj5mHfHLvK BfjFVAs3Kjf6bsuEV6rfZIvwXsBVJ0Zz1dYyQOoSS6qxBYKyGeQB6uWs96XaSxfQKqEZ F5OmatGVxsPm/CqAZ/P+tZZLXTtzh6o8UBOOjD1KbpBdd+OQzU2XlcdoDp0JKgFLqAGp 4n3EdUh/RcqtQajn9w5UO97RV9Arn8JAYsL8rRRNxrGvcTt+4ouBwM9WeGt4XfnZtRX1 OvwOmedF88U4A59UmDdA2cEErdSJifwygjcOUCSWYqDSGfO70dXbXE0AotFDE3dn6u9U VEqw== X-Received: by 10.60.115.202 with SMTP id jq10mr50782598oeb.0.1401827092332; Tue, 03 Jun 2014 13:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.183.8.7 with HTTP; Tue, 3 Jun 2014 13:24:32 -0700 (PDT) In-Reply-To: <538E2D2E.4020903@gmail.com> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com> From: Scott Brim Date: Tue, 3 Jun 2014 16:24:32 -0400 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8b1ZXzvS4tVtn0fNe06vjV5irlk Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:25:00 -0000 On Tue, Jun 3, 2014 at 4:16 PM, Brian E Carpenter wrote: >> Having worked actively with both shim6 and Multipath TCP and supervised >> their implementation in the Linux kernel, I'm convinced that solving the >> problem in the transport layer is much better than in the network layer. >> Multipath TCP can deal with the case that you discuss and we'd be happy >> to perform tests with the Multipath TCP implementation in the Linux >> kernel (see http://www.multipath-tcp.org ) > > But, of course, the great advantage of shim6, as you know, is that it > applies to all transport layers. MPTCP is very elegant but only works > for TCP applications. So we have a bit of a dilemma in this area. > It's not a v6ops issue though. And the disadvantage of shim6 is that it's gone, sorry Brian but it's not coming back. In the meantime, while MPTCP itself has little deployment, the framework in it and SCTP are strongly present in HTTP 2.0, RTCWEB, and web browser space in general, and there is refreshing work being done on transport layer improvements. If and when multipathing proves its usefulness (imho the jury is still out, eg. when you have paths with highly different quality) there will be several convenient paths for its deployment. Scott From nobody Tue Jun 3 13:40:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07321A0344 for ; Tue, 3 Jun 2014 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 HBnzAjw2x7jJ for ; Tue, 3 Jun 2014 13:40:53 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE681A0271 for ; Tue, 3 Jun 2014 13:40:53 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id um1so5962986pbc.32 for ; Tue, 03 Jun 2014 13:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OCF8bOLn1gVMF3M907jeFn2lHmNzlGeDB9nQiHxmJQs=; b=Oju77yHIArnltOVkE2710bfFUvEmc475rmWcBm9St+rhhajca5wYHQkVWwpZEcWqjl 7fnZJKxbl/5jK/k0wacEGKmfJhRToejlSMy1BgWenW/dFKhR/B6xxWKyL3j0llqq+h3g d7Wd3mazJMAG5Q5yVP1F8Fero7+lCkOkrgSRHqwr1EdGfy0ontEaPujmM3bNRz1hJOkl +xVAyFxRIpWIKXzOk9omipTZaDjN1ypzaygs+rrd1gotKcYcQZJpAhTbFH233aq3da8F ZG7acDkYYdR5UV73yPt3SI7tOEv/EoLAGgzy+r/fbXn0og6pbpYH/05zyJ08CXOn3ZSe Jm8g== X-Received: by 10.68.237.67 with SMTP id va3mr55215204pbc.19.1401828048035; Tue, 03 Jun 2014 13:40:48 -0700 (PDT) Received: from [192.168.178.23] (17.200.69.111.dynamic.snap.net.nz. [111.69.200.17]) by mx.google.com with ESMTPSA id vf9sm909735pbc.94.2014.06.03.13.40.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 13:40:47 -0700 (PDT) Message-ID: <538E32D0.9050005@gmail.com> Date: Wed, 04 Jun 2014 08:40:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qyl5GUCM4q41x9QzHMsqFLe7iXo Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:40:56 -0000 On 04/06/2014 08:24, Scott Brim wrote: > On Tue, Jun 3, 2014 at 4:16 PM, Brian E Carpenter > wrote: >>> Having worked actively with both shim6 and Multipath TCP and supervised >>> their implementation in the Linux kernel, I'm convinced that solving the >>> problem in the transport layer is much better than in the network layer. >>> Multipath TCP can deal with the case that you discuss and we'd be happy >>> to perform tests with the Multipath TCP implementation in the Linux >>> kernel (see http://www.multipath-tcp.org ) >> But, of course, the great advantage of shim6, as you know, is that it >> applies to all transport layers. MPTCP is very elegant but only works >> for TCP applications. So we have a bit of a dilemma in this area. >> It's not a v6ops issue though. > > And the disadvantage of shim6 is that it's gone, sorry Brian but it's > not coming back. In the meantime, while MPTCP itself has little > deployment, the framework in it and SCTP are strongly present in HTTP > 2.0, RTCWEB, and web browser space in general, and there is refreshing > work being done on transport layer improvements. If and when > multipathing proves its usefulness (imho the jury is still out, eg. > when you have paths with highly different quality) there will be > several convenient paths for its deployment. My point is that there are useful learnings in shim6 as well as in MPTCP and SCTP. However, it will be very sad if we have to re-solve these problems in every application suite rather than solving them once in the stack. Brian From nobody Tue Jun 3 14:27:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471BD1A037B for ; Tue, 3 Jun 2014 14:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JT0kgVH1q-Ks for ; Tue, 3 Jun 2014 14:27:43 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B19C1A0375 for ; Tue, 3 Jun 2014 14:27:43 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j17so6931378oag.29 for ; Tue, 03 Jun 2014 14:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5cgPq4tMUeE9rC2+m4xgddkSJ7ww6dBZJ7f2+b2e6A4=; b=lXXhIW37EKFmoZjrTbTCvXUFmrPLZkxaK89IIfa79woU/flpvSQzljuX1daN2Mgc3t 4lltieJfvuXoPGIDH4VtsY7LFXIaptdVhsKIk/2krwt5tsYvKobSjH+hOuQklD3MALt8 bRDrY8lJWS73lgJDtwULtcDovJTtvdmikXrk12Q5UK36XE1+ivlPxNhtT+3sRrauNSHW TPz+KceXH+UJCeJtds/8nGsrOBB8Afn8wEjS/JHX+lKlevli6JD4bC8kiT1JsTay52Or RW831/A6voUDZMcblyfcLRFM8ib/tJBE6T1BPb/KInbdcpBjhb7ivGpaxyX2jK7NHhyT //Mw== X-Received: by 10.182.236.229 with SMTP id ux5mr51444383obc.12.1401830857075; Tue, 03 Jun 2014 14:27:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.183.8.7 with HTTP; Tue, 3 Jun 2014 14:27:17 -0700 (PDT) In-Reply-To: <538E32D0.9050005@gmail.com> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com> <538E32D0.9050005@gmail.com> From: Scott Brim Date: Tue, 3 Jun 2014 17:27:17 -0400 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZVNvWpyMWrRw-8nz0p1uc9vySkg Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:27:44 -0000 On Tue, Jun 3, 2014 at 4:40 PM, Brian E Carpenter wrote: > My point is that there are useful learnings in shim6 as well as in MPTCP > and SCTP. However, it will be very sad if we have to re-solve these > problems in every application suite rather than solving them once > in the stack. Got it. Agree completely. But looking at the momentum, I'm betting on higher layers. Content is driving the bus. Scott From nobody Tue Jun 3 15:49:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F531A038D for ; Tue, 3 Jun 2014 15:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 4vXQbsTCptw9 for ; Tue, 3 Jun 2014 15:49:06 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57231A038A for ; Tue, 3 Jun 2014 15:49:06 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id ma3so6049070pbc.23 for ; Tue, 03 Jun 2014 15:49:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QWeEE3bG3qOyDRywIV0SZ0yHK8OyR/tLIqJvi97OVIQ=; b=JvjF2DgDeaIbenZNa+KkcW4Wuii1+eyJYU4ON9P4mvj+gfE3ixa5eo70FZLwQmHJdz YIq7ojcDzwhPuwT0Ww+6F8ZuMCg2/1ffoWIFsL+YkprViD+xSUkEvX15Ao/FUYYYSkVM 2eIjMQ9f3qjSYQbe44sFCMrLAQCqy8xRfRgiftStdiUXr1IIHIB/5HFtoS6R+q2QHLRH JGVljFJef4RsCNGgFDBwVKn2G5jf8PRl/iokNpPQxvwSJPtpT2rkVOUItiWjLuog4yvH /U+jwKS5bVN0py2FB1KLOUapHk+cjdqWAcnaj6ygV6N3WjMQm/26KbqDhofgGZ6IdlP0 I/Ag== X-Gm-Message-State: ALoCoQl/4WNblmCFRDlQZYOLWdhupIrUbIEhTe2QW1L9HGvg9vh4kgqBD1rtY77Ws9SHLP4orCMz MIME-Version: 1.0 X-Received: by 10.68.218.231 with SMTP id pj7mr55388855pbc.95.1401835740455; Tue, 03 Jun 2014 15:49:00 -0700 (PDT) Received: by 10.70.37.78 with HTTP; Tue, 3 Jun 2014 15:49:00 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:a548:7657:72b0:a36e] In-Reply-To: References: <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <538B6AC3.7020402@bogus.com> <1DA781EA-D249-4B91-B8B7-3B719CE88925@nominum.com> <20140602233943.47DF017375B9@rock.dv.isc.org> <20140603130522.GQ46558@Space.Net> Date: Wed, 4 Jun 2014 08:49:00 +1000 Message-ID: From: George Michaelson To: V6 Ops List Content-Type: multipart/alternative; boundary=047d7b2ed26d595eb404faf651a2 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BSZw-PZ84izZI10LS2ykFPFlrOE Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 22:49:08 -0000 --047d7b2ed26d595eb404faf651a2 Content-Type: text/plain; charset=UTF-8 Its only a personal opinion, but I feel (based on what we see in V6 measurements that HE) has been a net overall mistake. * its not consistently implemented. * it collides with other mechanisms for address/family selection such as the apple RTT estimation model * its inherently non-deterministic * its not under (much) end user control I cannot believe that making it an across the board, or adding more complexity is going to make it better. -G On Tue, Jun 3, 2014 at 11:24 PM, Philip Homburg wrote: > In your letter dated Tue, 3 Jun 2014 15:05:22 +0200 you wrote: > >On Tue, Jun 03, 2014 at 09:39:43AM +1000, Mark Andrews wrote: > >> Extending HE to do multiple source addresses (one per prefix) within > >> a adddress family will give pretty much the same robustness as > >> running BGP at the cost of some embryonic connections if the initial > >> attempt doesn't work. > > > >It will give you *better* robustness than BGP, because BGP can not send > >your packets around dataplane failures where control plane still > advertises > >reachability. > > > >I find this very important to point out, again and again :-) > > The good news is that in a network that provides hosts with just one prefix > this feature should be harmless. > > But I'm not holding my breath for getting any kind of wide spread > implementation of such a feature. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b2ed26d595eb404faf651a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Its only a personal opinion, but I feel (based on what we = see in V6 measurements that HE) has been a net overall mistake.=C2=A0
<= br>
=C2=A0* its not consistently implemented.
=C2=A0* i= t collides with other mechanisms for address/family selection such as the a= pple RTT estimation model
=C2=A0* its inherently non-deterministic
=C2=A0* its not und= er (much) end user control

I cannot believe that m= aking it an across the board, or adding more complexity is going to make it= better.

-G


On Tue, Jun 3, 2014 at 11:24 PM, Philip Homburg <pch-v6ops-3a@u-1.phicoh.com> wrote:
In your letter dated Tue, 3 = Jun 2014 15:05:22 +0200 you wrote:
>On Tue, Jun 03, 2014 at 09:39:43AM +1000, Mark Andrews wrote:
>> Extending HE to do multiple source addresses (one per prefix) with= in
>> a adddress family will give pretty much the same robustness as
>> running BGP at the cost of some embryonic connections if the initi= al
>> attempt doesn't work.
>
>It will give you *better* robustness than BGP, because BGP can not send=
>your packets around dataplane failures where control plane still advert= ises
>reachability.
>
>I find this very important to point out, again and again :-)

The good news is that in a network that provides hosts with just one = prefix
this feature should be harmless.

But I'm not holding my breath for getting any kind of wide spread
implementation of such a feature.

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

--047d7b2ed26d595eb404faf651a2-- From nobody Tue Jun 3 18:18:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E671A03B6 for ; Tue, 3 Jun 2014 18:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xjjPUC6D5pIY for ; Tue, 3 Jun 2014 18:18:41 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2158A1A035F for ; Tue, 3 Jun 2014 18:18:41 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so5304172pdj.26 for ; Tue, 03 Jun 2014 18:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MtWOYs098rOvKpvyIjabx/2eOP9rhbagKiKS+ZL6o4c=; b=W6CHYSMvKM93hVPbVWQ2nISYOyzkEieM2i9aXz0AoInGuvT0GhtcYkVpmapXzFRBQM qIwDtm19H3IlUdj8VRWQ4KVs8LIBlJ+huY30thF+zAYPpXoP1FpUiv8aJ5N/c1dLWXuT UDLt/RRSOAh+ZzUM9ckOKR4ZbQYTN0+w2fCREI8wnGbP80Xr6lAZBpqmJjfFsSFvONbx PTIP8W9uHgrA551XmEyhWCR8o73rNS8C3Z9lkPo/xHUx6RV80nFEk3aV/h2RpBJxaoUh 2db1lTZt+Geb/3hmljt1WU4VllHO/OcZg0RwpwqeUVRqxH30C3D31bv6weUiIZRpQuyX ZDMA== X-Received: by 10.68.181.67 with SMTP id du3mr56589352pbc.96.1401844715276; Tue, 03 Jun 2014 18:18:35 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id hb10sm2852397pbd.75.2014.06.03.18.18.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 18:18:34 -0700 (PDT) Message-ID: <538E73EE.8050409@gmail.com> Date: Wed, 04 Jun 2014 13:18:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> In-Reply-To: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/71G53iYvz5h4yCDlbiSU-7FhA6g Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 01:18:42 -0000 Hi, > A problem common to the approach of distribution through hashing is > its impact on path MTU discovery. An ICMPv6 type 2 PTB message > generated on the path between a client and an ECMP load balanced > server will have the anycast address as the destination and will be > statelessly load balanced to one of the anycast servers. This may seem picky, but I think the reader's brain will run more smoothly if it's explicit that it's a PTB triggered by a packet *from* the server and therefore directed *to* the server. "on the path" doesn't quite contain that information. > Because of this, the results of > the ICMPv6 ECMP hash do not match that of the corresponding TCP or > UDP ECMP hash. Again picky, but if there are (say) 2 paths, there's a 50% chance that it gets the right path, etc. So "might not match" is probably better. General comment: I'm not sure what is specific to ECMP about this problem. We identified it as a general (but out of scope) problem in RFC 7098. We did include this comment there: o Note that correct handling of ICMPv6 for Path MTU Discovery requires the layer 3/4 balancer to keep state for the client source address, independently of either the port numbers or the flow label. because, indeed, the PMTU is a function of the address pair only. Brian From nobody Tue Jun 3 21:49:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C541A0075 for ; Tue, 3 Jun 2014 21:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 OOBc-mPwBXFj for ; Tue, 3 Jun 2014 21:49:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B18B1A0072 for ; Tue, 3 Jun 2014 21:49:07 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s544mrus020003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jun 2014 04:48:57 GMT (envelope-from joelja@bogus.com) Message-ID: <538EA522.4060507@bogus.com> Date: Tue, 03 Jun 2014 21:48:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Brian E Carpenter , IPv6 Operations , draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> <538E73EE.8050409@gmail.com> In-Reply-To: <538E73EE.8050409@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HwkPaMhCHSB8umCej6Lj5Pl1xXf2ptxlT" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Jun 2014 04:48:58 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/__muolVJmn9hgijSiglfZSytulg Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 04:49:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HwkPaMhCHSB8umCej6Lj5Pl1xXf2ptxlT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/3/14, 6:18 PM, Brian E Carpenter wrote: > Hi, >=20 >> A problem common to the approach of distribution through hashing is= >> its impact on path MTU discovery. An ICMPv6 type 2 PTB message >> generated on the path between a client and an ECMP load balanced >> server will have the anycast address as the destination and will be= >> statelessly load balanced to one of the anycast servers.=20 >=20 > This may seem picky, but I think the reader's brain will run > more smoothly if it's explicit that it's a PTB triggered by > a packet *from* the server and therefore directed *to* the server. > "on the path" doesn't quite contain that information. I think that's a reasonable observation and fairly straight forward to adjust. To my mind the destination address being the anycast address does communicate the direction of this ptb message. >> Because of this, the results of >> the ICMPv6 ECMP hash do not match that of the corresponding TCP or >> UDP ECMP hash. >=20 > Again picky, but if there are (say) 2 paths, there's a 50% chance > that it gets the right path, etc. So "might not match" is probably > better. If there are 64 hash buckets the probability of ending up in the same one is 1.5% if there are 255 it's ~.4%. so may not is potentially a near certainty. It's entirely possible to have more hash buckets than next-hops in order to facilitate load balancing without rehashing when adding and removing devices in which case the distribution may vary, and on those cases a packet hashed to the wrong bucket may well arrive on the correct server/load-balancer. > General comment: I'm not sure what is specific to ECMP > about this problem. We identified it as a general (but out of > scope) problem in RFC 7098. We did include this comment there: So it may be out of scope for your rfc, I'm pretty sure that doesn 't make the problem go away. I've been dinking around with large scale load-balancing of this flavor for some time, more than a decade in on form or another. We found it to be a commercial necessity to address the problem of how to make PTB work as part of deploying consumer facing internet applications services. it's not unique to ICMP, e.g. my interest in the fragdrop discussion is due to similar problems. > o Note that correct handling of ICMPv6 for Path MTU Discovery > requires the layer 3/4 balancer to keep state for the client > source address, independently of either the port numbers or the > flow label. So there are two problems with this assertion. 1. state sharing is presently impossible at that scale I'm operating at. so any solution that presumes it across an entire population of devices isn't going to work. state sharing between pairs of devices in otherwise stateless clusters (which describes the internal architecture of a number of high-end firewalls and load-balancer products doesn't solve this either). 2. the ptb packet doesn't have the parts of the flow associated within the ip and icmp header so the flow that is was associated with cannot be reconstructed by a pure l3/l4 device stateful or otherwise, it can as noted in the draft be derived by inspecting the icmp payload for the IP/TCP/UDP header of outgoing packet which is pretty deep packet inspection (normally done by the end system). Finding the ICMP header is not the same as being able to parse the payload. In any event we were using rather high-end but but otherwise normal router silicon, so we get to do this the same as anyone else who fronts a load-balancer or server tier containing ecmp nexhops with a router... > because, indeed, the PMTU is a function of the address pair only. The ptb packet has the source address of the device that emitted it. In any event, our goal isn't really to boil the ocean, with respect to parsing the packet or deriving correct host, if we could get close enough, it was to not break PMTUD, and therefore customers in a service that supported millions of users. > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --HwkPaMhCHSB8umCej6Lj5Pl1xXf2ptxlT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOOpSsACgkQ8AA1q7Z/VrJuxACaA565PHAOGsh7BIJW3+rehirB Ei4An3GifmARQ+7rwDRKHY+8ghjsCO9j =bkwF -----END PGP SIGNATURE----- --HwkPaMhCHSB8umCej6Lj5Pl1xXf2ptxlT-- From nobody Tue Jun 3 22:58:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBB51A008F for ; Tue, 3 Jun 2014 22:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 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.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LaxOJ2rOPq8o for ; Tue, 3 Jun 2014 22:58:02 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6011A008A for ; Tue, 3 Jun 2014 22:58:02 -0700 (PDT) Received: from [192.168.2.18] (unknown [108.71.36.133]) by dougbarton.us (Postfix) with ESMTPSA id 00A5822B1D for ; Wed, 4 Jun 2014 05:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1401861475; bh=KHWF3lr+aJIuVGNuSe9S+C6aOVY1EGiWeS8ERJfzXiA=; h=Date:From:To:Subject:References:In-Reply-To; b=mcjsdUFkMX5hlmH4m/mzqmoosHUg6T4v+QWEofCe3Q9WXbcGkEZfbv/G6NZjYSOUD 7525cV00GIINvzFfwUx+HQg2KqEo1WLBL0HUlYQLvTsrtdFz1suImItNN9WofKIyeu 9iW5paTu1xDqdP6dfbR8DJf2iFYBmGHp6ZL/YmrY= Message-ID: <538EB561.2020704@dougbarton.us> Date: Tue, 03 Jun 2014 22:57:53 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: V6 Ops List References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602025833.A659C1723F0A@rock.dv.isc.org> <20140602081853.GQ46558@Space.Net> <20140602150803.179BC1734B4E@rock.dv.isc.org> In-Reply-To: <20140602150803.179BC1734B4E@rock.dv.isc.org> X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a7kXq8XdDHNzSeVZAqRIBfspknw Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 05:58:03 -0000 On 06/02/2014 08:08 AM, Mark Andrews wrote: > At this point multiple PA prefixes are not common yet. It's actually fairly common in the US. Doug From nobody Wed Jun 4 03:48:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28161A01B1 for ; Wed, 4 Jun 2014 03:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham 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 ypVpuUDmgZZ1 for ; Wed, 4 Jun 2014 03:48:25 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25E1A0282 for ; Wed, 4 Jun 2014 03:48:25 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F03DD19833D; Wed, 4 Jun 2014 12:48:12 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be F03DD19833D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1401878893; bh=o4C6lmGjUTP+s7cxPc60mMiW4GRnfLxJ2TdSkWbLKbg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=R3YzcUoiGZsHnKOF6tVPA5Q7rOrEQaIXurrkd7NEzRBdn73hG4vWpAMqKBrxDhwAR rZH83oaktDgyRhdPCCTC4DvxDCiBSarHHpKq4aEcxRYZD+18zPEh5vUefqp/y51baM DW+USVu0vWdbxnW0NO9phz0ytoZyTi/Jm3mW5OVM= Message-ID: <538EF96E.8070300@uclouvain.be> Date: Wed, 04 Jun 2014 12:48:14 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Scott Brim , Brian E Carpenter References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com> <538E32D0.9050005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F03DD19833D.A4C0C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YS3GGxyzT_LvCI7dmPJnkcbBMbA Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:48:27 -0000 Scott, >> My point is that there are useful learnings in shim6 as well as in MPTCP >> and SCTP. However, it will be very sad if we have to re-solve these >> problems in every application suite rather than solving them once >> in the stack. > > Got it. Agree completely. But looking at the momentum, I'm betting on > higher layers. Content is driving the bus. I'd prefer transport than application. The problem with solving multihoming or other issues at the application layer is that this is complex and requires a lot of networking expertise. Some app developpers have this expertise, but they are the minority. We should not expect each app developper to have to deal with multihoming, the stack should solve the issue. This is the same problem as for reliability. We've placed reliability in the transport layer so that applications can built upon it. There are niche applications that want to reinvent reliable delivery, but this is not the best utilisation of scarce developper time... Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From nobody Wed Jun 4 03:57:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279471A029F for ; Wed, 4 Jun 2014 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mYLzFiePmZwZ for ; Wed, 4 Jun 2014 03:57:47 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07CE1A030B for ; Wed, 4 Jun 2014 03:57:46 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j17so7748769oag.1 for ; Wed, 04 Jun 2014 03:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MPb3Z290b1Xxoyum2l7ec2qUfChJYrJPlKvswQxp0yk=; b=gQO2li21/OIdn/Xgw2Dd9T44KeFsUtlZUimUL4rqoWAIQKSbeSCN4dma6WcyfTT1zc QvRGTRsu0J/OahOH87opS264kPyuOkHpbf/mE1lmYw32mo2tMqQFx778sC6ONm9j/bWo JVgDAnJ5P/g5mjmyl8VY7oXXTvZxWOgnVcH70XyngfKHiG4XMApe1/5fSadXMVP195Kz 3tDNA9+9J02ugahwznv+PmZ9erWBDNzSGPC0r/SgtnFo1J6buf1CHgB7uyEZ7HaywEUv uV4l55sKMS74RcuNRp0sQUaPNzcUOjPKc44mYRjcn7zaDchuxljglCsdq4nIIT2zuGUt J9QA== X-Received: by 10.60.101.170 with SMTP id fh10mr55746862oeb.39.1401879460739; Wed, 04 Jun 2014 03:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.183.8.7 with HTTP; Wed, 4 Jun 2014 03:57:19 -0700 (PDT) In-Reply-To: <538EF96E.8070300@uclouvain.be> References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com> <538E32D0.9050005@gmail.com> <538EF96E.8070300@uclouvain.be> From: Scott Brim Date: Wed, 4 Jun 2014 06:57:19 -0400 Message-ID: To: "Olivier.Bonaventure@uclouvain.be" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QbXkAvkWO4ipq375xF4hSP0LTrA Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:57:48 -0000 On Wed, Jun 4, 2014 at 6:48 AM, Olivier Bonaventure wrote: >>> My point is that there are useful learnings in shim6 as well as in MPTCP >>> and SCTP. However, it will be very sad if we have to re-solve these >>> problems in every application suite rather than solving them once >>> in the stack. >> >> Got it. Agree completely. But looking at the momentum, I'm betting on >> higher layers. Content is driving the bus. > > I'd prefer transport than application. The problem with solving multihoming > or other issues at the application layer is that this is complex and > requires a lot of networking expertise. Some app developpers > have this expertise, but they are the minority. We should not expect each > app developper to have to deal with multihoming, the stack should solve the > issue. This is the same problem as for reliability. We've placed reliability > in the transport layer so that applications can built upon it. There are > niche applications that want to reinvent reliable delivery, but this is not > the best utilisation of scarce developper time... > > Olivier Olivier: yes but there is tremendous momentum in user space / apps. ... but we digress. From nobody Wed Jun 4 13:32:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27D1A0085 for ; Wed, 4 Jun 2014 13:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1nJBUA7xyCDr for ; Wed, 4 Jun 2014 13:32:09 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F421E1A0339 for ; Wed, 4 Jun 2014 13:32:08 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id ma3so25389pbc.23 for ; Wed, 04 Jun 2014 13:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q1eym8FhCcBmVOA0ZlCxwVB3q9W8eJrHrLcDekIBDJk=; b=CGoGwLS97CfwiurnxS6TBIA/QKJrq71YnWlo6qnhejmLXPIKLi0gk3ViVHMEj3BnmP HA+PnYQQk3843hSk4c0Gf3uC8F5VhtmocykNou5x5gV6CKRTR8Ml0NiczdidTSD3mKuP I859mtLse0dgQGvXoa/g/2guCJlPbQUdVQusVHXFZiYODw5Q9Ulh+OySq5rHwmjn9gNs +G9GR5OWrc1WBKXGCc8jhoaX3xARr9D2PzV4rSmfTPFe4s3JVrtr+coWMEsSTQ78RuSS ja1/9/bVTUZvDDonISIxpjzV19fndMtsbQbc5+an9VCfR5RI9Sxe7cilr9f7BaknIGRl +kkA== X-Received: by 10.68.254.70 with SMTP id ag6mr67457805pbd.33.1401913922885; Wed, 04 Jun 2014 13:32:02 -0700 (PDT) Received: from [192.168.178.23] (81.194.69.111.dynamic.snap.net.nz. [111.69.194.81]) by mx.google.com with ESMTPSA id eh4sm13626423pbc.79.2014.06.04.13.32.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 13:32:02 -0700 (PDT) Message-ID: <538F8246.9000909@gmail.com> Date: Thu, 05 Jun 2014 08:32:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> <538E73EE.8050409@gmail.com> <538EA522.4060507@bogus.com> In-Reply-To: <538EA522.4060507@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/29Kqmcv7PB1cU-z2lYJqzJGx3Dw Cc: IPv6 Operations , draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:32:11 -0000 On 04/06/2014 16:48, joel jaeggli wrote: > On 6/3/14, 6:18 PM, Brian E Carpenter wrote: >> Hi, >> >>> A problem common to the approach of distribution through hashing is >>> its impact on path MTU discovery. An ICMPv6 type 2 PTB message >>> generated on the path between a client and an ECMP load balanced >>> server will have the anycast address as the destination and will be >>> statelessly load balanced to one of the anycast servers. >> This may seem picky, but I think the reader's brain will run >> more smoothly if it's explicit that it's a PTB triggered by >> a packet *from* the server and therefore directed *to* the server. >> "on the path" doesn't quite contain that information. > > I think that's a reasonable observation and fairly straight forward to > adjust. To my mind the destination address being the anycast address > does communicate the direction of this ptb message. > >>> Because of this, the results of >>> the ICMPv6 ECMP hash do not match that of the corresponding TCP or >>> UDP ECMP hash. >> Again picky, but if there are (say) 2 paths, there's a 50% chance >> that it gets the right path, etc. So "might not match" is probably >> better. > > If there are 64 hash buckets the probability of ending up in the same > one is 1.5% if there are 255 it's ~.4%. so may not is potentially a near > certainty. It's entirely possible to have more hash buckets than > next-hops in order to facilitate load balancing without rehashing when > adding and removing devices in which case the distribution may vary, and > on those cases a packet hashed to the wrong bucket may well arrive on > the correct server/load-balancer. My logic is the number of hash buckets doesn't matter - it's the number of paths, because if there are N paths, ~1/N of the traffic will go along each path regardless of the number of hash buckets. > >> General comment: I'm not sure what is specific to ECMP >> about this problem. We identified it as a general (but out of >> scope) problem in RFC 7098. We did include this comment there: > > So it may be out of scope for your rfc, I'm pretty sure that doesn 't > make the problem go away. I've been dinking around with large scale > load-balancing of this flavor for some time, more than a decade in on > form or another. We found it to be a commercial necessity to address the > problem of how to make PTB work as part of deploying consumer facing > internet applications services. it's not unique to ICMP, e.g. my > interest in the fragdrop discussion is due to similar problems. Fully agreed. It just wasn't a problem we could ameliorate using the flow label, so it didn't belong in 7098. > >> o Note that correct handling of ICMPv6 for Path MTU Discovery >> requires the layer 3/4 balancer to keep state for the client >> source address, independently of either the port numbers or the >> flow label. > > So there are two problems with this assertion. > > 1. state sharing is presently impossible at that scale I'm operating at. > so any solution that presumes it across an entire population of devices > isn't going to work. state sharing between pairs of devices in otherwise > stateless clusters (which describes the internal architecture of a > number of high-end firewalls and load-balancer products doesn't solve > this either). Agreed. Our comment was not intended to suggest that it was practical to synchronise state in that way. > > 2. the ptb packet doesn't have the parts of the flow associated within > the ip and icmp header so the flow that is was associated with cannot be > reconstructed by a pure l3/l4 device stateful or otherwise, it can as > noted in the draft be derived by inspecting the icmp payload for the > IP/TCP/UDP header of outgoing packet which is pretty deep packet > inspection (normally done by the end system). Finding the ICMP header is > not the same as being able to parse the payload. In any event we were > using rather high-end but but otherwise normal router silicon, so we get > to do this the same as anyone else who fronts a load-balancer or server > tier containing ecmp nexhops with a router... Agreed. Again, we didn't mean to imply that line-speed dissection of ICMP was practical; only that it seems to be needed to send PTBs where they need to go. > >> because, indeed, the PMTU is a function of the address pair only. > > The ptb packet has the source address of the device that emitted it. Yes, of course. That's why you have to dissect the packet. (One fanciful idea that the authors of 7098 discussed was to specify that the outgoing flow label value should be reflected back in the ICMPv6 packet, but that didn't seem like a deployable idea.) > > In any event, our goal isn't really to boil the ocean, with respect to > parsing the packet or deriving correct host, if we could get close > enough, it was to not break PMTUD, and therefore customers in a service > that supported millions of users. Fully understood. Brian From nobody Wed Jun 4 14:49:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E71A032B for ; Wed, 4 Jun 2014 14:49:17 -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 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 VCZIQljKY2rI for ; Wed, 4 Jun 2014 14:49:15 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 0423E1A024F for ; Wed, 4 Jun 2014 14:49:14 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s54Ln1C9031370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Jun 2014 22:49:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <538F944D.5080205@foobar.org> Date: Wed, 04 Jun 2014 22:49:01 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> <538E73EE.8050409@gmail.com> <538EA522.4060507@bogus.com> <538F8246.9000909@gmail.com> In-Reply-To: <538F8246.9000909@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Wy3W0En8cx6MwuUnVEPRcpGpX6k Cc: IPv6 Operations , draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:49:17 -0000 On 04/06/2014 21:32, Brian E Carpenter wrote: > My logic is the number of hash buckets doesn't matter - it's the number > of paths, because if there are N paths, ~1/N of the traffic will go > along each path regardless of the number of hash buckets. on a matter of nits, the number of hash buckets matters greatly if it's too small, and there is lots of hardware deployed out on the internet which suffers from not enough hash buckets. Nick From nobody Wed Jun 4 15:21:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80A51A0309 for ; Wed, 4 Jun 2014 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 8SWhkIyVSV0W for ; Wed, 4 Jun 2014 15:20:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id C24841A0373 for ; Wed, 4 Jun 2014 15:20:17 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 89D1E3493BC; Wed, 4 Jun 2014 22:20:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6EAA0160067; Wed, 4 Jun 2014 22:25:23 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 25F4E16004C; Wed, 4 Jun 2014 22:25:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7DC891767F80; Thu, 5 Jun 2014 08:19:35 +1000 (EST) To: Nick Hilliard From: Mark Andrews References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> <538E73EE.8050409@gmail.com> <538EA522.4060507@bogus.com> <538F8246.9000909@gmail.com> <538F944D.5080205@foobar.org> In-reply-to: Your message of "Wed, 04 Jun 2014 22:49:01 +0100." <538F944D.5080205@foobar.org> Date: Thu, 05 Jun 2014 08:19:35 +1000 Message-Id: <20140604221935.7DC891767F80@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eW9I2B9EAVJndTHa2Y-LvNqslSg Cc: IPv6 Operations , draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:21:03 -0000 Setting IPV6_USE_MIN_MTU to 1 should be a effective fix at the application layer for IPv6. That said FreeBSD doesn't do the right thing by taking IPV6_USE_MIN_MTU into consideration when performing MSS negotiations. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173444 Mark In message <538F944D.5080205@foobar.org>, Nick Hilliard writes: > On 04/06/2014 21:32, Brian E Carpenter wrote: > > My logic is the number of hash buckets doesn't matter - it's the number > > of paths, because if there are N paths, ~1/N of the traffic will go > > along each path regardless of the number of hash buckets. > > on a matter of nits, the number of hash buckets matters greatly if it's too > small, and there is lots of hardware deployed out on the internet which > suffers from not enough hash buckets. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 4 16:41:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC81A03D8 for ; Wed, 4 Jun 2014 16:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 SA1VkrPS5kLu for ; Wed, 4 Jun 2014 16:41:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697951A03D0 for ; Wed, 4 Jun 2014 16:41:05 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s54NetYC028430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jun 2014 23:40:56 GMT (envelope-from joelja@bogus.com) Message-ID: <538FAE82.1000902@bogus.com> Date: Wed, 04 Jun 2014 16:40:50 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20140602072659.7433.89475.idtracker@ietfa.amsl.com> <538E73EE.8050409@gmail.com> <538EA522.4060507@bogus.com> <538F8246.9000909@gmail.com> In-Reply-To: <538F8246.9000909@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DikI2GbIO8gdA5ltE1lmskowwq28rc4kX" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Jun 2014 23:40:56 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hTer6M-xhgs-5waxDUWI1W40KE4 Cc: IPv6 Operations , draft-jaeggli-v6ops-pmtud-ecmp-problem@tools.ietf.org Subject: Re: [v6ops] I-D Action: draft-jaeggli-v6ops-pmtud-ecmp-problem-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:41:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DikI2GbIO8gdA5ltE1lmskowwq28rc4kX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/4/14, 1:32 PM, Brian E Carpenter wrote: > On 04/06/2014 16:48, joel jaeggli wrote: >> On 6/3/14, 6:18 PM, Brian E Carpenter wrote: >>> Hi, >>> >>>> A problem common to the approach of distribution through hashing = is >>>> its impact on path MTU discovery. An ICMPv6 type 2 PTB message >>>> generated on the path between a client and an ECMP load balanced >>>> server will have the anycast address as the destination and will = be >>>> statelessly load balanced to one of the anycast servers.=20 >>> This may seem picky, but I think the reader's brain will run >>> more smoothly if it's explicit that it's a PTB triggered by >>> a packet *from* the server and therefore directed *to* the server. >>> "on the path" doesn't quite contain that information. >> >> I think that's a reasonable observation and fairly straight forward to= >> adjust. To my mind the destination address being the anycast address >> does communicate the direction of this ptb message. >> >>>> Because of this, the results of >>>> the ICMPv6 ECMP hash do not match that of the corresponding TCP o= r >>>> UDP ECMP hash. >>> Again picky, but if there are (say) 2 paths, there's a 50% chance >>> that it gets the right path, etc. So "might not match" is probably >>> better. >> >> If there are 64 hash buckets the probability of ending up in the same >> one is 1.5% if there are 255 it's ~.4%. so may not is potentially a ne= ar >> certainty. It's entirely possible to have more hash buckets than >> next-hops in order to facilitate load balancing without rehashing when= >> adding and removing devices in which case the distribution may vary, a= nd >> on those cases a packet hashed to the wrong bucket may well arrive on >> the correct server/load-balancer. >=20 > My logic is the number of hash buckets doesn't matter - it's the number= > of paths, because if there are N paths, ~1/N of the traffic will go > along each path regardless of the number of hash buckets. yeah and I had 64 paths in one deployment so... >> >>> General comment: I'm not sure what is specific to ECMP >>> about this problem. We identified it as a general (but out of >>> scope) problem in RFC 7098. We did include this comment there: >> >> So it may be out of scope for your rfc, I'm pretty sure that doesn 't >> make the problem go away. I've been dinking around with large scale >> load-balancing of this flavor for some time, more than a decade in on >> form or another. We found it to be a commercial necessity to address t= he >> problem of how to make PTB work as part of deploying consumer facing >> internet applications services. it's not unique to ICMP, e.g. my >> interest in the fragdrop discussion is due to similar problems. >=20 > Fully agreed. It just wasn't a problem we could ameliorate using the > flow label, so it didn't belong in 7098. If I were hashing on the flow label (which frankly I wouldn't mind doing) I'd still have to find it. it can probably can be found fairly easily since theoretically since the packet in the payload originated with me, and I emitted no fragments, and used no extension headers the payload in the icmp after offset 32 should be the ip header, which is conveniently fixed. and the upper layer header. doing this in silicon depends on how much of the packet I can sluice off with the header (and vendor implmentation of course). >> >>> o Note that correct handling of ICMPv6 for Path MTU Discovery >>> requires the layer 3/4 balancer to keep state for the client >>> source address, independently of either the port numbers or the >>> flow label. >> >> So there are two problems with this assertion. >> >> 1. state sharing is presently impossible at that scale I'm operating a= t. >> so any solution that presumes it across an entire population of device= s >> isn't going to work. state sharing between pairs of devices in otherwi= se >> stateless clusters (which describes the internal architecture of a >> number of high-end firewalls and load-balancer products doesn't solve >> this either). >=20 > Agreed. Our comment was not intended to suggest that it was practical > to synchronise state in that way. >=20 >> >> 2. the ptb packet doesn't have the parts of the flow associated within= >> the ip and icmp header so the flow that is was associated with cannot = be >> reconstructed by a pure l3/l4 device stateful or otherwise, it can as >> noted in the draft be derived by inspecting the icmp payload for the >> IP/TCP/UDP header of outgoing packet which is pretty deep packet >> inspection (normally done by the end system). Finding the ICMP header = is >> not the same as being able to parse the payload. In any event we were >> using rather high-end but but otherwise normal router silicon, so we g= et >> to do this the same as anyone else who fronts a load-balancer or serve= r >> tier containing ecmp nexhops with a router... >=20 > Agreed. Again, we didn't mean to imply that line-speed dissection > of ICMP was practical; only that it seems to be needed to send > PTBs where they need to go. >=20 >> >>> because, indeed, the PMTU is a function of the address pair only. >> >> The ptb packet has the source address of the device that emitted it. >=20 > Yes, of course. That's why you have to dissect the packet. >=20 > (One fanciful idea that the authors of 7098 discussed was to > specify that the outgoing flow label value should be reflected > back in the ICMPv6 packet, but that didn't seem like a > deployable idea.) In practice even if many of them weren't zero, 20 bits isn't enough for the flow label by itself to positively identify the flow in my case. notwitstanding the lack of state sharing. if it used the destination adress and the flow label, that would actually do it, but then it's spoofing. >> >> In any event, our goal isn't really to boil the ocean, with respect to= >> parsing the packet or deriving correct host, if we could get close >> enough, it was to not break PMTUD, and therefore customers in a servic= e >> that supported millions of users. >=20 > Fully understood. >=20 > Brian >=20 --DikI2GbIO8gdA5ltE1lmskowwq28rc4kX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOProIACgkQ8AA1q7Z/VrK0sACfUcQybxRLnWwfMrKr0Zzu1Aiu k7EAn1tDiDlK4q+e+UpYXUpLCuPKJLFi =z+gc -----END PGP SIGNATURE----- --DikI2GbIO8gdA5ltE1lmskowwq28rc4kX-- From nobody Thu Jun 5 06:53:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED8C1A0090 for ; Thu, 5 Jun 2014 06:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 VOeShQzH6q8I for ; Thu, 5 Jun 2014 06:53:48 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DA71A016E for ; Thu, 5 Jun 2014 06:53:48 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id to1so902569ieb.30 for ; Thu, 05 Jun 2014 06:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TXm31So5NAoM/m8r5bWFuhOhCT4HvHRZcc/fMXyMSuI=; b=iUlc9/VSLy30qP2TZ0TkwMGEQyATjz2/Egv6w1VbbKMW/6Juui7AYiHqezq43IYEbM 65UTtZ5iSxtA9DBEYFXauI/byo0E9Tn/4jF7fcFVdX0Jqxtjvq+nb6X3xzOp3oWyfixh j4pNmWuCiWzAbaDvSWldyururpHH61l3fuFBLZDw5uOWNhkIoBSIcOhAQtlVhyZXYkOa nRKfOLMTH1fzHpdzUdRdrlblgk4JisGnq+b9hnaDJQJH66BVRlsY3W1NTrdzZEYKGqTR U4GH6GYfJKVYsDNhab0+CyiHU5mbk25PayrvqXm2cQDzZxBg06uKTc7INSgQlprvqech hurQ== 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-type; bh=TXm31So5NAoM/m8r5bWFuhOhCT4HvHRZcc/fMXyMSuI=; b=FMDFkJ0Dyic/XJ1z/Sl6LqdMGZR8/fwRwKIt18TC+DkihJoVRvYEL01VNw7yRB6d3I vFItAYQGxeM8ojLSWDR2YMHVkBzQbXKLWlKRe0iITe9Q0IIBUWdyIHwxF48nCYAW6QAg htSxAv1wZ8OXDkcjanCs6v5kfJjdmqC0flb/CP243ybzxYW4LraDcPQ3lNpmmJxPOw0p +B5BQCMPy7w5fIBIpuuFZBm5BOswZdyS+vNzuV2LNCQdp84ryheTntfCB27/PtlQN059 VxG6+eD7IFnmPUd4gBelyPjHNtjBdqZ0kNIbni6dSjJKRPav/zBOAQHONhBO4dKQpjwx jG9A== X-Gm-Message-State: ALoCoQkidFZmEZbiMvhRtdE7dNcivCbbKc0TARXbwQJPOGBmTn0xqjfb2G3QIxejvE7s91J20s7I X-Received: by 10.50.143.9 with SMTP id sa9mr20570466igb.2.1401976421289; Thu, 05 Jun 2014 06:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 5 Jun 2014 06:53:20 -0700 (PDT) In-Reply-To: <1401744443.72735.YahooMailNeo@web162204.mail.bf1.yahoo.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140601231140.303E9171FD22@rock.dv.isc.org> <1401744443.72735.YahooMailNeo@web162204.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Thu, 5 Jun 2014 22:53:20 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=001a1134d10293389f04fb17120c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tCuqs5v7vdp48zIEn7sH19fvsWE Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:53:51 -0000 --001a1134d10293389f04fb17120c Content-Type: text/plain; charset=UTF-8 On Tue, Jun 3, 2014 at 6:27 AM, Mark ZZZ Smith wrote: > Google seem to consider that they need to facilitate IPv4 redundancy in > this way, as a query for A records for google.com returns 16 different A > records. I doubt they'd be doing that unless they had some evidence that it > is useful to some portion of end-users. They are shuffling the addresses > around on each query, however they could do that but still only return one. > AFAIK that is not done for fallback reasons. --001a1134d10293389f04fb17120c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 3, 2014 at 6:27 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com= .au> wrote:
Google seem to consider that= they need to facilitate IPv4 redundancy in this way, as a query for A reco= rds for google.com retu= rns 16 different A records. I doubt they'd be doing that unless they ha= d some evidence that it is useful to some portion of end-users. They are sh= uffling the addresses around on each query, however they could do that but = still only return one.

AFAIK that is not done for fallback reason= s.=C2=A0
--001a1134d10293389f04fb17120c-- From nobody Thu Jun 5 12:01:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7041A02EA; Thu, 5 Jun 2014 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 KYTFEl9-7seW; Thu, 5 Jun 2014 12:01:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0FAE71A031D; Thu, 5 Jun 2014 12:00:56 -0700 (PDT) Received: from unnumerable.local (pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s55J0nxv017809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 5 Jun 2014 14:00:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66] claimed to be unnumerable.local Message-ID: <5390BE61.4050407@nostrum.com> Date: Thu, 05 Jun 2014 14:00:49 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: General Area Review Team , "ietf@ietf.org" , draft-ietf-v6ops-enterprise-incremental-v6@tools.ietf.org, v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v9t0khhqBqVZXa7b1qKEFKAhCN8 Subject: [v6ops] Gen-art LC review: draft-ietf-v6ops-enterprise-incremental-ipv6-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:01:13 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-enterprise-incremental-ipv6-05 Reviewer: Robert Sparks Review Date: 5 June 2014 IETF LC End Date: 9 June 2014 IESG Telechat date: not yet scheduled Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be considered before publication. I had a mixed overall impression after my first read-through of this draft. Overall, the list of issues to consider, and the compendium of references is very useful, but there are large stretches of text that really aren't helping the reader, and they make the good stuff harder to see. I encourage the group to take one more editorial pass, focusing on removing as much text as possible without losing the message. Please help the IESG and the RFC-Editor out: the shepherd's writeup should say something about why deviating from the style guide's restriction on number of authors is is appropriate for this document. Here are specific nits to consider in document order: The first paragraph of section 1.3 starts talking about phases as if they've already been described. As written, it says that beginning with the External Phase is recommended in RFC5211. But the words "External Phase" do not appear in 5211, and its not clear on a quick read exactly what in 5211 you were hoping to point out here. Please introduce the phases before this point, and change the callout to 5211 to make it more clear how what 5211 is saying ties into this document. Why is "Other Phases" capitalized in 2.1? The number of phases defined in this document is small - I suspect this text is older and left room for the group to decide to define more phases. Consider just listing what you ended up with explicitly. Section 2.1 contains sentences like "The project manager will need to spend some time on planning." That is obvious, and you've already established that planning needs to happen. This paragraph (perhaps much of this section) would be improved by removing as much text as you can. It already speaks mostly in terms of the benefits of planning. Making that a more explicit goal in the writing structure would help identify what can be taken away without losing the message. Overall, trying to describe what good project management entails is a bit out of place. Perhaps you should just say "This requires good project management skills"? In 2.2.2 you say "Applications should be made to use APIs". That seems an odd construct for an IETF document. Perhaps you could observe, rather than command, here? Would saying something like "Applications that use APIs to hide the specifics ... will be easier to take through the migration" make the point? In 2.3, why do you need the hyperbole in "IPv6 adoption will be a multifacted undertaking that will touch everyone in the organization unlike almost any other project."? How does the "unlike almost any other project" help the reader? In 2.4.1, please rephrase "pretty much like". Are there any differences in the use of IPSec dependent on the address family that are important to call out? If not, why doesn't this say "the same as in"? Section 2.4.2: As written, this says Etc. is an attack. Please change the introduction to the list to say "for example" or "in particular" and remove the Etc. If the point was to cause the reader to think about attacks beyond these listed, say that explicitly. The 6th paragraph of 2.6 states the problem is "how to get host DNS records updated." The text in the rest of the paragraph only addresses this by implication. It looks more like the general discussion of SLAAC vs DHCPv6 instead of straightforwardly noting that a DHCPv6 server can be made to update DNS records. The reference to RFC6866 in paragraph 7 of section 2.6 is unclear - what was it trying to point out? I think the last sentence was trying to say 'static address assignment (even if achieved with DHCP) is usually used' where it currently says 'SLAAC is rarely used'? Section 3: The second paragraph doesn't add anything to the document. Section 3.1 paragraph 2: I don't understand why the paragraph ends with "which is an important consideration". Can you delete the phrase without losing the message? If not, say why an enterprise would care whether or not _other_ enterprises had already deployed using BGP on their own. Section 3.1 paragraph 4 : "will prefer to use" is out of place. Perhaps this should be stated as "will likely get better results using"? Section 3.1 paragraph 5: Can you add a reference to a discussion of how keeping the MTU congruent simplifies operations? In section 3.2 consider using the names from 4890 in the list ('Packet Too Big' rather than 'Unreachable packet-to-big') Please check whether the sentence "To be fully compliant with [RFC5095], all packets containing the routing extension header type 0 must be dropped." is perhaps too simple a description of 5095? Does context keep you out of the "Segments left is zero" branch of that RFCs requirement? In section 3.4, please remove "this may seem too time-consuming and too risky" or restate it with details. How is this observation supposed to help the reader? In section 4.1 paragraph 3 "But the major issue is probably linked to all threats" would read better as "One major issue is threats" In section 5 paragraph 3, please provide a reference to where these significant implications are discussed, or add some discussion. (Otherwise, what is the reader supposed to do with this observation?) From nobody Fri Jun 6 18:20:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068931A0293; Fri, 6 Jun 2014 18:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 noO85Yopi0kP; Fri, 6 Jun 2014 18:20:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3191A030A; Fri, 6 Jun 2014 18:19:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 83B0B180491; Fri, 6 Jun 2014 18:18:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140607011835.83B0B180491@rfc-editor.org> Date: Fri, 6 Jun 2014 18:18:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/INPxRP9IUSo01IcxCOR3e1VYzqU Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7269 on NAT64 Deployment Options and Experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:20:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7269 Title: NAT64 Deployment Options and Experience Author: G. Chen, Z. Cao, C. Xie, D. Binet Status: Informational Stream: IETF Date: June 2014 Mailbox: chengang@chinamobile.com, caozhen@chinamobile.com, xiechf@ctbri.com.cn, david.binet@orange.com Pages: 22 Characters: 56043 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-nat64-experience-10.txt URL: http://www.rfc-editor.org/rfc/rfc7269.txt This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jun 11 15:05:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5FB1A02D4; Wed, 11 Jun 2014 15:05:11 -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 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 UAmSkoFniL17; Wed, 11 Jun 2014 15:05:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B13701B28B3; Wed, 11 Jun 2014 15:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611220502.9808.40372.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 15:05:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s9xO95_ZAl4I8bQUZQt_v74ZZno Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-clatip-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:05:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv4 Service Continuity Prefix Author : Cameron Byrne Filename : draft-ietf-v6ops-clatip-03.txt Pages : 5 Date : 2014-06-11 Abstract: DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-clatip-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-clatip-03 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 Tue Jun 17 12:33:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B10D1A014E for ; Tue, 17 Jun 2014 12:33:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 AFufRFBihp5g for ; Tue, 17 Jun 2014 12:33:40 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0461A00C0 for ; Tue, 17 Jun 2014 12:33:39 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s5HJXcYn016247 for ; Tue, 17 Jun 2014 15:33:38 -0400 Received: (qmail 23314 invoked by uid 0); 17 Jun 2014 19:33:33 -0000 X-TCPREMOTEIP: 204.235.115.166 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.46?) (lee@asgard.org@204.235.115.166) by 0 with ESMTPA; 17 Jun 2014 19:33:32 -0000 User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Tue, 17 Jun 2014 15:33:29 -0400 From: Lee Howard To: "'IPv6 Operations'" Message-ID: Thread-Topic: Important dates in preparation for IETF90 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Rxsmavr-iRjWqTPtfckK6hP7eHA Subject: [v6ops] Important dates in preparation for IETF90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 19:33:44 -0000 Some reminders about important dates coming up. . . Registration is now open. 4 July: Internet Draft submission. Work on them early, so as not to interrupt your summer plans. This is just over two weeks away, so if you were planning to submit or revise a draft and get some discussion, this would be the time. 7 July: WG chairs upload WG agendas. Remember that in v6ops, agenda time is given to drafts people have shown interest in, based on mailing list discussion. 11 July: Early Bird registration and payment cut-off; the cost to register goes up. 18 July: Last day to pre-register and pre-pay. 20-25 July: 90th IETF Meeting in Toronto, ON, Canada. We have requested two meeting slots, based on activity at previous meetings. If you need a travel visa, you should figure out requirements early. While you're considering your IETF activity and plans, please consider volunteering for the NomCom: https://datatracker.ietf.org/nomcom/ann/66245/ Helpfully, Lee From nobody Wed Jun 18 01:32:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5B1A00BF; Wed, 18 Jun 2014 01:32:39 -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 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 1GP6PFnay5iH; Wed, 18 Jun 2014 01:32:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A941A008B; Wed, 18 Jun 2014 01:32:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618083237.18766.77289.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 01:32:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wmkAJO5IzPPLYuJF476UsbxZ6EM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:32:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : DHCPv6/SLAAC Address Configuration Interaction Problem Statement Authors : Bing Liu Ron Bonica Xiangyang Gong Wendong Wang Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt Pages : 12 Date : 2014-06-18 Abstract: This document analyzes the DHCPv6/SLAAC interaction issue on host. More specifically, the interaction is regarding with the A, M, and O flags which are defined in ND protocol. Test results identify that current implementations in operating systems have varied on interpreting the flags. The variation might cause some operational issues as described in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 18 01:47:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5371C1A008E for ; Wed, 18 Jun 2014 01:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 g6_uszKZetsi for ; Wed, 18 Jun 2014 01:47:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749E01A008C for ; Wed, 18 Jun 2014 01:47:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO04627; Wed, 18 Jun 2014 08:47:41 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 09:47:13 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 16:47:08 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt Thread-Index: AQHPis/h/mihngwm+Uy5R751pHKbUpt2iydQ Date: Wed, 18 Jun 2014 08:47:08 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kxDF5Z_9MSyTIdigNHkty3_yDks Subject: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 08:47:44 -0000 SGkgYWxsLA0KDQpXZSd2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0K VGhpcyB2ZXJzaW9uIGRvZXNuJ3QgaGF2ZSBtdWNoIHRlY2huaWNhbCBjaGFuZ2VzLCBidXQgbG90 cyBvZiByZS13b3JkaW5nIGFuZCBzb21lIHN0cnVjdHVyZSBhZGp1c3RtZW50Lg0KMS4gVGhlIHRl c3QgcmVzdWx0cyBhcmUgdG90YWxseSByZW1vdmVkIHRvIHRoZSBBcHBlbmRpeCwgc28gdGhhdCB0 aGUgbWFpbiBib2R5IGlzIGZvY3VzaW5nIG9uIGNvbW1vbiBwcm9ibGVtcywgcmF0aGVyIHRoYW4g ZGV0YWlsZWQgYmVoYXZpb3Igb2Ygc29tZSBzcGVjaWZpYyBvcGVyYXRpbmcgc3lzdGVtcy4gDQpC ZWNhdXNlIHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBhbHdheXMgZXZvbHZpbmcsIGV2ZW4gZGlmZmVy ZW50IHZlcnNpb25zIG9mIHRoZSBzYW1lIHZlbmRvciBtaWdodCBoYXZlIGRpZmZlcmVudCBiZWhh dmlvci4gVGhlIHBvaW50IG9mIHRoZSBkcmFmdCBpcyB0byBjYXV0aW9uIHRoZSBhZG1pbmlzdHJh dG9ycywgYXMgbG9uZyBhcyB0aGUgYW1iaWd1aXR5IGV4aXN0cyBpbiB0aGUgc3RhbmRhcmQsIHRo ZXJlIGFyZSBwb3NzaWJsZSBwcm9ibGVtcyB0aGV5IG1pZ2h0IGZhY2UuIFRoZSB0ZXN0IHJlc3Vs dHMgYXJlIG9ubHkgYW4gaW5zdGFuY2UvcHJvb2Ygb2YgdGhlIGFtYmlndWl0eSBwcm9ibGVtLCBp dCBzaG91bGQgbm90IGJlIHRoZSBtYWluIGNvbnRlbnQuDQpCdXQgYXMgc29tZSBwZW9wbGUgc3Vn Z2VzdGVkLCB3ZSdsbCByZWZyZXNoIHRoZSB0ZXN0IG9mIG5ld2VzdCBvcGVyYXRpb24gc3lzdGVt cyB3aGVuIHRoZSBkb2N1bWVudCBjb3VsZCBiZSBwdWJsaXNoZWQgaW4gdGhlIGZ1dHVyZS4NCjIu IFRoZSBzdHJ1Y3R1cmUgd2FzIGFkanVzdGVkLCB0byBlbXBoYXNpemUgdGhlIHByb2JsZW0gc3Rh dGVtZW50IGFzIGEgc3RhbmRhbG9uZSBTZWN0aW9uIDMuDQozLiBTb21lIHRpdGxlcyB3ZXJlIGNo YW5nZWQgYXMgd2VsbA0KNC4gTm90IGEgZmV3IHJlLXdvcmRpbmcgYm90aCBpbiBtYWluIGJvZHkg YW5kIHRoZSBhcHBlbmRpeA0KDQpZb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21lZC4NCg0KTWFueSB0 aGFua3MhDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcgKG9uIGJlaGFsZiBvZiBhbGwgY28tYXV0aG9y cykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNk YXksIEp1bmUgMTgsIDIwMTQgNDozMyBQTQ0KVG86IFJvbiBCb25pY2E7IFJvbiBCb25pY2E7IFhp YW5neWFuZyBHb25nOyBMaXViaW5nIChMZW8pOyBXZW5kb25nIFdhbmc7IExpdWJpbmcgKExlbyk7 IFhpYW5neWFuZyBHb25nOyBXZW5kb25nIFdhbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMS50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMt cHJvYmxlbS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBM aXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0 Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KUmV2aXNpb246CTAxDQpUaXRsZToJCURIQ1B2 Ni9TTEFBQyBBZGRyZXNzIENvbmZpZ3VyYXRpb24gSW50ZXJhY3Rpb24gUHJvYmxlbSBTdGF0ZW1l bnQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMTgNCkdyb3VwOgkJdjZvcHMNClBhZ2VzOgkJMTIN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtZGhjcHY2 LXNsYWFjLXByb2JsZW0vDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wMQ0KRGlmZjogICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtZGhj cHY2LXNsYWFjLXByb2JsZW0tMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGFuYWx5 emVzIHRoZSBESENQdjYvU0xBQUMgaW50ZXJhY3Rpb24gaXNzdWUgb24gaG9zdC4NCiAgIE1vcmUg c3BlY2lmaWNhbGx5LCB0aGUgaW50ZXJhY3Rpb24gaXMgcmVnYXJkaW5nIHdpdGggdGhlIEEsIE0s IGFuZCBPDQogICBmbGFncyB3aGljaCBhcmUgZGVmaW5lZCBpbiBORCBwcm90b2NvbC4gVGVzdCBy ZXN1bHRzIGlkZW50aWZ5IHRoYXQNCiAgIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGluIG9wZXJh dGluZyBzeXN0ZW1zIGhhdmUgdmFyaWVkIG9uDQogICBpbnRlcnByZXRpbmcgdGhlIGZsYWdzLiBU aGUgdmFyaWF0aW9uIG1pZ2h0IGNhdXNlIHNvbWUgb3BlcmF0aW9uYWwNCiAgIGlzc3VlcyBhcyBk ZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Wed Jun 18 02:18:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BFB1A00BF for ; Wed, 18 Jun 2014 02:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Ng36gQn6H0NR for ; Wed, 18 Jun 2014 02:18:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462C71A008E for ; Wed, 18 Jun 2014 02:18:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO08242; Wed, 18 Jun 2014 09:18:29 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 10:18:28 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 17:18:25 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: Next step of DHCP/SLAAC problem Thread-Index: Ac+K1jnjx5Ibf0NSRUycj/2xE16mVg== Date: Wed, 18 Jun 2014 09:18:25 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KZWVTggUFDqL94aJ5JTBHRCsEjI Subject: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:18:32 -0000 Hi all, Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC interac= tion problem: Problem Statement: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem Operational Guidelines: http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 The Problem Statement document has been adopted by the WG (we just uploaded= a new version, details to see the other mail), and the Operational Guideli= nes document was discussed in last ietf meeting in London. According to the discussion, it seemed people were not clear about whether = we need a separate operational guidelines document or not.=20 So let me enumerate possible next steps of the topic to see which you prefe= r: 1. Move forward the PS document to be published, and possibly adopt the Ope= rational Guidelines document as well (Of course the draft needs further rev= ision and discussion). 2. Integrate the operations guidelines into the PS draft, and move forward = it to be published 3. Move forward the PS document, and drop the operational guidelines docume= nt. Looking forward to your opinions. Many thanks! Best regards, Bing From nobody Wed Jun 18 02:27:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771AA1A0142 for ; Wed, 18 Jun 2014 02:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 osSNdZfd5yd8 for ; Wed, 18 Jun 2014 02:27:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CF61A0129 for ; Wed, 18 Jun 2014 02:27:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO09232; Wed, 18 Jun 2014 09:27:18 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 10:27:17 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 17:27:13 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: Next step of DHCP/SLAAC problem Thread-Index: Ac+K1jnjx5Ibf0NSRUycj/2xE16mVgAAEKZA Date: Wed, 18 Jun 2014 09:27:12 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA34@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AYtkP6ldOW8W4GVFNOWYwyNHzOI Subject: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:27:22 -0000 (re-send to CC the Chairs) Hi all, Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC interac= tion problem: Problem Statement: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem Operational Guidelines: http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 The Problem Statement document has been adopted by the WG (we just uploaded= a new version, details to see the other mail), and the Operational Guideli= nes document was discussed in last ietf meeting in London. According to the discussion, it seemed people were not clear about whether = we need a separate operational guidelines document or not.=20 So let me enumerate possible next steps of the topic to see which you prefe= r: 1. Move forward the PS document to be published, and possibly adopt the Ope= rational Guidelines document as well (Of course the draft needs further rev= ision and discussion). 2. Integrate the operations guidelines into the PS draft, and move forward = it to be published 3. Move forward the PS document, and drop the operationa= l guidelines document. Looking forward to your opinions. Many thanks! Best regards, Bing From nobody Wed Jun 18 04:07:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA231A0193 for ; Wed, 18 Jun 2014 04:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 7TY-1MQDe7Rr for ; Wed, 18 Jun 2014 04:07:09 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C51A0171 for ; Wed, 18 Jun 2014 04:07:09 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-135.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2DEF766BA; Wed, 18 Jun 2014 03:55:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1D05E034-6DC7-43EF-9F14-130F01F97F72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ole Troan In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA34@nkgeml506-mbx.china.huawei.com> Date: Wed, 18 Jun 2014 12:55:54 +0200 Message-Id: <7736F42D-8BB1-4611-8036-0E2E351BFA82@employees.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA34@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o-YOMu3DY101he5cjrr7V24SC3k Cc: v6ops WG Subject: Re: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 11:07:11 -0000 --Apple-Mail=_1D05E034-6DC7-43EF-9F14-130F01F97F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bing, > (re-send to CC the Chairs) >=20 > Hi all, >=20 > Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC = interaction problem: > Problem Statement: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > Operational Guidelines: > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 >=20 > The Problem Statement document has been adopted by the WG (we just = uploaded a new version, details to see the other mail), and the = Operational Guidelines document was discussed in last ietf meeting in = London. > According to the discussion, it seemed people were not clear about = whether we need a separate operational guidelines document or not.=20 >=20 > So let me enumerate possible next steps of the topic to see which you = prefer: > 1. Move forward the PS document to be published, and possibly adopt = the Operational Guidelines document as well (Of course the draft needs = further revision and discussion). > 2. Integrate the operations guidelines into the PS draft, and move = forward it to be published 3. Move forward the PS document, and drop the = operational guidelines document. do you also intend to update protocol specifications? cheers, Ole --Apple-Mail=_1D05E034-6DC7-43EF-9F14-130F01F97F72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJToXA7AAoJEFuJXizso86ghfMH/jP+UHmENeta/7uRAhAoQi+U g7+v4dd0EXEsMvHTyWtLdwSV/1mav+QMezrMzgqj9LDeP0takHt3+JskBTtDJ5fH N6RLGvJx43yUNkgYxrBjhm4dnCvfGgt81J9yl826uqefMm29PI6sN//Zapwnk5VQ uKfA395TDkHGww+x4r9r+O830ZJ6rhXoDyZ/OTIeowQH5Znm6wRnJnPST5mgcBRM ZAcnss7VKWibtUwSGHqYW5mCi3Ih6opq0C/B6SkTpY3LDDus5Ls7NKjDj57T3mAm NlSo2mOHg+hkeTqhhK8H60h2vDvNqlHmBncA+js+mlSiTfnqU9tbSMWIOoUWCxs= =IW/h -----END PGP SIGNATURE----- --Apple-Mail=_1D05E034-6DC7-43EF-9F14-130F01F97F72-- From nobody Wed Jun 18 18:51:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477A21A025C for ; Wed, 18 Jun 2014 18:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 wNAdCZeLMSQ2 for ; Wed, 18 Jun 2014 18:51:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848681A016E for ; Wed, 18 Jun 2014 18:51:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO74269; Thu, 19 Jun 2014 01:51:51 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 02:51:50 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 09:51:46 +0800 From: "Liubing (Leo)" To: Ole Troan Thread-Topic: [v6ops] Next step of DHCP/SLAAC problem Thread-Index: Ac+K1jnjx5Ibf0NSRUycj/2xE16mVgAAEKZA//+UqwD//oOqQA== Date: Thu, 19 Jun 2014 01:51:45 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEBBB@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA34@nkgeml506-mbx.china.huawei.com> <7736F42D-8BB1-4611-8036-0E2E351BFA82@employees.org> In-Reply-To: <7736F42D-8BB1-4611-8036-0E2E351BFA82@employees.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WcupWHUC2vBQKxEPmjhx5HuMVuQ Cc: v6ops WG Subject: Re: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 01:51:55 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Wednesday, June 18, 2014 6:56 PM > To: Liubing (Leo) > Cc: v6ops WG > Subject: Re: [v6ops] Next step of DHCP/SLAAC problem >=20 > Bing, >=20 > > (re-send to CC the Chairs) > > > > Hi all, > > > > Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC > interaction problem: > > Problem Statement: > > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > > Operational Guidelines: > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 > > > > The Problem Statement document has been adopted by the WG (we just > uploaded a new version, details to see the other mail), and the Operation= al > Guidelines document was discussed in last ietf meeting in London. > > According to the discussion, it seemed people were not clear about > whether we need a separate operational guidelines document or not. > > > > So let me enumerate possible next steps of the topic to see which you > prefer: > > 1. Move forward the PS document to be published, and possibly adopt the > Operational Guidelines document as well (Of course the draft needs furthe= r > revision and discussion). > > 2. Integrate the operations guidelines into the PS draft, and move forw= ard > it to be published 3. Move forward the PS document, and drop the > operational guidelines document. >=20 > do you also intend to update protocol specifications? [Bing] According to former discussion, we now have no intention to update r= elevant protocol specifications. I think the two documents are still useful in v6ops without any protocol re= visions. Best regards, Bing > cheers, > Ole From nobody Thu Jun 19 09:45:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD21A02A4 for ; Thu, 19 Jun 2014 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wD0RdmjMaK-8 for ; Thu, 19 Jun 2014 09:45:31 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 CB19B1A02A3 for ; Thu, 19 Jun 2014 09:45:30 -0700 (PDT) Received: from e7240.linfre (109.47.192.249) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 224541; Thu, 19 Jun 2014 18:45:17 +0200 From: Karsten Thomann To: v6ops@ietf.org Date: Thu, 19 Jun 2014 18:44:26 +0200 Message-ID: <1644362.f7SIiLMVUD@e7240.linfre> User-Agent: KMail/4.13.2 (Linux/3.15.0-33.g9194b64-desktop; KDE/4.13.2; x86_64; ; ) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart4513161.TKfXVXgdUc" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/02Y54Wxzwtbcb3OTgLoxAD_nBq8 Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:45:34 -0000 This is a multi-part message in MIME format. --nextPart4513161.TKfXVXgdUc Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, one short question regarding the Introduction: And there is an O (OtherConfig) flag, if set, indicating configure information other than addresses (e.g. DNS, Route .etc) is available through DHCPv6 configuration. What I've missed that it is possible to distribute any routing information in DHCPv6? Regards Karsten Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing: > Hi all, > > We've uploaded a new version of the draft. > > This version doesn't have much technical changes, but lots of re-wording and > some structure adjustment. 1. The test results are totally removed to the > Appendix, so that the main body is focusing on common problems, rather than > detailed behavior of some specific operating systems. Because the > implementation is always evolving, even different versions of the same > vendor might have different behavior. The point of the draft is to caution > the administrators, as long as the ambiguity exists in the standard, there > are possible problems they might face. The test results are only an > instance/proof of the ambiguity problem, it should not be the main content. > But as some people suggested, we'll refresh the test of newest operation > systems when the document could be published in the future. 2. The > structure was adjusted, to emphasize the problem statement as a standalone > Section 3. 3. Some titles were changed as well > 4. Not a few re-wording both in main body and the appendix > > Your comments are welcomed. > > Many thanks! > > Best regards, > Bing (on behalf of all co-authors) > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 18, 2014 4:33 PM > To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (Leo); Wendong Wang; > Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: New Version > Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > > > A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-ietf-v6ops-dhcpv6-slaac-problem > Revision: 01 > Title: DHCPv6/SLAAC Address Configuration Interaction Problem Statement > Document date: 2014-06-18 > Group: v6ops > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem-0 > 1.txt Status: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Diff: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-01 > > Abstract: > This document analyzes the DHCPv6/SLAAC interaction issue on host. > More specifically, the interaction is regarding with the A, M, and O > flags which are defined in ND protocol. Test results identify that > current implementations in operating systems have varied on > interpreting the flags. The variation might cause some operational > issues as described in the document. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --nextPart4513161.TKfXVXgdUc Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Hi,

 

one short question regarding the Introduction:

And there is an O (OtherConfig) flag, if set, indicating

   configure information other than addresses (e.g. DNS, Route .etc) is
   available through DHCPv6 configuration.
What I've missed that it is possible to distribute any routing information in DHCPv6?

Regards
Karsten

 

Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing:

> Hi all,

>

> We've uploaded a new version of the draft.

>

> This version doesn't have much technical changes, but lots of re-wording and

> some structure adjustment. 1. The test results are totally removed to the

> Appendix, so that the main body is focusing on common problems, rather than

> detailed behavior of some specific operating systems. Because the

> implementation is always evolving, even different versions of the same

> vendor might have different behavior. The point of the draft is to caution

> the administrators, as long as the ambiguity exists in the standard, there

> are possible problems they might face. The test results are only an

> instance/proof of the ambiguity problem, it should not be the main content.

> But as some people suggested, we'll refresh the test of newest operation

> systems when the document could be published in the future. 2. The

> structure was adjusted, to emphasize the problem statement as a standalone

> Section 3. 3. Some titles were changed as well

> 4. Not a few re-wording both in main body and the appendix

>

> Your comments are welcomed.

>

> Many thanks!

>

> Best regards,

> Bing (on behalf of all co-authors)

>

> -----Original Message-----

> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> Sent: Wednesday, June 18, 2014 4:33 PM

> To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (Leo); Wendong Wang;

> Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: New Version

> Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt

>

>

> A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt

> has been successfully submitted by Bing Liu and posted to the IETF

> repository.

>

> Name: draft-ietf-v6ops-dhcpv6-slaac-problem

> Revision: 01

> Title: DHCPv6/SLAAC Address Configuration Interaction Problem Statement

> Document date: 2014-06-18

> Group: v6ops

> Pages: 12

> URL:

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem-0

> 1.txt Status:

> https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/

> Htmlized:

> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Diff:

>

> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-01

>

> Abstract:

> This document analyzes the DHCPv6/SLAAC interaction issue on host.

> More specifically, the interaction is regarding with the A, M, and O

> flags which are defined in ND protocol. Test results identify that

> current implementations in operating systems have varied on

> interpreting the flags. The variation might cause some operational

> issues as described in the document.

>

>

>

>

> 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.

>

> The IETF Secretariat

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.org/mailman/listinfo/v6ops

 

--nextPart4513161.TKfXVXgdUc-- From nobody Thu Jun 19 09:50:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EF1A02AE for ; Thu, 19 Jun 2014 09:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rJBJG_2SgYjQ for ; Thu, 19 Jun 2014 09:50:46 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 4ECDB1A02A3 for ; Thu, 19 Jun 2014 09:50:46 -0700 (PDT) Received: from e7240.linfre (109.47.192.249) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 2643E7; Thu, 19 Jun 2014 18:50:34 +0200 From: Karsten Thomann To: v6ops@ietf.org Date: Thu, 19 Jun 2014 18:49:47 +0200 Message-ID: <9172495.94DC0fWb08@e7240.linfre> User-Agent: KMail/4.13.2 (Linux/3.15.0-33.g9194b64-desktop; KDE/4.13.2; x86_64; ; ) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 4 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/STeUBerI_5ZBxOdakXOJAK4Tfw8 Subject: Re: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:50:48 -0000 Hi, I prefer to merge the two documents to have a combined statement about the Problem and the current operational Guidelines, as it avoids to read two drafts/RFCs to provide an operator the description of the problem and what is recommended to use. Regards Karsten Am Mittwoch, 18. Juni 2014, 09:18:25 schrieb Liubing: > Hi all, > > Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC > interaction problem: Problem Statement: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > Operational Guidelines: > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 > > The Problem Statement document has been adopted by the WG (we just uploaded > a new version, details to see the other mail), and the Operational > Guidelines document was discussed in last ietf meeting in London. According > to the discussion, it seemed people were not clear about whether we need a > separate operational guidelines document or not. > > So let me enumerate possible next steps of the topic to see which you > prefer: 1. Move forward the PS document to be published, and possibly adopt > the Operational Guidelines document as well (Of course the draft needs > further revision and discussion). 2. Integrate the operations guidelines > into the PS draft, and move forward it to be published 3. Move forward the > PS document, and drop the operational guidelines document. > > Looking forward to your opinions. > Many thanks! > > Best regards, > Bing > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 19 09:53:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9D1A02A3 for ; Thu, 19 Jun 2014 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 OmYTaHUVcd_s for ; Thu, 19 Jun 2014 09:52:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2A91A0002 for ; Thu, 19 Jun 2014 09:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33581; q=dns/txt; s=iport; t=1403196775; x=1404406375; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=r/o6ZLcV8t3xufgdjbcj5Uhem4jraNSKBZK2z+JVW2g=; b=APEPmLpgs2BvHeU9cR4tiQdtzNMUQ1ZAln+WtvbdKXeWMyLUr+L9K7VF E+9ehknj4vA6At+tMm6mFVs8RyvSsj+TQS2bwjs/QK/6l1iGXUHlz//8Q Ks1xXeTQ5xPp+6lr0n2PxUSGzHasvo53CVZp3RRV2+Dv5RbHDyQG72Syx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwMALcUo1OtJA2E/2dsb2JhbABPCoJGR1JTB6oWAQEBAQEBBQGQFoFSAYc+AYEKFnWEAwEBAQMBAQEBKkEJBwcEAgEIEQQBAQsWAQYHJwsUCAEIAgQBEggBiDEICAXOKBeFYoNghFgrDx4KAQaDJ4EWBJwGkhWCAIFCgjA X-IronPort-AV: E=Sophos;i="5.01,508,1400025600"; d="scan'208,217";a="334339574" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jun 2014 16:52:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5JGqrZr005926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 16:52:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 11:52:53 -0500 From: "Bernie Volz (volz)" To: Karsten Thomann , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt Thread-Index: AQHPi93tvJ8e8SM8q0SmZzV/TGeK35t4pQ7Q Date: Thu, 19 Jun 2014 16:52:53 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5CE2FD@xmb-rcd-x04.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> <1644362.f7SIiLMVUD@e7240.linfre> In-Reply-To: <1644362.f7SIiLMVUD@e7240.linfre> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.85] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5CE2FDxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5zra9x28GFFEekssGAv8uLYQfkc Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:53:00 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5CE2FDxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > What I've missed that it is possible to distribute any routing informatio= n in DHCPv6? No ... Routing information for IPv6 is handled by Neighbor Discovery. See h= ttp://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/. There have been several attempts at this - see http://tools.ietf.org/html/d= raft-ietf-mif-dhcpv6-route-option for an example of one attempt. - Bernie From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Karsten Thomann Sent: Thursday, June 19, 2014 12:44 PM To: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcp= v6-slaac-problem-01.txt Hi, one short question regarding the Introduction: And there is an O (OtherConfig) flag, if set, indicating configure information other than addresses (e.g. DNS, Route .etc) is available through DHCPv6 configuration. What I've missed that it is possible to distribute any routing information = in DHCPv6? Regards Karsten Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing: > Hi all, > > We've uploaded a new version of the draft. > > This version doesn't have much technical changes, but lots of re-wording = and > some structure adjustment. 1. The test results are totally removed to the > Appendix, so that the main body is focusing on common problems, rather th= an > detailed behavior of some specific operating systems. Because the > implementation is always evolving, even different versions of the same > vendor might have different behavior. The point of the draft is to cautio= n > the administrators, as long as the ambiguity exists in the standard, ther= e > are possible problems they might face. The test results are only an > instance/proof of the ambiguity problem, it should not be the main conten= t. > But as some people suggested, we'll refresh the test of newest operation > systems when the document could be published in the future. 2. The > structure was adjusted, to emphasize the problem statement as a standalon= e > Section 3. 3. Some titles were changed as well > 4. Not a few re-wording both in main body and the appendix > > Your comments are welcomed. > > Many thanks! > > Best regards, > Bing (on behalf of all co-authors) > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Wednesday, June 18, 2014 4:33 PM > To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (Leo); Wendong Wang; > Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: New Version > Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > > > A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-ietf-v6ops-dhcpv6-slaac-problem > Revision: 01 > Title: DHCPv6/SLAAC Address Configuration Interaction Problem Statement > Document date: 2014-06-18 > Group: v6ops > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem= -0 > 1.txt Status: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem-= 01 > > Abstract: > This document analyzes the DHCPv6/SLAAC interaction issue on host. > More specifically, the interaction is regarding with the A, M, and O > flags which are defined in ND protocol. Test results identify that > current implementations in operating systems have varied on > interpreting the flags. The variation might cause some operational > issues as described in the document. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_000_489D13FBFA9B3E41812EA89F188F018E1B5CE2FDxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
> What I've missed that it is possible to distribute any routing informatio=
n in DHCPv6?

No … Routing inform= ation for IPv6 is handled by Neighbor Discovery. See http://www.isc.org/blo= gs/routing-configuration-over-dhcpv6-2/.

 <= /p>

There have been several a= ttempts at this – see h= ttp://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option for an exa= mple of one attempt.

 <= /p>

- =          Bernie=

 <= /p>

From: v6ops [m= ailto:v6ops-bounces@ietf.org] On Behalf Of Karsten Thomann
Sent: Thursday, June 19, 2014 12:44 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6o= ps-dhcpv6-slaac-problem-01.txt

 

Hi,

 

= one short question regarding the Introduction:

And there is an O (OtherConfig) flag, if set, indicating

   configure information oth=
er than addresses (e.g. DNS, Route .etc) is
   avail=
able through DHCPv6 configuration.
What I've missed t=
hat it is possible to distribute any routing information in DHCPv6?<=
o:p>
 
Regards
Karsten

 

= Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing:

> Hi all,

>

> We've uploaded a new version of the draft.=

>

> This version doesn't have much technical changes, but= lots of re-wording and

> some structure adjustment. 1. The test results are to= tally removed to the

> Appendix, so that the main body is focusing on common= problems, rather than

> detailed behavior of some specific operating systems.= Because the

> implementation is always evolving, even different ver= sions of the same

> vendor might have different behavior. The point of th= e draft is to caution

> the administrators, as long as the ambiguity exists i= n the standard, there

> are possible problems they might face. The test resul= ts are only an

> instance/proof of the ambiguity problem, it should no= t be the main content.

> But as some people suggested, we'll refresh the test = of newest operation

> systems when the document could be published in the f= uture. 2. The

> structure was adjusted, to emphasize the problem stat= ement as a standalone

> Section 3. 3. Some titles were changed as well

> 4. Not a few re-wording both in main body and the app= endix

>

> Your comments are welcomed.

>

> Many thanks!

>

> Best regards,

> Bing (on behalf of all co-authors)<= /p>

>

> -----Original Message-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Wednesday, June 18, 2014 4:33 PM

> To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (= Leo); Wendong Wang;

> Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: = New Version

> Notification for draft-ietf-v6ops-dhcpv6-slaac-proble= m-01.txt

>

>

> A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-p= roblem-01.txt

> has been successfully submitted by Bing Liu and poste= d to the IETF

> repository.

>

> Name: draft-ietf-v6ops-dhcpv6-slaac-problem

> Revision: 01

> Title: DHCPv6/SLAAC Address Configuration Interaction= Problem Statement

> Document date: 2014-06-18

> Group: v6ops

> Pages: 12

> URL:

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem-0=

> 1.txt Status:

> https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/=

> Htmlized:

> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Diff:

>

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem-01=

>

> Abstract:

> This document analyzes the DHCPv6/SLAAC interaction i= ssue on host.

> More specifically, the interaction is regarding with = the A, M, and O

> flags which are defined in ND protocol. Test results = identify that

> current implementations in operating systems have var= ied on

> interpreting the flags. The variation might cause som= e operational

> issues as described in the document.

>

>

>

>

> 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.

>

> The IETF Secretariat

>

> _______________________________________________<= /o:p>

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.or= g/mailman/listinfo/v6ops

 

--_000_489D13FBFA9B3E41812EA89F188F018E1B5CE2FDxmbrcdx04ciscoc_-- From nobody Thu Jun 19 10:58:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE61A02D3 for ; Thu, 19 Jun 2014 10:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 eYPT1G0uScGx for ; Thu, 19 Jun 2014 10:58:33 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 32D021A02B3 for ; Thu, 19 Jun 2014 10:58:33 -0700 (PDT) Received: from e7240.linfre (31.150.30.99) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 32FFF3; Thu, 19 Jun 2014 19:58:23 +0200 From: Karsten Thomann To: "Bernie Volz (volz)" Date: Thu, 19 Jun 2014 19:58:23 +0200 Message-ID: <3031947.AAuiVBMTjn@e7240.linfre> User-Agent: KMail/4.13.2 (Linux/3.15.0-33.g9194b64-desktop; KDE/4.13.2; x86_64; ; ) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5CE2FD@xmb-rcd-x04.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> <1644362.f7SIiLMVUD@e7240.linfre> <489D13FBFA9B3E41812EA89F188F018E1B5CE2FD@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mqDulH13QN_zuE_WuWaSEwq3d7A Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 17:58:35 -0000 That's the same link I already read, and that draft expired over one year ago. I know that there were several attempts to implement it, but I won't use it as an example, if it is until now not standardized. I would like to replace the route withfor example NTP, DNS Suffix or Bootserver... Am Donnerstag, 19. Juni 2014, 16:52:53 schrieb Bernie Volz: > > What I've missed that it is possible to distribute any routing information > > in DHCPv6? > No ... Routing information for IPv6 is handled by Neighbor Discovery. See > http://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/. > > There have been several attempts at this - see > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option for an > example of one attempt. > > > - Bernie > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Karsten Thomann > Sent: Thursday, June 19, 2014 12:44 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for > draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > > > Hi, > > > > one short question regarding the Introduction: > > And there is an O (OtherConfig) flag, if set, indicating > > configure information other than addresses (e.g. DNS, Route .etc) is > > available through DHCPv6 configuration. > > What I've missed that it is possible to distribute any routing information > in DHCPv6? > > > > Regards > > Karsten > > Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing: > > Hi all, > > > > > > > > We've uploaded a new version of the draft. > > > > > > > > This version doesn't have much technical changes, but lots of re-wording > > and > > > > some structure adjustment. 1. The test results are totally removed to the > > > > Appendix, so that the main body is focusing on common problems, rather > > than > > > > detailed behavior of some specific operating systems. Because the > > > > implementation is always evolving, even different versions of the same > > > > vendor might have different behavior. The point of the draft is to caution > > > > the administrators, as long as the ambiguity exists in the standard, there > > > > are possible problems they might face. The test results are only an > > > > instance/proof of the ambiguity problem, it should not be the main > > content. > > > > But as some people suggested, we'll refresh the test of newest operation > > > > systems when the document could be published in the future. 2. The > > > > structure was adjusted, to emphasize the problem statement as a standalone > > > > Section 3. 3. Some titles were changed as well > > > > 4. Not a few re-wording both in main body and the appendix > > > > > > > > Your comments are welcomed. > > > > > > > > Many thanks! > > > > > > > > Best regards, > > > > Bing (on behalf of all co-authors) > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org > > [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, June 18, 2014 4:33 PM > > > > To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (Leo); Wendong Wang; > > > > Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: New Version > > > > Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > > > > has been successfully submitted by Bing Liu and posted to the IETF > > > > repository. > > > > > > > > Name: draft-ietf-v6ops-dhcpv6-slaac-problem > > > > Revision: 01 > > > > Title: DHCPv6/SLAAC Address Configuration Interaction Problem Statement > > > > Document date: 2014-06-18 > > > > Group: v6ops > > > > Pages: 12 > > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem-> > 0 > > > > 1.txt Status: > > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > > > > Htmlized: > > > > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Diff: > > > > > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-01 > > > > > > > > Abstract: > > > > This document analyzes the DHCPv6/SLAAC interaction issue on host. > > > > More specifically, the interaction is regarding with the A, M, and O > > > > flags which are defined in ND protocol. Test results identify that > > > > current implementations in operating systems have varied on > > > > interpreting the flags. The variation might cause some operational > > > > issues as described in the document. > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 19 11:18:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621971A0161 for ; Thu, 19 Jun 2014 11:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ain_GLgczfpj for ; Thu, 19 Jun 2014 11:18:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5B91A026A for ; Thu, 19 Jun 2014 11:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6000; q=dns/txt; s=iport; t=1403201920; x=1404411520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J8+/WkG4+ail1Frz087Gu+Y42eQawoTV9N4pSbs8X40=; b=Um3vw8editCytZI3CfYtgn4741CfBw2cDe587fVteujp7GtcDmezDjTm B0C0NTJMqbED8Y5Qrj7ZPwhxdDxVQ/FXS3b4aO4IPuqS1y+aZg9BpTS9m grPshU8MJKu2tinnRbiwmdxtHJCHVWhXDj9aBrruDnEglq+x1h+nq3Bnj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQLAOMoo1OtJV2R/2dsb2JhbABPCoMNUlMHqhYBAQEBAQEFAZFohz8BgQsWdYQDAQEBAwEBAQEkEzQJAgwEAgEIEQQBAQsUCQcnCxQIAQgCBA4FCAGIMQgIBc4KF4Vig2CEWCsPIgcGgyeBFgScBpIVggCBQmyBRA X-IronPort-AV: E=Sophos;i="5.01,508,1400025600"; d="scan'208";a="54423265" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 19 Jun 2014 18:18:39 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5JIIcHT031557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 18:18:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 13:18:38 -0500 From: "Bernie Volz (volz)" To: Karsten Thomann Thread-Topic: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt Thread-Index: AQHPi93tvJ8e8SM8q0SmZzV/TGeK35t4pQ7QgABnJ4D//7C5YA== Date: Thu, 19 Jun 2014 18:18:36 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5CE8A5@xmb-rcd-x04.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BE9DD@nkgeml506-mbx.china.huawei.com> <1644362.f7SIiLMVUD@e7240.linfre> <489D13FBFA9B3E41812EA89F188F018E1B5CE2FD@xmb-rcd-x04.cisco.com> <3031947.AAuiVBMTjn@e7240.linfre> In-Reply-To: <3031947.AAuiVBMTjn@e7240.linfre> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Eo3lBBhv2Lubr5OHY5nsHhCbA38 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:18:46 -0000 That sounds fine. There are plenty of options to use as of potential interest to clients ... http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhc= pv6-parameters-2 - Bernie -----Original Message----- From: Karsten Thomann [mailto:karsten_thomann@linfre.de]=20 Sent: Thursday, June 19, 2014 1:58 PM To: Bernie Volz (volz) Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-ietf-v6ops-dhcp= v6-slaac-problem-01.txt That's the same link I already read, and that draft expired over one year a= go. I know that there were several attempts to implement it, but I won't use it= as an example, if it is until now not standardized. I would like to replace the route withfor example NTP, DNS Suffix or Bootse= rver... Am Donnerstag, 19. Juni 2014, 16:52:53 schrieb Bernie Volz: > > What I've missed that it is possible to distribute any routing=20 > > information in DHCPv6? > No ... Routing information for IPv6 is handled by Neighbor Discovery.=20 > See http://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/. >=20 > There have been several attempts at this - see=20 > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option for an=20 > example of one attempt. >=20 >=20 > - Bernie >=20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Karsten=20 > Thomann > Sent: Thursday, June 19, 2014 12:44 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for=20 > draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt >=20 >=20 > Hi, >=20 >=20 >=20 > one short question regarding the Introduction: >=20 > And there is an O (OtherConfig) flag, if set, indicating >=20 > configure information other than addresses (e.g. DNS, Route .etc)=20 > is >=20 > available through DHCPv6 configuration. >=20 > What I've missed that it is possible to distribute any routing=20 > information in DHCPv6? >=20 >=20 >=20 > Regards >=20 > Karsten >=20 > Am Mittwoch, 18. Juni 2014, 08:47:08 schrieb Liubing: > > Hi all, > >=20 > >=20 > >=20 > > We've uploaded a new version of the draft. > >=20 > >=20 > >=20 > > This version doesn't have much technical changes, but lots of=20 > > re-wording and > >=20 > > some structure adjustment. 1. The test results are totally removed=20 > > to the > >=20 > > Appendix, so that the main body is focusing on common problems,=20 > > rather than > >=20 > > detailed behavior of some specific operating systems. Because the > >=20 > > implementation is always evolving, even different versions of the=20 > > same > >=20 > > vendor might have different behavior. The point of the draft is to=20 > > caution > >=20 > > the administrators, as long as the ambiguity exists in the standard,=20 > > there > >=20 > > are possible problems they might face. The test results are only an > >=20 > > instance/proof of the ambiguity problem, it should not be the main=20 > > content. > >=20 > > But as some people suggested, we'll refresh the test of newest=20 > > operation > >=20 > > systems when the document could be published in the future. 2. The > >=20 > > structure was adjusted, to emphasize the problem statement as a=20 > > standalone > >=20 > > Section 3. 3. Some titles were changed as well > >=20 > > 4. Not a few re-wording both in main body and the appendix > >=20 > >=20 > >=20 > > Your comments are welcomed. > >=20 > >=20 > >=20 > > Many thanks! > >=20 > >=20 > >=20 > > Best regards, > >=20 > > Bing (on behalf of all co-authors) > >=20 > >=20 > >=20 > > -----Original Message----- > >=20 > > From: internet-drafts@ietf.org > > [mailto:internet-drafts@ietf.org] > >=20 > > Sent: Wednesday, June 18, 2014 4:33 PM > >=20 > > To: Ron Bonica; Ron Bonica; Xiangyang Gong; Liubing (Leo); Wendong=20 > > Wang; > >=20 > > Liubing (Leo); Xiangyang Gong; Wendong Wang Subject: New Version > >=20 > > Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > >=20 > >=20 > >=20 > >=20 > >=20 > > A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt > >=20 > > has been successfully submitted by Bing Liu and posted to the IETF > >=20 > > repository. > >=20 > >=20 > >=20 > > Name: draft-ietf-v6ops-dhcpv6-slaac-problem > >=20 > > Revision: 01 > >=20 > > Title: DHCPv6/SLAAC Address Configuration Interaction Problem=20 > > Statement > >=20 > > Document date: 2014-06-18 > >=20 > > Group: v6ops > >=20 > > Pages: 12 > >=20 > > URL: > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-pr > > oblem-> > 0 > >=20 > > 1.txt Status: > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-probl > > em/ > >=20 > > Htmlized: > >=20 > > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01 Dif= f: > >=20 > >=20 > >=20 > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-probl > > em-01 > >=20 > >=20 > >=20 > > Abstract: > >=20 > > This document analyzes the DHCPv6/SLAAC interaction issue on host. > >=20 > > More specifically, the interaction is regarding with the A, M, and O > >=20 > > flags which are defined in ND protocol. Test results identify that > >=20 > > current implementations in operating systems have varied on > >=20 > > interpreting the flags. The variation might cause some operational > >=20 > > issues as described in the document. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of=20 > > submission > >=20 > > until the htmlized version and diff are available at tools.ietf.org. > >=20 > >=20 > >=20 > > The IETF Secretariat > >=20 > >=20 > >=20 > > _______________________________________________ > >=20 > > v6ops mailing list > >=20 > > v6ops@ietf.org > >=20 > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 20 01:48:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AB61AD6B1 for ; Fri, 20 Jun 2014 01:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 yVAa5nFstKnU for ; Fri, 20 Jun 2014 01:48:42 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420B31A0351 for ; Fri, 20 Jun 2014 01:48:42 -0700 (PDT) Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 20 Jun 2014 08:48:39 +0000 Message-ID: <012501cf8c63$face2aa0$4001a8c0@gateway.2wire.net> From: t.petch To: Karsten Thomann , References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8BEA1E@nkgeml506-mbx.china.huawei.com> <9172495.94DC0fWb08@e7240.linfre> Date: Fri, 20 Jun 2014 09:44:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA006.eurprd07.prod.outlook.com (10.242.77.174) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 024847EE92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(53754006)(377454003)(51704005)(199002)(189002)(41574002)(66654002)(13464003)(50466002)(76482001)(77156001)(23756003)(50226001)(77982001)(62966002)(15202345003)(74502001)(79102001)(86362001)(93916002)(33646001)(46102001)(44736004)(92726001)(61296003)(66066001)(80022001)(77096002)(102836001)(42186005)(21056001)(87286001)(19580405001)(83322001)(14496001)(19580395003)(81342001)(81542001)(99396002)(101416001)(106356001)(83072002)(50986999)(85306003)(84392001)(81686999)(88136002)(76176999)(74662001)(4396001)(87976001)(89996001)(85852003)(62236002)(81816999)(44716002)(95666004)(15975445006)(20776003)(64706001)(47776003)(104166001)(105586002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gcrjB-p1EoJjBS2qfwCz3ZPlYaE Subject: Re: [v6ops] Next step of DHCP/SLAAC problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 08:48:45 -0000 Keep them separate. This topic has generated so much discussion over so many years that achieving rough consensus on it will be a challenge, perhaps impossible. A clear statement of the problem would be a small step forward. If and when guidelines are produced, then that will be all an operator needs, with the problem statement confined to history for students of how (not?) to design a protocol. And the problem statement alone needs more attention before it goes forward (IMO). Tom Petch ----- Original Message ----- From: "Karsten Thomann" To: Sent: Thursday, June 19, 2014 5:49 PM Subject: Re: [v6ops] Next step of DHCP/SLAAC problem > Hi, > > I prefer to merge the two documents to have a combined statement about the > Problem and the current operational Guidelines, as it avoids to read two > drafts/RFCs to provide an operator the description of the problem and what is > recommended to use. > > Regards > Karsten > > Am Mittwoch, 18. Juni 2014, 09:18:25 schrieb Liubing: > > Hi all, > > > > Currently we have 2 v6ops documents regarding with the DHCPv6/SLAAC > > interaction problem: Problem Statement: > > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem > > Operational Guidelines: > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-01 > > > > The Problem Statement document has been adopted by the WG (we just uploaded > > a new version, details to see the other mail), and the Operational > > Guidelines document was discussed in last ietf meeting in London. According > > to the discussion, it seemed people were not clear about whether we need a > > separate operational guidelines document or not. > > > > So let me enumerate possible next steps of the topic to see which you > > prefer: 1. Move forward the PS document to be published, and possibly adopt > > the Operational Guidelines document as well (Of course the draft needs > > further revision and discussion). 2. Integrate the operations guidelines > > into the PS draft, and move forward it to be published 3. Move forward the > > PS document, and drop the operational guidelines document. > > > > Looking forward to your opinions. > > Many thanks! > > > > Best regards, > > Bing > > > > _______________________________________________ > > 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 Fri Jun 20 08:14:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3376E1A0379; Fri, 20 Jun 2014 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nZHofBraddWb; Fri, 20 Jun 2014 08:13:59 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCF41A03A2; Fri, 20 Jun 2014 08:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5375; q=dns/txt; s=iport; t=1403277239; x=1404486839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zOVIdpkgKF6mM8shiGqmTy+gLiM+xETgJXZXZzIjTzQ=; b=DPefyQnpc++8LVKD6kDQgnKpqQ0IRrOZo7iNJsWr4Inh9bpWRXsrP2C5 kZsZ2n2B0U1VjLCnzwZUBYONNB+SZwiVghrwCpaCSFqJASc9cfZ714Duc /AWnLINV6osRHxfgR27iRtXCtv5MbCSgbkNHgY2HCnvbD2QPNGOH1Ozm6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgLABdPpFOtJV2Z/2dsb2JhbABZDoJ/UlMHqh8BAQEBAQEFAZFrhz8BgQkWdYQEAQEEAQEBawsQAgEIDiABFycLJQIEAQ0FCYg5CAXKZxeFYokUBxIBhDAEigaOAYI9gUOSF4MAQoFwBxci X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="54749790" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 20 Jun 2014 15:13:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5KFDvSP006527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 15:13:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 10:13:57 -0500 From: "Eric Vyncke (evyncke)" To: Tim Chown , Fernando Gont Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt Thread-Index: AQHPiCwRtt82smvvGECcJrApL1Pdv5t6mX0A Date: Fri, 20 Jun 2014 15:13:56 +0000 Message-ID: References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> In-Reply-To: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HVNfay4AYNeRkuHYbouYR3o_Vow Cc: "opsec@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:14:08 -0000 Fernando and Tim [Adding V6OPS in cc], Just re-read your I-D, here are some comments: - in the intro, 'van dijk' scanning via reverse DNS is no more 'recent' IMHO (update also section 4.4) - section 3.1.1 is yet another explanation of SLAAC & Co, I usually prefer avoiding repetition because they may introduce discrepancy or incoherencies =3D> remove those parts from the I-D? What about only talking about EUI-64 for example? - section 3.1.2 about DHCP, probably worth to say that some DHCP servers change the leased address(es) every few hours/days while others keep the same address(es) for years (even if the DHCP client went away for months) - section 3.3 about local mcast probe, a lot of networks (think large wifi) prevent direct WiFi client to WiFi client communication, or isolate hosts to communication to each others (hosting providers for example), so, this method of scanning is not always efficient. My default Mac OS/X configuration also prevents replying to any ICMP echo request... - section 3.4 not sure whether an inventory of existing scanning tools is valuable and this is an every changing world - 3.5 about mitigations, IPFIX can also help a lot with regard to detecting a scan - 3.5 I do not like the idea that error messages should not be generated when destination is a multicast... We need at least packet too big as well as parameter problem if we still dream about mcasted IPv6 video streaming - section 3.5 mitigations is in the middle of scanning techniques? Move it apart? Or build a mitigation section in all other scanning techniques? - section 4.4, should there be a recommendation to optionally change the reply code of reverse DNS servers? More work to be done in DNSEXT? Or DNSOP? - section 8 (ND cache), it is not only by 'login' but also available through SNMP (see also section 5 of draft-ietf-opsec-v6) - section 10 (routing protocols), not sure whether it can really help to scan except by providing the prefixes and in some case some router interface addresses (but trace route is there anyway) - appendix A, not sure whether it brings value May I suggest to add also IPFIX as it can aggregate the flows by source addresses, hence, getting a list of all addresses. See also section 2.5.1.2 of draft-ietf-opsec-v6. While at the beginning the I-D rightfully discusses about the two purposes of scanning (bad guys and good guys doing inventory), the main focus of the document appears to be on mitigation techniques (i.e. Prevent scanning) while very few on helping the good guys to build an inventory. May I also suggest that SAVI RFC 6620 also builds a cache of MAC/IPv6 without actively participating in the NDP exchange, so, it is also another source of information. You may also want to add simple traceroutes as they discover the IP addresses of routers. Lastly, and not sure about that point, should we drop a can full of worms in the document? Telling readers that using ULA and NAT is perhaps worse than the benefit? ;-) (it is Friday after all) -=E9ric On 15/06/14 01:54, "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 Operational Security Capabilities for >IP Network Infrastructure Working Group of the IETF. > > Title : Network Reconnaissance in IPv6 Networks > Authors : Fernando Gont > Tim Chown > Filename : draft-ietf-opsec-ipv6-host-scanning-04.txt > Pages : 31 > Date : 2014-06-14 > >Abstract: > IPv6 offers a much larger address space than that of its IPv4 > counterpart. An IPv6 subnet of size /64 can (in theory) accommodate > approximately 1.844 * 10^19 hosts, thus resulting in a much lower > host density (#hosts/#addresses) than is typical in IPv4 networks, > where a site typically has 65,000 or less unique addresses. As a > result, it is widely assumed that it would take a tremendous effort > to perform address scanning attacks against IPv6 networks, and > therefore brute-force IPv6 address scanning attacks have been > considered unfeasible. This document updates RFC 5157, which first > discussed this assumption, by providing further analysis on how > traditional address scanning techniques apply to IPv6 networks, and > exploring some additional techniques that can be employed for IPv6 > network reconnaissance. In doing so, this document formally > obsoletes RFC 5157. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-host-scanning-04 > > >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/ > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From nobody Mon Jun 23 07:57:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7B21A0653 for ; Mon, 23 Jun 2014 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 GvspgO5oB73W for ; Mon, 23 Jun 2014 07:56:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890E41B2AFA for ; Mon, 23 Jun 2014 07:56:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5NEunim027276 for ; Mon, 23 Jun 2014 16:56:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E5B56202B3A for ; Mon, 23 Jun 2014 16:58:43 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA592201086 for ; Mon, 23 Jun 2014 16:58:43 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5NEuZoe014568 for ; Mon, 23 Jun 2014 16:56:49 +0200 Message-ID: <53A84023.1060008@gmail.com> Date: Mon, 23 Jun 2014 16:56:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> In-Reply-To: <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ilU_FfE9p1vz-IXoj1vOP7lKPno Subject: Re: [v6ops] disconnected homenets (was: #2 Regarding isolated networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:57:01 -0000 Old email, sorry. Le 28/05/2014 23:24, Mark ZZZ Smith a écrit : [...] > The use case I like to imagine is a home user streaming a video from > their NAS to their TV over their internal network. That should use > ULAs so that a failure of their Internet connection/Global addressing > has no impact on watching their movie. If the movie failed because > the Internet connection/global addressing failed, that user will call > the ISP's helpdesk. But why should it fail! The home users internal > network is fine, it is only external connectivity that has failed. I hope this requirement is considered in the homenet architecture discussion. Too often the in-home Internet-disconnected network can not work internally. Alex > > People might argue that enterprise networks are different and they > are - they're simpler! Enterprise networks have technical staff on > hand that can troubleshoot networks and resolve faults. If you can > make IPv6 work seamlessly for home networks and their non-technical > "operators", you've solved the harder problem. Since enterprise > networks also value the same things home networks do - seamless > operation, robustness against failure, stable internal connectivity, > you've solved most of the enterprise network problems too. > >> It doesn't conform to RFC 7084 either, which clearly > >> states that "prefix(es) (and ULA prefix if configured...)" must be >> advertised. >> > > The precursor to 7084 (6204) was in development at the time, but it > wouldn't have helped because they were ignoring our feedback. > (Another CPE vendor was much better and almost too keen - they were > sending me new software to test within 24 hours after reporting an > IPv6 issue.) > > Regards, Mark. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 23 08:13:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF821B2B0B for ; Mon, 23 Jun 2014 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 M3_uT43HWcrB for ; Mon, 23 Jun 2014 08:12:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48981B2B19 for ; Mon, 23 Jun 2014 08:12:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5NFCJcV023753 for ; Mon, 23 Jun 2014 17:12:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3EDF2203DC1 for ; Mon, 23 Jun 2014 17:14:14 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3669B200B3B for ; Mon, 23 Jun 2014 17:14:14 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5NFC9a8025598 for ; Mon, 23 Jun 2014 17:12:19 +0200 Message-ID: <53A843C9.1040002@gmail.com> Date: Mon, 23 Jun 2014 17:12:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> In-Reply-To: <20140602013829.875B917236AC@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8Ni4NETuSICfS49x5t35EEoSRL4 Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:13:01 -0000 Le 02/06/2014 03:38, Mark Andrews a écrit : > > In message , Ted Lemon writes > : >> On Jun 1, 2014, at 9:01 PM, Lorenzo Colitti wrote: >>> And this problem is specific to IPv6 because...? >> >> IPv4 never claimed to provide ubiquitous support for multihoming. IPv6 kind >> of does. > > IPv6 adds multiple addresses on a interface. Hmmm, I have recollections of discovering multiple IPv4 addresses per interface before there was an IPv6 stack. Alex Multihoming support is > transport family agnostic. > > Multihoming support is supposed to be done in IPv4 applications > unless you have a very good reason to not support it or do you think > SHOULD means it is a optional part of IPv4? > > RFC 1123 > > 2.3 Applications on Multihomed hosts > > When the remote host is multihomed, the name-to-address > translation will return a list of alternative IP addresses. As > specified in Section 6.1.3.4, this list should be in order of > decreasing preference. Application protocol implementations > SHOULD be prepared to try multiple addresses from the list until > success is obtained. More specific requirements for SMTP are > given in Section 5.3.4. > > When the local host is multihomed, a UDP-based request/response > application SHOULD send the response with an IP source address > that is the same as the specific destination address of the UDP > request datagram. The "specific destination address" is defined > in the "IP Addressing" section of the companion RFC [INTRO:1]. > > Similarly, a server application that opens multiple TCP > connections to the same client SHOULD use the same local IP > address for all. > > All dual stack machines are multihomed. HE is basically about fast > failover when the destination addresses are unreachable. This is not > hard to do. From memory BSD 4.2 supported non blocking connect > which is all that is required from the IP stack to do fast failover. > > Mark > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 23 08:17:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9021B2971 for ; Mon, 23 Jun 2014 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 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.651, SPF_NEUTRAL=0.779] autolearn=ham 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 avTra088sM_h for ; Mon, 23 Jun 2014 08:17:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4F31B285C for ; Mon, 23 Jun 2014 08:17:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5NFHhPK000897; Mon, 23 Jun 2014 16:17:43 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5NFHhPK000897 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1403536663; bh=RyxxNmztcbRXfcJmCgUVN0sBo4k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ljtKs0RmrPEqZNVtSqrMllIGI+9/HOoOSgpG8daBTItFYgA5hvrdXqHE+UizZYEEK R7QVXdAMx6t2UrHCLrqDHl3vnEX13/4DLNYa4gxKMsK0hAahWkEG9YhqroqkhPzcIp idRu/5Z9D7ONykzx+vRRII3nh1uv8j8tAi/v5ITA= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5MGHg0546045361nC ret-id none; Mon, 23 Jun 2014 16:17:43 +0100 Received: from dhcp-162-206.wireless.soton.ac.uk (dhcp-162-206.wireless.soton.ac.uk [152.78.162.206] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5NFHg1X012315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 16:17:42 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tim Chown In-Reply-To: <53A84023.1060008@gmail.com> Date: Mon, 23 Jun 2014 16:18:15 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> <679AE942-6F18-4398-B490-E3B4BB0143AA@ecs.soton.ac.uk> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1874) X-smtpf-Report: sid=q5MGHg054604536100; tid=q5MGHg0546045361nC; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5NFHhPK000897 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7XZyJvjXuYtSj1gD__VvGBQc-hs Cc: v6ops@ietf.org Subject: Re: [v6ops] disconnected homenets (was: #2 Regarding isolated networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:17:53 -0000 On 23 Jun 2014, at 15:56, Alexandru Petrescu = wrote: > Old email, sorry. >=20 > Le 28/05/2014 23:24, Mark ZZZ Smith a =E9crit : > [...] >> The use case I like to imagine is a home user streaming a video from >> their NAS to their TV over their internal network. That should use >> ULAs so that a failure of their Internet connection/Global addressing >> has no impact on watching their movie. If the movie failed because >> the Internet connection/global addressing failed, that user will call >> the ISP's helpdesk. But why should it fail! The home users internal >> network is fine, it is only external connectivity that has failed. >=20 > I hope this requirement is considered in the homenet architecture = discussion. It is already covered, e.g. in 3.4.2. Tim >=20 > Too often the in-home Internet-disconnected network can not work = internally. >=20 > Alex >=20 >>=20 >> People might argue that enterprise networks are different and they >> are - they're simpler! Enterprise networks have technical staff on >> hand that can troubleshoot networks and resolve faults. If you can >> make IPv6 work seamlessly for home networks and their non-technical >> "operators", you've solved the harder problem. Since enterprise >> networks also value the same things home networks do - seamless >> operation, robustness against failure, stable internal connectivity, >> you've solved most of the enterprise network problems too. >>=20 >>> It doesn't conform to RFC 7084 either, which clearly >>=20 >>> states that "prefix(es) (and ULA prefix if configured...)" must be >>> advertised. >>>=20 >>=20 >> The precursor to 7084 (6204) was in development at the time, but it >> wouldn't have helped because they were ignoring our feedback. >> (Another CPE vendor was much better and almost too keen - they were >> sending me new software to test within 24 hours after reporting an >> IPv6 issue.) >>=20 >> Regards, Mark. >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 23 08:29:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DA01B2AF3 for ; Mon, 23 Jun 2014 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 7VqI-W-GIldl for ; Mon, 23 Jun 2014 08:29:50 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015C1B2AE7 for ; Mon, 23 Jun 2014 08:29:49 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 967371B81C7 for ; Mon, 23 Jun 2014 08:29:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8AFD3190071; Mon, 23 Jun 2014 08:29:49 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 08:29:44 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A843C9.1040002@gmail.com> Date: Mon, 23 Jun 2014 11:29:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pbWwhgBCw9uxO0L1CEbkzBwg0bk Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:29:51 -0000 On Jun 23, 2014, at 11:12 AM, Alexandru Petrescu = wrote: > Hmmm, I have recollections of discovering multiple IPv4 addresses per = interface before there was an IPv6 stack. It's certainly possible, but you will never see an IPv4 host do it = automatically. It has to be configured manually, and rarely makes much = sense other than for servers that simply need an additional public = identifier, or routers that need to do network address translation and = hence need an IP address on both the public and private subnets. From nobody Mon Jun 23 08:42:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B468C1B296A for ; Mon, 23 Jun 2014 08:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 bOYo5R6rIHx4 for ; Mon, 23 Jun 2014 08:41:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3D51A0384 for ; Mon, 23 Jun 2014 08:41:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5NFfuIv003262; Mon, 23 Jun 2014 17:41:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93A42204854; Mon, 23 Jun 2014 17:43:50 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 87DBA2047E2; Mon, 23 Jun 2014 17:43:50 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5NFfoHX013458; Mon, 23 Jun 2014 17:41:55 +0200 Message-ID: <53A84ABE.4060800@gmail.com> Date: Mon, 23 Jun 2014 17:41:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tim Chown References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> <679AE942-6F18-4398-B490-E3B4BB0143AA@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MsoMX2Zr1-jud76fh_6ghWX-C2E Cc: v6ops@ietf.org Subject: Re: [v6ops] disconnected homenets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:42:00 -0000 Le 23/06/2014 17:18, Tim Chown a écrit : > > On 23 Jun 2014, at 15:56, Alexandru Petrescu wrote: > >> Old email, sorry. >> >> Le 28/05/2014 23:24, Mark ZZZ Smith a écrit : >> [...] >>> The use case I like to imagine is a home user streaming a video from >>> their NAS to their TV over their internal network. That should use >>> ULAs so that a failure of their Internet connection/Global addressing >>> has no impact on watching their movie. If the movie failed because >>> the Internet connection/global addressing failed, that user will call >>> the ISP's helpdesk. But why should it fail! The home users internal >>> network is fine, it is only external connectivity that has failed. >> >> I hope this requirement is considered in the homenet architecture discussion. > > It is already covered, e.g. in 3.4.2. Thanks, it's already covered and makes sense. However, I have one minor issue with it. I do not understand why it requires an in-home Router to not advertise self as a default router whenever ULA prefixes are involved. > In cases where ULA prefixes are in use within a homenet but there is > no external IPv6 connectivity (and thus no GUAs in use), > recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed to > ensure correct operation, in particular where the homenet may be > dual-stack with IPv4 external connectivity. The use of the Route > Information Option described in [RFC4191] provides a mechanism to > advertise such more-specific ULA routes. (or I can't remember the earlier discussions). It may be that this requirement will make the in-home Hosts not capable of talking to each other simply because not implementing RFC4191. And, certainly RFC4191 is not for Router-to-Router communications. The benefit of the doubt. Alex > > Tim > >> >> Too often the in-home Internet-disconnected network can not work internally. >> >> Alex >> >>> >>> People might argue that enterprise networks are different and they >>> are - they're simpler! Enterprise networks have technical staff on >>> hand that can troubleshoot networks and resolve faults. If you can >>> make IPv6 work seamlessly for home networks and their non-technical >>> "operators", you've solved the harder problem. Since enterprise >>> networks also value the same things home networks do - seamless >>> operation, robustness against failure, stable internal connectivity, >>> you've solved most of the enterprise network problems too. >>> >>>> It doesn't conform to RFC 7084 either, which clearly >>> >>>> states that "prefix(es) (and ULA prefix if configured...)" must be >>>> advertised. >>>> >>> >>> The precursor to 7084 (6204) was in development at the time, but it >>> wouldn't have helped because they were ignoring our feedback. >>> (Another CPE vendor was much better and almost too keen - they were >>> sending me new software to test within 24 hours after reporting an >>> IPv6 issue.) >>> >>> Regards, Mark. >>> >>> _______________________________________________ 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 Mon Jun 23 09:14:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968F91B2BD4 for ; Mon, 23 Jun 2014 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 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.651, SPF_NEUTRAL=0.779] autolearn=ham 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 moX6UZhDYzhv for ; Mon, 23 Jun 2014 09:14:14 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D631B2C31 for ; Mon, 23 Jun 2014 09:05:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5NG5KIZ019843; Mon, 23 Jun 2014 17:05:20 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5NG5KIZ019843 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1403539522; bh=hppeB+yKPwbOwc8SCbs5RWwDoY8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=gwpfQ0BG9j8pK6qFvSdU21vGNiIbMFNyHVvnSPjHVX22rCNtOgsiSIqpXbJHTXsUq 5OfxDZ28c3/DTiINZ3EoN3JPJk1MI8eJwuooJdXvF7McVp6hMx6qNqGx5Ir2OyUouK 5936bOXE/1tjWwRm5dYSocWaw5JQr6RMygo4PHkY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q5MH5K0546046401Jm ret-id none; Mon, 23 Jun 2014 17:05:20 +0100 Received: from dhcp-162-206.wireless.soton.ac.uk (dhcp-162-206.wireless.soton.ac.uk [152.78.162.206] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5NG5Jgk021077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 17:05:20 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_BF986E82-4C09-48E7-9231-674CF5ECC721" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tim Chown In-Reply-To: <53A84ABE.4060800@gmail.com> Date: Mon, 23 Jun 2014 17:05:17 +0100 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> <679AE942-6F18-4398-B490-E3B4BB0143AA@ecs.soton.ac.uk> <53A84ABE.4060800@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1874) X-smtpf-Report: sid=q5MH5K054604640100; tid=q5MH5K0546046401Jm; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5NG5KIZ019843 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u7-Vwjew6cfIqj4S7vXWBrssKpA Cc: v6ops@ietf.org Subject: Re: [v6ops] disconnected homenets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 16:14:17 -0000 --Apple-Mail=_BF986E82-4C09-48E7-9231-674CF5ECC721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 HI, On 23 Jun 2014, at 16:41, Alexandru Petrescu = wrote: > Le 23/06/2014 17:18, Tim Chown a =E9crit : >>=20 >> On 23 Jun 2014, at 15:56, Alexandru Petrescu = wrote: >>=20 >>> Old email, sorry. >>>=20 >>> Le 28/05/2014 23:24, Mark ZZZ Smith a =E9crit : >>> [...] >>>> The use case I like to imagine is a home user streaming a video = from >>>> their NAS to their TV over their internal network. That should use >>>> ULAs so that a failure of their Internet connection/Global = addressing >>>> has no impact on watching their movie. If the movie failed because >>>> the Internet connection/global addressing failed, that user will = call >>>> the ISP's helpdesk. But why should it fail! The home users internal >>>> network is fine, it is only external connectivity that has failed. >>>=20 >>> I hope this requirement is considered in the homenet architecture = discussion. >>=20 >> It is already covered, e.g. in 3.4.2. >=20 > Thanks, it's already covered and makes sense. >=20 > However, I have one minor issue with it. >=20 > I do not understand why it requires an in-home Router to not advertise = self as a default router whenever ULA prefixes are involved. >=20 >> In cases where ULA prefixes are in use within a homenet but there = is >> no external IPv6 connectivity (and thus no GUAs in use), >> recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed = to >> ensure correct operation, in particular where the homenet may be >> dual-stack with IPv4 external connectivity. The use of the Route >> Information Option described in [RFC4191] provides a mechanism to >> advertise such more-specific ULA routes. >=20 > (or I can't remember the earlier discussions). >=20 > It may be that this requirement will make the in-home Hosts not = capable of talking to each other simply because not implementing = RFC4191. And, certainly RFC4191 is not for Router-to-Router = communications. >=20 > The benefit of the doubt. This topic was discussed a year or so ago in the context of the draft on = ULA usage, e.g. see http://www.ietf.org/mail-archive/web/v6ops/current/msg16405.html It would be good to ensure this is captured in=20 http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 Tim >=20 > Alex >=20 >>=20 >> Tim >>=20 >>>=20 >>> Too often the in-home Internet-disconnected network can not work = internally. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> People might argue that enterprise networks are different and they >>>> are - they're simpler! Enterprise networks have technical staff on >>>> hand that can troubleshoot networks and resolve faults. If you can >>>> make IPv6 work seamlessly for home networks and their non-technical >>>> "operators", you've solved the harder problem. Since enterprise >>>> networks also value the same things home networks do - seamless >>>> operation, robustness against failure, stable internal = connectivity, >>>> you've solved most of the enterprise network problems too. >>>>=20 >>>>> It doesn't conform to RFC 7084 either, which clearly >>>>=20 >>>>> states that "prefix(es) (and ULA prefix if configured...)" must be >>>>> advertised. >>>>>=20 >>>>=20 >>>> The precursor to 7084 (6204) was in development at the time, but it >>>> wouldn't have helped because they were ignoring our feedback. >>>> (Another CPE vendor was much better and almost too keen - they were >>>> sending me new software to test within 24 hours after reporting an >>>> IPv6 issue.) >>>>=20 >>>> Regards, Mark. >>>>=20 >>>> _______________________________________________ v6ops mailing list >>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_BF986E82-4C09-48E7-9231-674CF5ECC721 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 HI,

On 23 Jun 2014, at 16:41, = Alexandru Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:

Le 23/06/2014 17:18, Tim Chown a =E9crit :

On 23 Jun 2014, at 15:56, Alexandru Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:

Old email, = sorry.

Le 28/05/2014 23:24, Mark ZZZ Smith a =E9crit = :
[...]
The use case I like to imagine = is a home user streaming a video from
their NAS to their TV over = their internal network. That should use
ULAs so that a failure of = their Internet connection/Global addressing
has no impact on watching = their movie. If the movie failed because
the Internet = connection/global addressing failed, that user will call
the ISP's = helpdesk. But why should it fail! The home users internal
network is = fine, it is only external connectivity that has = failed.

I hope this requirement is considered in the = homenet architecture discussion.

It is already = covered, e.g. in 3.4.2.

Thanks, it's already covered = and makes sense.

However, I have one minor issue with = it.

I do not understand why it requires an in-home Router to not = advertise self as a default router whenever ULA prefixes are = involved.

  In cases where = ULA prefixes are in use within a homenet but there is
  no = external IPv6 connectivity (and thus no GUAs in use),
=   recommendations ULA-5, L-3 and L-4 in RFC 6204 should be = followed to
  ensure correct operation, in particular = where the homenet may be
  dual-stack with IPv4 external = connectivity.  The use of the Route
  Information = Option described in [RFC4191] provides a mechanism to
=   advertise such more-specific ULA = routes.

(or I can't remember the earlier = discussions).

It may be that this requirement will make the = in-home Hosts not capable of talking to each other simply because not = implementing RFC4191.  And, certainly RFC4191 is not for = Router-to-Router communications.

The benefit of the = doubt.

This topic was discussed a year or = so ago in the context of the draft on ULA usage, e.g. see
=

It would be good to ensure this is captured = in 

Tim


Alex


Tim


Too often the = in-home Internet-disconnected network can not work = internally.

Alex


People = might argue that enterprise networks are different and they
are - = they're simpler! Enterprise networks have technical staff on
hand = that can troubleshoot networks and resolve faults. If you can
make = IPv6 work seamlessly for home networks and their = non-technical
"operators", you've solved the harder problem. Since = enterprise
networks also value the same things home networks do - = seamless
operation, robustness against failure, stable internal = connectivity,
you've solved most of the enterprise network problems = too.

It doesn't conform to RFC 7084 = either, which clearly

states= that "prefix(es) (and ULA prefix if configured...)" must = be
advertised.


The precursor to 7084 (6204) = was in development at the time, but it
wouldn't have helped because = they were ignoring our feedback.
(Another CPE vendor was much better = and almost too keen - they were
sending me new software to test = within 24 hours after reporting an
IPv6 issue.)

Regards, = Mark.

_______________________________________________ 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






= --Apple-Mail=_BF986E82-4C09-48E7-9231-674CF5ECC721-- From nobody Mon Jun 23 11:59:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7BA1B2C14 for ; Mon, 23 Jun 2014 11:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 oMCi2634hfEd for ; Mon, 23 Jun 2014 11:59:21 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766C31B2CEF for ; Mon, 23 Jun 2014 11:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2452; q=dns/txt; s=iport; t=1403549782; x=1404759382; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gmiuq3ovjWin8Obkxrwo3YHFhCMTO3dWu4AC05c54RI=; b=W+6NgNv8jHStAjmpCzA2IdpKHN8ayAjjxpU7aZhU4Wi4yunMPho2EIFL IblmdgYiLfAC04iEOgQO7SaexOqbvRXYyYZQ35T5R7pdkOIjGPQC0J+MF +o/NrIT1WM+8ukjJ8pbEQyFQEpMANOGzZs8G1RlRa8yA/nIrqMAB9d2ZU Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FABZ3qFOtJA2B/2dsb2JhbABZgw1SWsQBAYEPFnWEAwEBAQMBZhgLAgEIRjIlAgQTCQWILAgNxG8Xjn4Fgy2BFgSSBoFBhwWBRYwbhgODQmyBRA X-IronPort-AV: E=Sophos;i="5.01,532,1400025600"; d="asc'?scan'208";a="55315219" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP; 23 Jun 2014 18:56:21 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5NIuLGl020880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 18:56:21 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 13:56:21 -0500 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: v6ops - Requested sessions have been scheduled for IETF 90 Thread-Index: AQHPjxTScC27rt9+gE+LXQ73EP+3hw== Date: Mon, 23 Jun 2014 18:56:21 +0000 Message-ID: <9F61A40E-7859-4037-8F4F-F6ACBC1DA06C@cisco.com> References: <20140623183115.30660.84275.idtracker@ietfa.amsl.com> In-Reply-To: <20140623183115.30660.84275.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_5270D72D-569E-4B86-9C8D-3CA4EC57A361"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HL4Ly2p13MEjUc33Ej5PmZSnmQI Subject: Re: [v6ops] v6ops - Requested sessions have been scheduled for IETF 90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:59:25 -0000 --Apple-Mail=_5270D72D-569E-4B86-9C8D-3CA4EC57A361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, we have been scheduled for two sessions. The schedule is not final = (it is published for somment at this point), but should be finalized = over the coming week or so. Hence, these might move. IETF 90 agenda may be found in several formats. Different strokes for = different folks, I suppose.=20 http://datatracker.ietf.org/meeting/agenda https://tools.ietf.org/agenda/90/ http://tools.ietf.org/calendar http://www.ietf.org/meeting/important-dates-2014.html On Jun 23, 2014, at 11:31 AM, IETF Secretariat wrote: > Dear Fred Baker, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > v6ops Session 1 (2:30:00) > Monday, Morning Session I 0900-1130 > Room Name: Canadian size: 1000 > --------------------------------------------- > v6ops Session 2 (2:00:00) > Tuesday, Afternoon Session II 1420-1620 > Room Name: Ontario size: 200 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 2 > Length of Session(s): 2.5 Hours, 2 Hours > Number of Attendees: 180 > Conflicts to Avoid:=20 > First Priority: sunset4 aqm 6man pcp homenet softwire opsec > Second Priority: lmap mif intarea iccrg tsvarea tsvwg >=20 >=20 >=20 > Special Requests: > Meetecho support is requested. Scheduling/non-conflict has primacy >=20 > Also need to not conflict with IRTF dclc > --------------------------------------------------------- >=20 --Apple-Mail=_5270D72D-569E-4B86-9C8D-3CA4EC57A361 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTqHhSbjEdbHIsm0MRArSpAKCiRku/FM/XlnaOkvRyoaX4ft060wCgiJ9D gLapuA1JlfahI7NR2x0yNt0= =C/bB -----END PGP SIGNATURE----- --Apple-Mail=_5270D72D-569E-4B86-9C8D-3CA4EC57A361-- From nobody Mon Jun 23 12:09:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D61B2C56; Mon, 23 Jun 2014 12:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 frX2Mpq1cqRa; Mon, 23 Jun 2014 12:09:32 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 CF5F11B2C33; Mon, 23 Jun 2014 12:09:06 -0700 (PDT) Received: from [190.246.228.61] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wz9bt-00084r-M9; Mon, 23 Jun 2014 21:08:58 +0200 Message-ID: <53A87B38.70000@si6networks.com> Date: Mon, 23 Jun 2014 16:08:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Tim Chown References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vRDuP09_n7nuk8usnCqvUFtWX2k Cc: "opsec@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:09:42 -0000 Hi, Eric, Thanks so much fr your feedback! Please find my responses in-line... On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > Just re-read your I-D, here are some comments: > - in the intro, 'van dijk' scanning via reverse DNS is no more 'recent' > IMHO (update also section 4.4) Agreed. Will do. > - section 3.1.1 is yet another explanation of SLAAC & Co, I usually prefer > avoiding repetition because they may introduce discrepancy or > incoherencies => remove those parts from the I-D? What about only talking > about EUI-64 for example? FWIW, the reason for which this part is included is that they key to doing host scanning in IPv6 is reducing the search space. -- that's why we essentially describe each of the algorithms that are commonly employed to generate the addresses, and then compute the approximate search space.... > - section 3.1.2 about DHCP, probably worth to say that some DHCP servers > change the leased address(es) every few hours/days while others keep the > same address(es) for years (even if the DHCP client went away for months) Good point. Will do. > - section 3.3 about local mcast probe, a lot of networks (think large > wifi) prevent direct WiFi client to WiFi client communication, or isolate > hosts to communication to each others (hosting providers for example), so, > this method of scanning is not always efficient. Good point, will add. > My default Mac OS/X configuration also prevents replying to any ICMP echo request... Wasn't aware about Mac OS... I expected them to follow FreeBSD in this respect. BTW, what version of Mac OS are you using? 8to check if this was changed for recent versions, or has been the case for a while now). > - section 3.4 not sure whether an inventory of existing scanning tools is > valuable and this is an every changing world IMHO, pointers to tools can be useful for folks willing to play/asses their networks -- particularly when many of the popular tools have little to no IPv6 support. > - 3.5 about mitigations, IPFIX can also help a lot with regard to > detecting a scan Anything better than "IPFIX [RFC7011] could also be of help to detect host scanning attacks"? > - 3.5 I do not like the idea that error messages should not be generated > when destination is a multicast... That's in the specs already (RFC4443) -- the only thing that I had proposed to change at the time was the response to unsupported options of type 10xxxxxx. > We need at least packet too big as well > as parameter problem if we still dream about mcasted IPv6 video streaming That would go against RFC4443. > - section 3.5 mitigations is in the middle of scanning techniques? Move it > apart? Or build a mitigation section in all other scanning techniques? Section 3.5 is a subsection of the "address scanning" section (section 3). It's true that the other sections do not have a mitigations subsections -- mostly becaus they boils down to "'It's impossible' or 'stop using that application'". Three options: 1) Leave as is 2) Have a top-level Section called "Mitigations", which would include the contents of Section 3.5, and also note that for the other vectors there's not much that you can do other than "stop using the orresponing protocol" (which, of course, in virtually all cases is not applicable). 3) Add a "Mitigations" subsection to each of the top-level sections... However, this would mess a bit with the index.. and many of such sections would have not much text. Thoughts? Me, I'd opt for 1 or 3 above. > - section 4.4, should there be a recommendation to optionally change the > reply code of reverse DNS servers? More work to be done in DNSEXT? Or > DNSOP? I had checked this before, and apparently "it was not possible". But please let me re-check again. > - section 8 (ND cache), it is not only by 'login' but also available > through SNMP (see also section 5 of draft-ietf-opsec-v6) Myabe we should ahve said "auth required" instead of "login"? -- The point was that if yu're an attacker, you might need credentials to access the aforementioned info. > - section 10 (routing protocols), not sure whether it can really help to > scan except by providing the prefixes and in some case some router > interface addresses (but trace route is there anyway) We might tweak the text noting that it might be of help for learning subnets rather than IIDs... > - appendix A, not sure whether it brings value FWIW, goal here was to provide some guidance for folks working n e.g. en-testing frameworks. - Most of the popular famewroks are rather clueless regarding how to learn the v6 addresses of potential targets (of couse, for v4 they do brute-forcing). > May I suggest to add also IPFIX as it can aggregate the flows by source > addresses, hence, getting a list of all addresses. See also section > 2.5.1.2 of draft-ietf-opsec-v6. Duble-checking: This would be for *legitimate* audits of *active* nodes, right? > While at the beginning the I-D rightfully discusses about the two purposes > of scanning (bad guys and good guys doing inventory), the main focus of > the document appears to be on mitigation techniques (i.e. Prevent > scanning) while very few on helping the good guys to build an inventory. > > May I also suggest that SAVI RFC 6620 also builds a cache of MAC/IPv6 > without actively participating in the NDP exchange, so, it is also another > source of information. Will do. > You may also want to add simple traceroutes as they discover the IP > addresses of routers. Good pint. > Lastly, and not sure about that point, should we drop a can full of worms > in the document? Telling readers that using ULA and NAT is perhaps worse > than the benefit? ;-) (it is Friday after all) Let's drop the can, but in a separate document. ;-)) (That aside, for scanning purposes, a diode-firewall would mostly do). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 23 16:00:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA60C1A03B1 for ; Mon, 23 Jun 2014 16:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 dCdB6QHJuCrP for ; Mon, 23 Jun 2014 16:00:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE671A03A4 for ; Mon, 23 Jun 2014 16:00:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WzDDt-0003Ky-7c; Mon, 23 Jun 2014 23:00:25 +0000 Date: Tue, 24 Jun 2014 08:00:24 +0900 Message-ID: From: Randy Bush To: Alexandru Petrescu In-Reply-To: <53A84023.1060008@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bQKCp0XPB9NVD6Wti6yLbOEbQNA Cc: V6 Ops List Subject: Re: [v6ops] disconnected homenets (was: #2 Regarding isolated networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:00:28 -0000 >> The use case I like to imagine is a home user streaming a video from >> their NAS to their TV over their internal network. That should use >> ULAs so that a failure of their Internet connection/Global addressing >> has no impact on watching their movie. this is yet another red herring (which this wg seems to love). if there is no external connection, whatever address prefix the LAN is using will still work. randy From nobody Mon Jun 23 16:12:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F171B2D2A for ; Mon, 23 Jun 2014 16:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 1MiUUxrYq_Dh for ; Mon, 23 Jun 2014 16:12:06 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D41A03B1 for ; Mon, 23 Jun 2014 16:12:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id EB0593493E0; Mon, 23 Jun 2014 23:12:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 822C8160059; Mon, 23 Jun 2014 23:18:42 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5267816004E; Mon, 23 Jun 2014 23:18:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8836618FC8C5; Tue, 24 Jun 2014 09:11:32 +1000 (EST) To: Randy Bush From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> In-reply-to: Your message of "Tue, 24 Jun 2014 08:00:24 +0900." Date: Tue, 24 Jun 2014 09:11:32 +1000 Message-Id: <20140623231132.8836618FC8C5@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vjhljPph_9MwYZkTQ9aNpo6ysK8 Cc: V6 Ops List Subject: Re: [v6ops] disconnected homenets (was: #2 Regarding isolated networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:12:08 -0000 In message , Randy Bush writes: > >> The use case I like to imagine is a home user streaming a video from > >> their NAS to their TV over their internal network. That should use > >> ULAs so that a failure of their Internet connection/Global addressing > >> has no impact on watching their movie. > > this is yet another red herring (which this wg seems to love). if there > is no external connection, whatever address prefix the LAN is using will > still work. But choosing the wrong one will potentially cause problems when the net reconnects. You can't safely keep using a PD assigned prefix after the lease has expired across a reconnect event. Note we have already agreed that there is no such thing as a permanently disconnected network. > randy > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 23 19:51:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6808F1B2812 for ; Mon, 23 Jun 2014 19:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 9ct_B75yxqXs for ; Mon, 23 Jun 2014 19:51:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AA31B2803 for ; Mon, 23 Jun 2014 19:51:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJC78937; Tue, 24 Jun 2014 02:51:54 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 03:51:53 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 10:51:48 +0800 From: "Liubing (Leo)" To: Tim Chown , Alexandru Petrescu Thread-Topic: [v6ops] disconnected homenets Thread-Index: AQHPjvn4gi2S87lwekmCkB9ETFGLgpt+VcmAgAE5GcA= Date: Tue, 24 Jun 2014 02:51:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8DD918@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <53A84023.1060008@gmail.com> <679AE942-6F18-4398-B490-E3B4BB0143AA@ecs.soton.ac.uk> <53A84ABE.4060800@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8DD918nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2AvCs0OZ56cbUSJR7RxO_kL059I Cc: "v6ops@ietf.org" Subject: Re: [v6ops] disconnected homenets X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 02:51:58 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8DD918nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tim, It may be that this requirement will make the in-home Hosts not capable of = talking to each other simply because not implementing RFC4191. And, certai= nly RFC4191 is not for Router-to-Router communications. The benefit of the doubt. This topic was discussed a year or so ago in the context of the draft on UL= A usage, e.g. see http://www.ietf.org/mail-archive/web/v6ops/current/msg16405.html It would be good to ensure this is captured in http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 [Bing] The default route had been mentioned in Section 3.2 and Section 3.3.= But we didn't mentioned RFC4191 relevant consideration, I think it would b= e good to add some text. Thanks for your remind. Best regards, Bing Tim Alex --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8DD918nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tim,

 = ;


It may be that this requirement will make the in-home Hosts not capable of = talking to each other simply because not implementing RFC4191.  And, c= ertainly RFC4191 is not for Router-to-Router communications.

The benefit of the doubt.

 

This topic was discussed a year= or so ago in the context of the draft on ULA usage, e.g. see

 

It would be good to ensure this= is captured in 

&n= bsp;

[Bing] The= default route had been mentioned in Section 3.2 and Section 3.3. But we di= dn’t mentioned RFC4191 relevant consideration, I think it would be good to add some text.

Thanks for= your remind.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

Tim




Alex


--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8DD918nkgeml506mbxchi_-- From nobody Mon Jun 23 21:38:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F97F1B2825 for ; Mon, 23 Jun 2014 21:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 IEZ0GIpLcQae for ; Mon, 23 Jun 2014 21:38:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7AF1A03F4 for ; Mon, 23 Jun 2014 21:38:17 -0700 (PDT) Received: (qmail 11498 invoked from network); 23 Jun 2014 21:38:16 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jun 2014 21:38:16 -0700 Date: Mon, 23 Jun 2014 21:38:16 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Fernando Gont In-Reply-To: <53A87B38.70000@si6networks.com> Message-ID: References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> <53A87B38.70000@si6networks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i23VkP_H4d1L5NeQfMSI_0Vb6lI Cc: "opsec@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 04:38:19 -0000 On Mon, 23 Jun 2014, Fernando Gont wrote: > On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > > - 3.5 I do not like the idea that error messages should not be generated > > when destination is a multicast... > > That's in the specs already (RFC4443) -- the only thing that I had > proposed to change at the time was the response to unsupported options > of type 10xxxxxx. > > > We need at least packet too big as well > > as parameter problem if we still dream about mcasted IPv6 video streaming > > That would go against RFC4443. That's not what I read. Section 2.4(e) says: (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: (e.1) An ICMPv6 error message. (e.2) An ICMPv6 redirect message [IPv6-DISC]. (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest- order two bits set to 10). Seems like PTB is always allowed/required. //cmh From nobody Tue Jun 24 03:10:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE091B29C4 for ; Tue, 24 Jun 2014 03:10:26 -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 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 ghYFXNfYXqyl for ; Tue, 24 Jun 2014 03:10:24 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 507641B29BD for ; Tue, 24 Jun 2014 03:10:22 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OAACK6088143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 11:10:13 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <53A94E88.6070101@foobar.org> Date: Tue, 24 Jun 2014 11:10:16 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon , Alexandru Petrescu References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> In-Reply-To: <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SAPWATt9ffgA0Rq8Coko0Z1vXO0 Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:10:26 -0000 On 23/06/2014 16:29, Ted Lemon wrote: > It's certainly possible, but you will never see an IPv4 host do it > automatically. It has to be configured manually, and rarely makes much > sense other than for servers that simply need an additional public > identifier, or routers that need to do network address translation and > hence need an IP address on both the public and private subnets. ...or any of the situations where it might make sense in the same way that it might make sense for ipv6, which is why all major operating systems have GUI access to make it easy to add secondary ipv4 addresses on any interface. Secondary ipv4 addresses are completely mainstream, even if we all used them before they were cool. Nick From nobody Tue Jun 24 03:20:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7A1B29BF for ; Tue, 24 Jun 2014 03:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 svohh3nVg1r6 for ; Tue, 24 Jun 2014 03:20:02 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1CB1B29BD for ; Tue, 24 Jun 2014 03:20:02 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 5C356349444; Tue, 24 Jun 2014 10:20:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EFF9F16005B; Tue, 24 Jun 2014 10:27:09 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B8577160059; Tue, 24 Jun 2014 10:27:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DBF2A192F4EE; Tue, 24 Jun 2014 20:19:57 +1000 (EST) To: Nick Hilliard From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> In-reply-to: Your message of "Tue, 24 Jun 2014 11:10:16 +0100." <53A94E88.6070101@foobar.org> Date: Tue, 24 Jun 2014 20:19:57 +1000 Message-Id: <20140624101957.DBF2A192F4EE@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PCv8_M577f_d3WotctE-u42mIh0 Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:20:06 -0000 In message <53A94E88.6070101@foobar.org>, Nick Hilliard writes: > On 23/06/2014 16:29, Ted Lemon wrote: > > It's certainly possible, but you will never see an IPv4 host do it > > automatically. It has to be configured manually, and rarely makes much > > sense other than for servers that simply need an additional public > > identifier, or routers that need to do network address translation and > > hence need an IP address on both the public and private subnets. > > ...or any of the situations where it might make sense in the same way that > it might make sense for ipv6, which is why all major operating systems have > GUI access to make it easy to add secondary ipv4 addresses on any > interface. Secondary ipv4 addresses are completely mainstream, even if we > all used them before they were cool. Yet there is equipment on sale as I write that doesn't support them. It is not a feature you can depend upon being present in *all* the equipment connected to the network. > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jun 24 03:39:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34E91B299F for ; Tue, 24 Jun 2014 03:39:05 -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 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 vk5Jn9wBlPZA for ; Tue, 24 Jun 2014 03:38:59 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 3D25C1B28FB for ; Tue, 24 Jun 2014 03:38:56 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OAck4O088291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 11:38:46 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <53A95539.6080901@foobar.org> Date: Tue, 24 Jun 2014 11:38:49 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <20140624101957.DBF2A192F4EE@rock.dv.isc.org> In-Reply-To: <20140624101957.DBF2A192F4EE@rock.dv.isc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j9Vt8wKncdCObHNG6GroNOzT0DA Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:39:06 -0000 On 24/06/2014 11:19, Mark Andrews wrote: > Yet there is equipment on sale as I write that doesn't support them. Mark, you quoted a single Brother HL-4040CN which ok, I'm sure it doesn't have a gui option to support multiple ipv4 addresses, but I'd also suspect that it uses a linux kernel underneath the glitz and that this is purely a UI issue. Either way, Mark Smith's original point: > RFC1918s have provided that internal connectivity robustness to both home > networks and enterprise networks. Of course the drawback is that in IPv4 it > is binary - hosts either have RFC1918s or public addresses, so if you have > RFC1918s you have to use NAT to access external destinations on the > Internet. ... is demonstrably incorrect on a matter of fact, and can we just accept that supporting multiple IPv4 addresses on the same interface is normal, mainstream and widely supported, including on consumer grade hardware? And then can we move on? thanks, Nick From nobody Tue Jun 24 04:28:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016171A03B5 for ; Tue, 24 Jun 2014 04:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 hTzeAbeTOzA8 for ; Tue, 24 Jun 2014 04:28:32 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 88FC71B27E6 for ; Tue, 24 Jun 2014 04:28:31 -0700 (PDT) Received: (qmail 4676 invoked from network); 24 Jun 2014 11:28:29 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Jun 2014 11:28:29 -0000 Date: Tue, 24 Jun 2014 13:27:14 +0200 (CEST) Message-Id: <20140624.132714.41725023.sthaug@nethelp.no> To: nick@foobar.org From: sthaug@nethelp.no In-Reply-To: <53A94E88.6070101@foobar.org> References: <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5OOvX3X7obYL8WkprQR4D_PNNjs Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 11:28:35 -0000 > > It's certainly possible, but you will never see an IPv4 host do it > > automatically. It has to be configured manually, and rarely makes much > > sense other than for servers that simply need an additional public > > identifier, or routers that need to do network address translation and > > hence need an IP address on both the public and private subnets. > > ...or any of the situations where it might make sense in the same way that > it might make sense for ipv6, which is why all major operating systems have > GUI access to make it easy to add secondary ipv4 addresses on any > interface. Secondary ipv4 addresses are completely mainstream, even if we > all used them before they were cool. Absolutely agreed. We tend to put each service on its own IP address - makes it much easier to move the service later without affecting other services on the same server. Steinar Haug, AS 2116 From nobody Tue Jun 24 06:14:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65451B294D for ; Tue, 24 Jun 2014 06:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 xR_gIIV5vLoL for ; Tue, 24 Jun 2014 06:14:46 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEEC1B2942 for ; Tue, 24 Jun 2014 06:14:46 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 670ED1B806B for ; Tue, 24 Jun 2014 06:14:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 49E30190071; Tue, 24 Jun 2014 06:14:46 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 06:14:40 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A94E88.6070101@foobar.org> Date: Tue, 24 Jun 2014 09:14:38 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DlCpJJ_WRhDhgryJ5qDbo0SMzwA Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:14:48 -0000 On Jun 24, 2014, at 6:10 AM, Nick Hilliard wrote: > ...or any of the situations where it might make sense in the same way = that > it might make sense for ipv6, which is why all major operating systems = have > GUI access to make it easy to add secondary ipv4 addresses on any > interface. Secondary ipv4 addresses are completely mainstream, even = if we > all used them before they were cool. So e.g. you would use a secondary IPv4 address on a host to do = multihoming? And you would argue that this works sufficiently well = that we should treat it as commonplace? From nobody Tue Jun 24 07:23:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ABC1B2A47 for ; Tue, 24 Jun 2014 07:23:27 -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 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 CUiD6UxW8zq5 for ; Tue, 24 Jun 2014 07:23:25 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 07D081B2A22 for ; Tue, 24 Jun 2014 07:23:24 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OENKg4089507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 15:23:20 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A989D8.2080704@foobar.org> Date: Tue, 24 Jun 2014 15:23:20 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> In-Reply-To: <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hicaKuYWPBqBCR2MFHUj2_R7KGE Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:23:27 -0000 On 24/06/2014 14:14, Ted Lemon wrote: > So e.g. you would use a secondary IPv4 address on a host to do > multihoming? your question is badly specified because you don't say what you mean by "multihoming" and it's not obvious from the context. If you're referring to local connectivity on the same l2 domain where there are multiple prefixes used on that lan, then adding multiple ipv4 addresses to the same interface works without problems and has always done so. If you're referring to something else which involves routing the traffic to a different network by selecting a next-hop gateway depending on the host address used, then that works as well as in ipv6, which is to say not at all. Nick From nobody Tue Jun 24 09:02:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AE11B2E2B for ; Tue, 24 Jun 2014 09:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ITknjedgHxg8 for ; Tue, 24 Jun 2014 09:02:08 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1021B2E2E for ; Tue, 24 Jun 2014 08:55:41 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 12E5D1B8034 for ; Tue, 24 Jun 2014 08:55:41 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0C8C1190071; Tue, 24 Jun 2014 08:55:41 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 08:55:41 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A95539.6080901@foobar.org> Date: Tue, 24 Jun 2014 11:55:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <539A0F8F-8B18-40CE-A39F-F83448E41B63@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <20140624101957.DBF2A192F4EE@rock.dv.isc.org> <53A95539.6080901@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fu1sxxp1xN-y5zdHIpoRBBRJKhw Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:02:13 -0000 On Jun 24, 2014, at 6:38 AM, Nick Hilliard wrote: > ... is demonstrably incorrect on a matter of fact, and can we just = accept > that supporting multiple IPv4 addresses on the same interface is = normal, > mainstream and widely supported, including on consumer grade hardware? = And > then can we move on? thanks, Nick, it's certainly "supported," but it's not configured automatically = (nor is there a standard mechanism for doing so), and it doesn't support = multihoming or intelligent source address selection. From nobody Tue Jun 24 09:40:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671721B2B5A for ; Tue, 24 Jun 2014 09:40:55 -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 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 nkgsM2-ia3jQ for ; Tue, 24 Jun 2014 09:40:53 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 374AC1B2B49 for ; Tue, 24 Jun 2014 09:40:52 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OGenxK090626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 17:40:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A9AA10.7080607@foobar.org> Date: Tue, 24 Jun 2014 17:40:48 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <20140624101957.DBF2A192F4EE@rock.dv.isc.org> <53A95539.6080901@foobar.org> <539A0F8F-8B18-40CE-A39F-F83448E41B63@nominum.com> In-Reply-To: <539A0F8F-8B18-40CE-A39F-F83448E41B63@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jo7fgwTWFEfoCEaAxRzsq0TSvQg Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:40:55 -0000 On 24/06/2014 16:55, Ted Lemon wrote: > Nick, it's certainly "supported," but it's not configured automatically > (nor is there a standard mechanism for doing so), and it doesn't support > multihoming or intelligent source address selection. you still haven't defined what you mean by multihoming in this context. ipv4 source address selection is handled by vendor implementations and the ietf has no particular guidelines on how it should be managed. Possibly there is a correlation between these two things. Nick From nobody Tue Jun 24 10:38:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245D31B2E68 for ; Tue, 24 Jun 2014 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 20V5zxRRCagL for ; Tue, 24 Jun 2014 10:38:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2126C1B2D67 for ; Tue, 24 Jun 2014 10:38:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DE86B1B81D5 for ; Tue, 24 Jun 2014 10:38:08 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CAE3A190071; Tue, 24 Jun 2014 10:38:08 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 10:38:08 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A989D8.2080704@foobar.org> Date: Tue, 24 Jun 2014 13:38:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C0iUpQdB7ugTL6zcJmc0LEv6ABI Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 17:38:12 -0000 On Jun 24, 2014, at 10:23 AM, Nick Hilliard wrote: > If you're referring to something else which involves routing the = traffic to > a different network by selecting a next-hop gateway depending on the = host > address used, then that works as well as in ipv6, which is to say not = at all. This isn't really true. If your routing is set up right and source = address selection is configured correctly, you can do multihoming. = It's not clear that every device supports it, and it's not particularly = easy to make it work at the moment, but it is _certainly_ possible to = make it work. The same is not true of IPv4, and it's unlikely we (the = IETF) will do the work to fix that, because nobody (that I know of) = cares. From nobody Tue Jun 24 11:49:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850CE1B2BE8 for ; Tue, 24 Jun 2014 11:49:58 -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 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 AuxDoMccU_eZ for ; Tue, 24 Jun 2014 11:49:56 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 68C6F1A039C for ; Tue, 24 Jun 2014 11:49:53 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OInkml091173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 19:49:47 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A9C84A.8020304@foobar.org> Date: Tue, 24 Jun 2014 19:49:46 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/50QAjiASAV4D4le6ps-veMaxDxU Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 18:49:58 -0000 On 24/06/2014 18:38, Ted Lemon wrote: > This isn't really true. If your routing is set up right and source > address selection is configured correctly, you can do multihoming. I'm trying to read between the lines here and am going to assume that you're talking about end hosts with multiple addresses being contactable over different links from other networks where next-hop interface selection based on destination addresses (which is defined for ipv4) is used. > It's not clear that every device supports it, and it's not particularly > easy to make it work at the moment, but it is _certainly_ possible to > make it work. Most people need protocols which just work rather than protocols which we're assured that it's possible that they can be made to work, assuming that there is device support and that the routing is set up correctly. And that address selection is configured correctly. And that you're doing one-legged cartwheels on nights where there is both a full moon and planetary alignment and you're waving dead chickens in the air. I've spend enough of my career dealing with that level of brokenness and it's not worth it by any widely-accepted metric: financial / technical / etc. > The same is not true of IPv4, and it's unlikely we (the > IETF) will do the work to fix that, because nobody (that I know of) > cares. indeed because it's not necessary. People who need reliable multihoming for either ipv4 or ipv6 will acquire an address assignment or allocation and will use that. It just works, and the people who do it don't much mind the small amount of global blood-letting it causes. Nick From nobody Tue Jun 24 12:46:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69F1A03B4 for ; Tue, 24 Jun 2014 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 6VpqGIhV1NrX for ; Tue, 24 Jun 2014 12:46:50 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831901A03A9 for ; Tue, 24 Jun 2014 12:46:40 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CF52460A8F for ; Tue, 24 Jun 2014 21:46:38 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8F94D602AA for ; Tue, 24 Jun 2014 21:46:38 +0200 (CEST) Received: (qmail 72154 invoked by uid 1007); 24 Jun 2014 21:46:38 +0200 Date: Tue, 24 Jun 2014 21:46:38 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20140624194638.GZ46558@Space.Net> References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A9C84A.8020304@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xqtD2UvW9b5TZLmty8sQLWFuZKQ Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:46:52 -0000 Hi, On Tue, Jun 24, 2014 at 07:49:46PM +0100, Nick Hilliard wrote: > indeed because it's not necessary. People who need reliable multihoming > for either ipv4 or ipv6 will acquire an address assignment or allocation > and will use that. It just works, and the people who do it don't much mind > the small amount of global blood-letting it causes. Mainly because some people keep repeating that BGP+PI is the only available option. Like, religiously. You're not *that* old yet. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jun 24 12:49:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD81A0410 for ; Tue, 24 Jun 2014 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6] autolearn=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 NDzfmoGTjD6m for ; Tue, 24 Jun 2014 12:49:30 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 528B61A0414 for ; Tue, 24 Jun 2014 12:49:26 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OJnNIi091799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 20:49:23 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A9D643.6040100@foobar.org> Date: Tue, 24 Jun 2014 20:49:23 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gert Doering References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> <20140624194638.GZ46558@Space.Net> In-Reply-To: <20140624194638.GZ46558@Space.Net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r80qZPMPNidzGFF0MwckVPGfpXs Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:49:31 -0000 On 24/06/2014 20:46, Gert Doering wrote: > Mainly because some people keep repeating that BGP+PI is the only available > option. Like, religiously. You're not *that* old yet. ...then point me to another option which works reliably. Nick From nobody Tue Jun 24 12:57:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EBA1A0387 for ; Tue, 24 Jun 2014 12:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 p0womottqnOu for ; Tue, 24 Jun 2014 12:57:22 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D351A03CB for ; Tue, 24 Jun 2014 12:57:22 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E68AC60AD3 for ; Tue, 24 Jun 2014 21:57:20 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id ABC5C6025B for ; Tue, 24 Jun 2014 21:57:20 +0200 (CEST) Received: (qmail 93545 invoked by uid 1007); 24 Jun 2014 21:57:20 +0200 Date: Tue, 24 Jun 2014 21:57:20 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20140624195720.GA46558@Space.Net> References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> <20140624194638.GZ46558@Space.Net> <53A9D643.6040100@foobar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ULYbezmuIpuQrBKU" Content-Disposition: inline In-Reply-To: <53A9D643.6040100@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BgBU9_6sBFWEiyDWWDe9o3y5t14 Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:57:24 -0000 --ULYbezmuIpuQrBKU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jun 24, 2014 at 08:49:23PM +0100, Nick Hilliard wrote: > On 24/06/2014 20:46, Gert Doering wrote: > > Mainly because some people keep repeating that BGP+PI is the only avail= able > > option. Like, religiously. You're not *that* old yet. >=20 > ...then point me to another option which works reliably. "reliably" in itself is already a red herring. Protecting you against *what*, and under which assumptions? For "I want my facebook and youtube and e-mail to work, even if one of=20 my ISPs goes belly-up!", homenet + dual-prefix works. It will not give you perfectness just yet, aka "source address selection will not=20 pick the best source IP for whatever definition of 'best'", but MIF is working on optimizing this. Your sessions will die if you are actively=20 using the ISP that just died on you, but mp-tcp is one *demonstrably working* way to handle that, get much faster session failover that BGP=20 would give you (seconds, not minutes). For "I need to run a datacenter full of stuff that need to have stable addresses, no matter what happens elsewhere", I give you that BGP+PI (or whatever other source of "your addresses") is a much better and more reliable approach. But for a barber shop that just wants their internet radio to be there all the time, it's completely wrong. Short form. Longer discussion of the options and missing bits upstream in this very thread. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ULYbezmuIpuQrBKU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU6nYIN9WwGXkzn/FAQI+cg//QAz2A6nI8PoP1myfG7NFVRUBSgG6/2Ge zWPXHlmcDHOPbZe1TyQjPha48hdVn/iyuSkQdfkvRyRmsluZXUoNpxtAjPuPn/Cf V7toN/pRCYI+5+Gn3leRqfhRhIhnWpCIlpk375d4tLyH0GSu+3gJt5UqSRUSFEFR AAjn7teLSpdQIbQWHa9ZhKUhExA3Xh9T+ZafgelmBHXHMW4/40A849l8CzlvnrRh UyjgyZK2kVq7+cG7fC0QPE/OnG4j+U8WuqIW0zK0/D6p3f5tiBPddQCDrVxB5+g/ mOyiqEGfFPxrF58DRoGZJBjohhnTWQPZ/XJw70i4xUTp34IbAUW/xbxl9sUjSFmx 2ovMNryPzKkw2W93bWv+ag+buvHx6aj6GzFwq2H9NFkKpg2GhFUzEo+5omj4Sqz4 KcQAcWsrfUFcORJSfo7CCs8C9JZ2Xvw7gL9X112A1r2ZoxG0m2vRWqtYh+B3hlfT hUjafWzsPSxolECSMqaMGbp+PXfmtKVxTBOnvdofZCqmGclxjOQiX032dq94amq+ NIeQ1XxWhtsjLHJ3riQjOHCuUQfOIi0sRYZRFn0rtgADJRQE3boSiyjYUNEqYMCl HKGrr4JrNmyGvXhptjcsQVaWLMA7m4MzAfVa0WvehJ7qj7nYvoIS1mIQbUkXcO1/ DZ9irEWYs+M= =HLaj -----END PGP SIGNATURE----- --ULYbezmuIpuQrBKU-- From nobody Tue Jun 24 13:43:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5B1B2884 for ; Tue, 24 Jun 2014 13:43:39 -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 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 3ssujhqS5QXv for ; Tue, 24 Jun 2014 13:43:35 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 D502E1B2813 for ; Tue, 24 Jun 2014 13:43:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OKhVAZ092056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 21:43:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A9E2F3.6080206@foobar.org> Date: Tue, 24 Jun 2014 21:43:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gert Doering References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> <20140624194638.GZ46558@Space.Net> <53A9D643.6040100@foobar.org> <20140624195720.GA46558@Space.Net> In-Reply-To: <20140624195720.GA46558@Space.Net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/veA8RMCDZ0-nVGFXL_mo8wTsFt0 Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:43:39 -0000 On 24/06/2014 20:57, Gert Doering wrote: > For "I want my facebook and youtube and e-mail to work, even if one of > my ISPs goes belly-up!", homenet + dual-prefix works. It will not give > you perfectness just yet, aka "source address selection will not > pick the best source IP for whatever definition of 'best'", but MIF is > working on optimizing this. Your sessions will die if you are actively > using the ISP that just died on you, but mp-tcp is one *demonstrably > working* way to handle that, get much faster session failover that BGP > would give you (seconds, not minutes). this kinda gets back to issue of what we mean when we talk about multihoming, which is why I poked Ted multiple times to try to get him to define what he meant when he used the term. At the moment it seems like we're all talking about different things, and this is leading to some of the confusion. So I ask again: can we please define what we mean by multihoming in the context of this discussion? Until we have clarified what we're talking about, the discussion is not going to lead anywhere. Nick From nobody Tue Jun 24 13:51:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0021B288C for ; Tue, 24 Jun 2014 13:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 msPfxb-OcCin for ; Tue, 24 Jun 2014 13:51:31 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463A01B2889 for ; Tue, 24 Jun 2014 13:51:31 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DFE3A1B81C7 for ; Tue, 24 Jun 2014 13:51:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C75FD190074; Tue, 24 Jun 2014 13:51:30 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 13:51:30 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A9E2F3.6080206@foobar.org> Date: Tue, 24 Jun 2014 16:51:29 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <21C61EF9-A82A-4493-9597-DCC62DE37F78@nominum.com> References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> <20140624194638.GZ46558@Space.Net> <53A9D643.6040100@foobar.org> <20140624195720.GA46558@Space.Net> <53A9E2F3.6080206@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mVDM6FYC-IZqnBMVutIcGIPFjJU Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:51:32 -0000 On Jun 24, 2014, at 4:43 PM, Nick Hilliard wrote: > So I ask again: can we please define what we mean by multihoming in = the > context of this discussion? Until we have clarified what we're = talking > about, the discussion is not going to lead anywhere. I shut up about this because as far as I can tell, the question of = multihoming has no bearing on this discussion. That is, I'm fairly = sure that even if I explained what I meant by multihoming, it would = still not lead us anywhere useful. From nobody Tue Jun 24 14:11:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B204A1B2903 for ; Tue, 24 Jun 2014 14:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 QHKgxbuvUuUI for ; Tue, 24 Jun 2014 14:11:29 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 935DC1B2A26 for ; Tue, 24 Jun 2014 14:01:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s5OL1VBE092164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 22:01:32 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53A9E72B.7030502@foobar.org> Date: Tue, 24 Jun 2014 22:01:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon References: <20140602013829.875B917236AC@rock.dv.isc.org> <53A843C9.1040002@gmail.com> <70F894D7-8701-420F-B16F-F8EAF3AE276F@nominum.com> <53A94E88.6070101@foobar.org> <8E5FC7CC-454E-437F-A85B-69366BC5D7B5@nominum.com> <53A989D8.2080704@foobar.org> <53A9C84A.8020304@foobar.org> <20140624194638.GZ46558@Space.Net> <53A9D643.6040100@foobar.org> <20140624195720.GA46558@Space.Net> <53A9E2F3.6080206@foobar.org> <21C61EF9-A82A-4493-9597-DCC62DE37F78@nominum.com> In-Reply-To: <21C61EF9-A82A-4493-9597-DCC62DE37F78@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f6a8Q9wIiRiz-WhD5Q0YiN1C-Us Cc: v6ops@ietf.org Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 21:11:30 -0000 On 24/06/2014 21:51, Ted Lemon wrote: > I shut up about this because as far as I can tell, the question of multihoming has no bearing on this discussion. That is, I'm fairly sure that even if I explained what I meant by multihoming, it would still not lead us anywhere useful. you're right, it's off-topic. Let's kill this ratholing exercise. Nick From nobody Tue Jun 24 21:06:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199B11B2AAC for ; Tue, 24 Jun 2014 21:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 PJDqchF1vYcy for ; Tue, 24 Jun 2014 21:06:51 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5FC1B2AAA for ; Tue, 24 Jun 2014 21:06:50 -0700 (PDT) Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKU6pK2rRuLxdL+uZFh0v26OD/JOhQO4WE@postini.com; Tue, 24 Jun 2014 21:06:50 PDT Received: by mail-qa0-f46.google.com with SMTP id i13so1055155qae.5 for ; Tue, 24 Jun 2014 21:06:49 -0700 (PDT) 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-type; bh=/NrO6KTd+tDwpoZQRNbRqx7hjtQyhHL8T1A/zx8CvVk=; b=kvQB2S+8Gv+D1ZS0X+CA3ma6/fpFEwI/mmsihMhXlXaebz/V3T4S4xeU2q/mkFOgPg nO+vpzJ9xgrMADlmNSE74WsYlhRdN/imHG5Ii3w3gPXEdatfYaymwiKwtgz/xQfxnSaS vAFgYgdumEzRGIKW8QVWEcY1k3vhsi3KlHbkfpb//oGzKcWNxs8PoS9kMaFVerHvdFOi D9cKtheBj8k+CAKk99XBRA9/tLsnGnXGtJUvPyXNA2wpkKivUwGVoiS0otb+YqHq9NtK ghUOaiFr87tKK0gCFnJxTddMGNsRv9ey25WcVbNDwSB9McO1X9szIDT1Z7gmCQZcYe9n MPPw== X-Gm-Message-State: ALoCoQlQ06eRq5vucQTTjf5z74hwhM9JusEC35w2V7BogcpR1wLGx0zOGS89PjZKNZK/ptpT3hwmfJJ/31MpX9gTywiV8cgkXsswci2bdQL0FHSaPBs4HGy86XZm5wMnO4VyHqgWsdi9 X-Received: by 10.140.37.75 with SMTP id q69mr7737254qgq.60.1403669209601; Tue, 24 Jun 2014 21:06:49 -0700 (PDT) X-Received: by 10.140.37.75 with SMTP id q69mr7737238qgq.60.1403669209499; Tue, 24 Jun 2014 21:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.51.132 with HTTP; Tue, 24 Jun 2014 21:06:28 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <20140527221708.A980B16B8C6E@rock.dv.isc.org> From: John Mann Date: Wed, 25 Jun 2014 14:06:28 +1000 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c1334a9d570b04fca134c8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4dENtZIfJeaNqY9p-xJeF_xEm5k Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 04:06:55 -0000 --001a11c1334a9d570b04fca134c8 Content-Type: text/plain; charset=UTF-8 Hi, On 28 May 2014 18:16, Owen DeLong wrote: > > On May 27, 2014, at 3:17 PM, Mark Andrews wrote: > > > > > In message , Philip Homburg > writes: > >> In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: > >>> The operational situation that's problematic is the large enterprise > >>> scenario, where you have two large enterprises with their own ULAs that > >>> merge. If those ULAs happen to clash, you have to renumber at least > >>> one of them. If they don't clash, you still have to deal with routing > >>> them (although I think the split-horizon complexity objection Mikael > >>> raised ought to be thought through carefully before being asserted as > >>> factual, because I think it can be addressed through routing and not > >>> naming). > >> > >> If you are a large entrprise, just spend the 50 euro or so (RIPE > service region) it > >> costs to get your own prefix. > > > > A /56 is over AUD1180 (+10% GST) annually. Thanks for playing. > > > > Yes, APNIC now has the distinction of being the absolutely most expensive > RIR on the planet. > > However, outside of the APNIC region, prices are much more reasonable. > > US 100 per resource (regardless of size) ARIN > EU 50 (flat rate, regardless of resources) RIPE > US 600 (up to a /35) LACNIC > US 100 (per /48?) AfriNIC > > AU1180 (/56, logarithmic formula for larger blocks) APNIC I think you are describing the APNIC costs poorly. It is AUD 1180 (up to a /34, logarithmic formula for larger blocks) APNIC Pricing one /56 http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F56&action=Calculate says "= AUD 4", but the minimum annual fee is AUD 1,180 so that is the actual fee. Similarly, an IPv6 /48 says "= AUD 30", but the minimum annual fee is AUD 1,180 so that is the actual fee. But a realistic situation for a SME with IPv4 and IPv6: - an IPv4 /24 and an IPv6 /34 http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=%2F24&ipv6=%2F34&action=Calculate Fees for each address type is AUD 1,180 ; take the maximum so the fee is AUD 1,180 And a small ISP: - an IPv4 /22 and/or an IPv6 /32 costs AUD 1,994 So, it looks like at a little less than twice your next closest > competitor, APNIC is the clear winner for the highest prices. > John --001a11c1334a9d570b04fca134c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 28 May 2014 18:16, Owen DeLong <owen@delong.com> wrote:<= br>

On May 27, 2014, at 3:17 PM, Mark Andrews <marka@isc.org> wrote:

>
> In message <m1WpHrp-0000BQC@stereo.hq.phicoh.net>, Philip Homburg writes:
>> In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: >>> The operational situation that's problematic is the large = enterprise
>>> scenario, where you have two large enterprises with their own = ULAs that
>>> merge. =C2=A0 If those ULAs happen to clash, you have to renum= ber at least
>>> one of them. =C2=A0 If they don't clash, you still have to= deal with routing
>>> them (although I think the split-horizon complexity objection = Mikael
>>> raised ought to be thought through carefully before being asse= rted as
>>> factual, because I think it can be addressed through routing a= nd not
>>> naming).
>>
>> If you are a large entrprise, just spend the 50 euro or so (RIPE s= ervice region) it
>> costs to get your own prefix.
>
> A /56 is over AUD1180 (+10% GST) annually. =C2=A0Thanks for playing. >

Yes, APNIC now has the distinction of being the absolutely most expen= sive RIR on the planet.

However, outside of the APNIC region, prices are much more reasonable.

US 100 per resource (regardless of size) ARIN
EU =C2=A050 (flat rate, regardless of resources) RIPE
US 600 (up to a /35) LACNIC
US 100 (per /48?) AfriNIC

> AU1180 (= /56, logarithmic formula for larger blocks) APNIC

= I think you are describing the APNIC costs poorly.

It is =C2=A0AUD 1180 (up to a /34,=C2=A0logarithmic formula for larger= blocks)=C2=A0APNIC

Pricing one /56
says "=3D AUD 4", but the minimum annual fee is AUD 1,= 180 =C2=A0so that is the actual fee.

Similarly, an= IPv6 /48 says "=3D AUD 30", but the minimum annual fee is AUD 1,= 180 =C2=A0so that is the actual fee.

But a realistic situation for a SME with IPv4 and IPv6:=
- an IPv4 /24 and an IPv6 /34
Fees for each address type is AUD 1,180 ; take the maximum so th= e fee is AUD 1,180

And a small ISP:
- an= IPv4 /22 and/or an IPv6 /32 costs AUD 1,994


So, it looks like at a little less than twice your next closest competitor,= APNIC is the clear winner for the highest prices.
=C2=A0 =C2=A0John
--001a11c1334a9d570b04fca134c8-- From nobody Wed Jun 25 12:50:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04A81B2E70 for ; Wed, 25 Jun 2014 12:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 0xFr-1PEPJtM for ; Wed, 25 Jun 2014 12:50:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B08861B2E71 for ; Wed, 25 Jun 2014 12:50:06 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s5PJjtZC018819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Jun 2014 12:45:56 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s5PJjtZC018819 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1403725558; bh=wVxkLAPxaZJsOxkSoae5gNNMNPM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=wv7XXbQYaFj6AzZulg+pb1Kk96QcM4G6zItEcn5VCtyglpMt0L5osGe5tzRfzheU5 c+H9GgFqCSHExk5Gymm0iHTVqJ/tqHxvxiFNmxpunQXEa4MzwG/u3Sf7PQG7JRqcjZ 0truiLVYyQhzkhGDljjhaYDDlzJEMq0M1kNXH37Y= Content-Type: multipart/alternative; boundary="Apple-Mail=_E3D5349D-9C48-48B8-9DCA-45E92AE7E263" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Owen DeLong In-Reply-To: Date: Wed, 25 Jun 2014 12:46:07 -0700 Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <20140527221708.A980B16B8C6E@rock.dv.isc.org> To: John Mann X-Mailer: Apple Mail (2.1878.2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 25 Jun 2014 12:45:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/div9JYep01PHqWEf_O-weGZZGNs Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 19:50:16 -0000 --Apple-Mail=_E3D5349D-9C48-48B8-9DCA-45E92AE7E263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 24, 2014, at 21:06 , John Mann wrote: > Hi, >=20 > On 28 May 2014 18:16, Owen DeLong wrote: >=20 > On May 27, 2014, at 3:17 PM, Mark Andrews wrote: >=20 > > > > In message , Philip Homburg = writes: > >> In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: > >>> The operational situation that's problematic is the large = enterprise > >>> scenario, where you have two large enterprises with their own ULAs = that > >>> merge. If those ULAs happen to clash, you have to renumber at = least > >>> one of them. If they don't clash, you still have to deal with = routing > >>> them (although I think the split-horizon complexity objection = Mikael > >>> raised ought to be thought through carefully before being asserted = as > >>> factual, because I think it can be addressed through routing and = not > >>> naming). > >> > >> If you are a large entrprise, just spend the 50 euro or so (RIPE = service region) it > >> costs to get your own prefix. > > > > A /56 is over AUD1180 (+10% GST) annually. Thanks for playing. > > >=20 > Yes, APNIC now has the distinction of being the absolutely most = expensive RIR on the planet. >=20 > However, outside of the APNIC region, prices are much more reasonable. >=20 > US 100 per resource (regardless of size) ARIN > EU 50 (flat rate, regardless of resources) RIPE > US 600 (up to a /35) LACNIC > US 100 (per /48?) AfriNIC >=20 > > AU1180 (/56, logarithmic formula for larger blocks) APNIC >=20 > I think you are describing the APNIC costs poorly. >=20 > It is AUD 1180 (up to a /34, logarithmic formula for larger blocks) = APNIC >=20 > Pricing one /56 > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F56&action=3DC= alculate > says "=3D AUD 4", but the minimum annual fee is AUD 1,180 so that is = the actual fee. >=20 > Similarly, an IPv6 /48 says "=3D AUD 30", but the minimum annual fee = is AUD 1,180 so that is the actual fee. >=20 > But a realistic situation for a SME with IPv4 and IPv6: > - an IPv4 /24 and an IPv6 /34 > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D%2F24&ipv6=3D%2F34&actio= n=3DCalculate > Fees for each address type is AUD 1,180 ; take the maximum so the fee = is AUD 1,180 >=20 > And a small ISP: > - an IPv4 /22 and/or an IPv6 /32 costs AUD 1,994 >=20 >=20 > So, it looks like at a little less than twice your next closest = competitor, APNIC is the clear winner for the highest prices. >=20 > John None of this contradicts my statement that APNIC is at least twice as = expensive as anyone else. (OK, not quite double LACNIC, but really = close). Owen --Apple-Mail=_E3D5349D-9C48-48B8-9DCA-45E92AE7E263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 24, 2014, at 21:06 , John Mann = <john.mann@monash.edu> = wrote:

Hi,

On 28 May 2014 18:16, Owen DeLong <owen@delong.com> wrote:

On May = 27, 2014, at 3:17 PM, Mark Andrews <marka@isc.org> = wrote:

>
> In message <m1WpHrp-0000BQC@stere= o.hq.phicoh.net>, Philip Homburg writes:
>> In your = letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote:
>>> = The operational situation that's problematic is the large = enterprise
>>> scenario, where you have two large = enterprises with their own ULAs that
>>> merge.   If = those ULAs happen to clash, you have to renumber at = least
>>> one of them.   If they don't clash, you still = have to deal with routing
>>> them (although I think the = split-horizon complexity objection Mikael
>>> raised ought = to be thought through carefully before being asserted as
>>> = factual, because I think it can be addressed through routing and = not
>>> naming).
>>
>> If you are a large = entrprise, just spend the 50 euro or so (RIPE service region) = it
>> costs to get your own prefix.
>
> A /56 is = over AUD1180 (+10% GST) annually.  Thanks for = playing.
>

Yes, APNIC now has the distinction of = being the absolutely most expensive RIR on the planet.

However, = outside of the APNIC region, prices are much more reasonable.

US = 100 per resource (regardless of size) ARIN
EU  50 (flat rate, = regardless of resources) RIPE
US 600 (up to a /35) LACNIC
US 100 = (per /48?) AfriNIC

> AU1180 (/56, = logarithmic formula for larger blocks) APNIC

I = think you are describing the APNIC costs = poorly.

It is  AUD 1180 (up to a = /34, logarithmic formula for larger = blocks) APNIC

Pricing one = /56
says "=3D AUD = 4", but the minimum annual fee is AUD 1,180  so that is the actual = fee.

Similarly, an IPv6 /48 says "=3D AUD 30", = but the minimum annual fee is AUD 1,180  so that is the actual = fee.

But a realistic situation for a SME with = IPv4 and IPv6:
- an IPv4 /24 and an IPv6 /34
Fees= for each address type is AUD 1,180 ; take the maximum so the fee is AUD = 1,180

And a small ISP:
- an IPv4 /22 = and/or an IPv6 /32 costs AUD = 1,994


So, it looks like at a little less than twice your = next closest competitor, APNIC is the clear winner for the highest = prices.

  =  John

None = of this contradicts my statement that APNIC is at least twice as = expensive as anyone else. (OK, not quite double LACNIC, but really = close).

Owen


= --Apple-Mail=_E3D5349D-9C48-48B8-9DCA-45E92AE7E263-- From nobody Wed Jun 25 16:51:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14DC1B28FA for ; Wed, 25 Jun 2014 16:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 7rGyOgZVrMnt for ; Wed, 25 Jun 2014 16:51:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102E51B2903 for ; Wed, 25 Jun 2014 16:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4651; q=dns/txt; s=iport; t=1403740278; x=1404949878; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8npmVZXyO374YwuEn39la1fLLYhwGOpaJyUw0ifiBaw=; b=hFq9IpmkOzWkS5TYceOZJDEifDGq/t3Z5bXEjNDSw/jFnicMwGz2njnt 2bEmzGD7Dk3AvVGdavYxK5Lhx7N5P4/SL+bP/oohdyDZpB+LpN5nxCPY4 Rxkd8gnFgv7PYjZ6NGdG8weUKaI2tkdPh+2NSFcMvqqkJrnEhCDICFg1G M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADhgq1OtJA2D/2dsb2JhbABYgw1SWsNbAYEJFnWEAwEBAQMBJyIwBQsCAQgYLjIlAgQOBQ4NiB8IxAAXjnwHCYMkgRYFkgiBQYcIgUaSJYNCgjA X-IronPort-AV: E=Sophos;i="5.01,548,1400025600"; d="asc'?scan'208";a="55977422" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 25 Jun 2014 23:51:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5PNp4OY018493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 23:51:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 25 Jun 2014 18:51:04 -0500 From: "Fred Baker (fred)" To: Ted Lemon Thread-Topic: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] Thread-Index: AQHPkNBT9D0WMTeSi06B2Kyd8GfDpw== Date: Wed, 25 Jun 2014 23:51:04 +0000 Message-ID: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> In-Reply-To: <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_4E8C6B4F-9091-45CB-A75C-5977FDC2E2EC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v10QKoDsyZlfI29ZZfHUcmzqQK0 Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 23:51:23 -0000 --Apple-Mail=_4E8C6B4F-9091-45CB-A75C-5977FDC2E2EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 1, 2014, at 9:54 AM, Ted Lemon wrote: > On May 31, 2014, at 5:55 PM, Philip Homburg = wrote: >> You suggest that every possible piece of software should implement = HE? >=20 > Software that doesn't implement some kind of happy eyeballs mechanism = is going to work poorly on an IPv6 internet. Ask rather whether there = could be some support for HE-like behavior that is relatively easy for = app developers to use, so that they don't fail to use it and wind up = making applications with crappy behaviors during partial outages. For the record, HE isn=92t actually about IPv6, although the document is = written that way. It=92s about multihoming. If I have a multihomed = device with two IPv4 addresses and one of them is intermittent for some = reason, I=92ll have exactly the same problem and should have exactly the = same solution. Or ditto if I have two IPv6 addresses. I actually have that problem right now. I have an HE tunnel to the = residential side of my home and IPv4+IPv6 to my home office courtesy of = Cisco. A few weeks ago, without notice, the HE tunnel stopped working. = Not sure why, but I have seen comments from others to the effect. So, on = the corporate side, I can ping or ping6 www.kame.net, but on the = residential network I can only ping it, not ping6. Imagine IPv4 not = working at all (that day will come, but not today). I=92d like to be = able to play happy eyeballs between my two IPv6 addresses. [FRED-M-20VW:~/Desktop] fred% ping6 -c 5 www.kame.net;ping -c 5 = www.kame.net PING6(56=3D40+8+8 bytes) 2001:1938:290:2:948e:3370:b5c6:74ff --> = 2001:200:dff:fff1:216:3eff:feb1:44d7 --- orange.kame.net ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss PING orange.kame.net (203.178.141.194): 56 data bytes 64 bytes from 203.178.141.194: icmp_seq=3D0 ttl=3D49 time=3D124.782 ms 64 bytes from 203.178.141.194: icmp_seq=3D1 ttl=3D49 time=3D124.827 ms 64 bytes from 203.178.141.194: icmp_seq=3D2 ttl=3D49 time=3D126.614 ms 64 bytes from 203.178.141.194: icmp_seq=3D3 ttl=3D49 time=3D116.715 ms 64 bytes from 203.178.141.194: icmp_seq=3D4 ttl=3D49 time=3D128.197 ms --- orange.kame.net ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 116.715/124.227/128.197/3.964 ms [FRED-M-20VW:~/Desktop] fred% !p ping6 -c 5 www.kame.net ; ping -c 5 www.kame.net PING6(56=3D40+8+8 bytes) 2001:420:701:32:9cec:98d1:3718:ce3c --> = 2001:200:dff:fff1:216:3eff:feb1:44d7 16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=3D0 hlim=3D51= time=3D173.079 ms 16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=3D1 hlim=3D51= time=3D172.896 ms 16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=3D2 hlim=3D51= time=3D187.208 ms 16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=3D3 hlim=3D51= time=3D171.177 ms 16 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7, icmp_seq=3D4 hlim=3D51= time=3D176.913 ms --- orange.kame.net ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 171.177/176.255/187.208/5.789 ms PING orange.kame.net (203.178.141.194): 56 data bytes 64 bytes from 203.178.141.194: icmp_seq=3D0 ttl=3D39 time=3D177.976 ms 64 bytes from 203.178.141.194: icmp_seq=3D1 ttl=3D39 time=3D180.668 ms 64 bytes from 203.178.141.194: icmp_seq=3D2 ttl=3D39 time=3D181.578 ms 64 bytes from 203.178.141.194: icmp_seq=3D3 ttl=3D39 time=3D183.519 ms 64 bytes from 203.178.141.194: icmp_seq=3D4 ttl=3D39 time=3D176.404 ms --- orange.kame.net ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 176.404/180.029/183.519/2.543 ms --Apple-Mail=_4E8C6B4F-9091-45CB-A75C-5977FDC2E2EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTq2BmbjEdbHIsm0MRApypAJ48wGvuaKmoB5ulF80W1adS6U73dACfb+cl nXY+qyucyyheodN3kLIDeRk= =tM7x -----END PGP SIGNATURE----- --Apple-Mail=_4E8C6B4F-9091-45CB-A75C-5977FDC2E2EC-- From nobody Wed Jun 25 18:57:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5736A1B2A0A for ; Wed, 25 Jun 2014 18:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 8IzfaycpQqyF for ; Wed, 25 Jun 2014 18:57:42 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AA61B291A for ; Wed, 25 Jun 2014 18:57:42 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 921701B806B for ; Wed, 25 Jun 2014 18:57:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7D8B0190071; Wed, 25 Jun 2014 18:57:42 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 18:57:42 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Wed, 25 Jun 2014 21:57:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8AE134E7-3AA9-4433-96DC-F256A7E8D8A1@nominum.com> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3qth55W3reYvtt5kXgnRYhT-H4U Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:57:44 -0000 On Jun 25, 2014, at 7:51 PM, Fred Baker (fred) wrote: > For the record, HE isn=92t actually about IPv6, although the document = is written that way. It=92s about multihoming. If I have a multihomed = device with two IPv4 addresses and one of them is intermittent for some = reason, I=92ll have exactly the same problem and should have exactly the = same solution. Or ditto if I have two IPv6 addresses. Yup. Hence the MIF happy eyeballs draft... From nobody Thu Jun 26 09:04:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ACA1B2D4A; Thu, 26 Jun 2014 09:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 4GN69Mzk1FaP; Thu, 26 Jun 2014 09:04:11 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC261B2D94; Thu, 26 Jun 2014 08:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A157C2CEE0; Thu, 26 Jun 2014 18:08:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VJ30_nJKkji; Thu, 26 Jun 2014 18:08:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id D79F12CEDE; Thu, 26 Jun 2014 18:08:37 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jari Arkko In-Reply-To: <5390BE61.4050407@nostrum.com> Date: Thu, 26 Jun 2014 16:08:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AF3C2D9-22C3-4FE1-9EBE-40BB8F9A6628@piuha.net> References: <5390BE61.4050407@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S9JxAoxsQh5QRAAzqHs7AD4IHA0 Cc: v6ops@ietf.org, General Area Review Team , "ietf@ietf.org" , draft-ietf-v6ops-enterprise-incremental-v6@tools.ietf.org Subject: Re: [v6ops] Gen-art LC review: draft-ietf-v6ops-enterprise-incremental-ipv6-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:04:16 -0000 Thank you Robert for your (once again) in-depth review. But I have a = question - was there a response to the comments? My e-mail system does = not show one, but maybe I missed it. Jari On 05 Jun 2014, at 20:00, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-v6ops-enterprise-incremental-ipv6-05 > Reviewer: Robert Sparks > Review Date: 5 June 2014 > IETF LC End Date: 9 June 2014 > IESG Telechat date: not yet scheduled >=20 > Summary: This draft is basically ready for publication as an = Informational RFC, > but has nits that should be considered before publication. >=20 > I had a mixed overall impression after my first read-through of this = draft. >=20 > Overall, the list of issues to consider, and the compendium of = references is very useful, but there are large stretches of text that = really aren't helping the reader, and they make the good stuff harder to = see. >=20 > I encourage the group to take one more editorial pass, focusing on = removing as much text as possible without losing the message. >=20 > Please help the IESG and the RFC-Editor out: the shepherd's writeup = should say something about why deviating from the style guide's = restriction on number of authors is is appropriate for this document. >=20 > Here are specific nits to consider in document order: >=20 > The first paragraph of section 1.3 starts talking about phases as if = they've already been described. As written, it says that beginning with = the External Phase is recommended in RFC5211. But the words "External = Phase" do not appear in 5211, and its not clear on a quick read exactly = what in 5211 you were hoping to point out here. Please introduce the = phases before this point, and change the callout to 5211 to make it more = clear how what 5211 is saying ties into this document. >=20 > Why is "Other Phases" capitalized in 2.1? The number of phases defined = in this document is small - I suspect this text is older and left room = for the group to decide to define more phases. Consider just listing = what you ended up with explicitly. >=20 > Section 2.1 contains sentences like "The project manager will need to = spend some time on planning." That is obvious, and you've already = established that planning needs to happen. This paragraph (perhaps much = of this section) would be improved by removing as much text as you can. = It already speaks mostly in terms of the benefits of planning. Making = that a more explicit goal in the writing structure would help identify = what can be taken away without losing the message. Overall, trying to = describe what good project management entails is a bit out of place. = Perhaps you should just say "This requires good project management = skills"? >=20 > In 2.2.2 you say "Applications should be made to use APIs". That seems = an odd construct for an IETF document. Perhaps you could observe, rather = than command, here? Would saying something like "Applications that use = APIs to hide the specifics ... will be easier to take through the = migration" make the point? >=20 > In 2.3, why do you need the hyperbole in "IPv6 adoption will be a = multifacted undertaking that will touch everyone in the organization = unlike almost any other project."? How does the "unlike almost any other = project" help the reader? >=20 > In 2.4.1, please rephrase "pretty much like". Are there any = differences in the use of IPSec dependent on the address family that are = important to call out? If not, why doesn't this say "the same as in"? >=20 > Section 2.4.2: As written, this says Etc. is an attack. Please change = the introduction to the list to say "for example" or "in particular" and = remove the Etc. If the point was to cause the reader to think about = attacks beyond these listed, say that explicitly. >=20 > The 6th paragraph of 2.6 states the problem is "how to get host DNS = records updated." The text in the rest of the paragraph only addresses = this by implication. It looks more like the general discussion of SLAAC = vs DHCPv6 instead of straightforwardly noting that a DHCPv6 server can = be made to update DNS records. >=20 > The reference to RFC6866 in paragraph 7 of section 2.6 is unclear - = what was it trying to point out? I think the last sentence was trying = to say 'static address assignment (even if achieved with DHCP) is = usually used' where it currently says 'SLAAC is rarely used'? >=20 > Section 3: The second paragraph doesn't add anything to the document. >=20 > Section 3.1 paragraph 2: I don't understand why the paragraph ends = with "which is an important consideration". Can you delete the phrase = without losing the message? If not, say why an enterprise would care = whether or not _other_ enterprises had already deployed using BGP on = their own. >=20 > Section 3.1 paragraph 4 : "will prefer to use" is out of place. = Perhaps this should be stated as "will likely get better results using"? >=20 > Section 3.1 paragraph 5: Can you add a reference to a discussion of = how keeping the MTU congruent simplifies operations? >=20 > In section 3.2 consider using the names from 4890 in the list ('Packet = Too Big' rather than 'Unreachable packet-to-big') >=20 > Please check whether the sentence "To be fully compliant with = [RFC5095], all packets containing the routing extension header type 0 = must be dropped." is perhaps too simple a description of 5095? Does = context keep you out of the "Segments left is zero" branch of that RFCs = requirement? >=20 > In section 3.4, please remove "this may seem too time-consuming and = too risky" or restate it with details. How is this observation supposed = to help the reader? >=20 > In section 4.1 paragraph 3 "But the major issue is probably linked to = all threats" would read better as "One major issue is threats" >=20 > In section 5 paragraph 3, please provide a reference to where these = significant implications are discussed, or add some discussion. = (Otherwise, what is the reader supposed to do with this observation?) >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 26 09:14:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC2C1B2F11; Thu, 26 Jun 2014 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ehRi1hXH7VV5; Thu, 26 Jun 2014 09:14:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 608F81B2FF3; Thu, 26 Jun 2014 08:22:37 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s5QFMYiW041704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 26 Jun 2014 10:22:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53AC3ABA.8010204@nostrum.com> Date: Thu, 26 Jun 2014 10:22:34 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jari Arkko References: <5390BE61.4050407@nostrum.com> <8AF3C2D9-22C3-4FE1-9EBE-40BB8F9A6628@piuha.net> In-Reply-To: <8AF3C2D9-22C3-4FE1-9EBE-40BB8F9A6628@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1kzbeUOn8LTfNgfvn99S-RrBDWU Cc: v6ops@ietf.org, General Area Review Team , "ietf@ietf.org" , draft-ietf-v6ops-enterprise-incremental-v6@tools.ietf.org Subject: Re: [v6ops] Gen-art LC review: draft-ietf-v6ops-enterprise-incremental-ipv6-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:14:19 -0000 No, I don't think I've seen a response. RjS On 6/26/14, 10:08 AM, Jari Arkko wrote: > Thank you Robert for your (once again) in-depth review. But I have a question - was there a response to the comments? My e-mail system does not show one, but maybe I missed it. > > Jari > > On 05 Jun 2014, at 20:00, Robert Sparks wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-v6ops-enterprise-incremental-ipv6-05 >> Reviewer: Robert Sparks >> Review Date: 5 June 2014 >> IETF LC End Date: 9 June 2014 >> IESG Telechat date: not yet scheduled >> >> Summary: This draft is basically ready for publication as an Informational RFC, >> but has nits that should be considered before publication. >> >> I had a mixed overall impression after my first read-through of this draft. >> >> Overall, the list of issues to consider, and the compendium of references is very useful, but there are large stretches of text that really aren't helping the reader, and they make the good stuff harder to see. >> >> I encourage the group to take one more editorial pass, focusing on removing as much text as possible without losing the message. >> >> Please help the IESG and the RFC-Editor out: the shepherd's writeup should say something about why deviating from the style guide's restriction on number of authors is is appropriate for this document. >> >> Here are specific nits to consider in document order: >> >> The first paragraph of section 1.3 starts talking about phases as if they've already been described. As written, it says that beginning with the External Phase is recommended in RFC5211. But the words "External Phase" do not appear in 5211, and its not clear on a quick read exactly what in 5211 you were hoping to point out here. Please introduce the phases before this point, and change the callout to 5211 to make it more clear how what 5211 is saying ties into this document. >> >> Why is "Other Phases" capitalized in 2.1? The number of phases defined in this document is small - I suspect this text is older and left room for the group to decide to define more phases. Consider just listing what you ended up with explicitly. >> >> Section 2.1 contains sentences like "The project manager will need to spend some time on planning." That is obvious, and you've already established that planning needs to happen. This paragraph (perhaps much of this section) would be improved by removing as much text as you can. It already speaks mostly in terms of the benefits of planning. Making that a more explicit goal in the writing structure would help identify what can be taken away without losing the message. Overall, trying to describe what good project management entails is a bit out of place. Perhaps you should just say "This requires good project management skills"? >> >> In 2.2.2 you say "Applications should be made to use APIs". That seems an odd construct for an IETF document. Perhaps you could observe, rather than command, here? Would saying something like "Applications that use APIs to hide the specifics ... will be easier to take through the migration" make the point? >> >> In 2.3, why do you need the hyperbole in "IPv6 adoption will be a multifacted undertaking that will touch everyone in the organization unlike almost any other project."? How does the "unlike almost any other project" help the reader? >> >> In 2.4.1, please rephrase "pretty much like". Are there any differences in the use of IPSec dependent on the address family that are important to call out? If not, why doesn't this say "the same as in"? >> >> Section 2.4.2: As written, this says Etc. is an attack. Please change the introduction to the list to say "for example" or "in particular" and remove the Etc. If the point was to cause the reader to think about attacks beyond these listed, say that explicitly. >> >> The 6th paragraph of 2.6 states the problem is "how to get host DNS records updated." The text in the rest of the paragraph only addresses this by implication. It looks more like the general discussion of SLAAC vs DHCPv6 instead of straightforwardly noting that a DHCPv6 server can be made to update DNS records. >> >> The reference to RFC6866 in paragraph 7 of section 2.6 is unclear - what was it trying to point out? I think the last sentence was trying to say 'static address assignment (even if achieved with DHCP) is usually used' where it currently says 'SLAAC is rarely used'? >> >> Section 3: The second paragraph doesn't add anything to the document. >> >> Section 3.1 paragraph 2: I don't understand why the paragraph ends with "which is an important consideration". Can you delete the phrase without losing the message? If not, say why an enterprise would care whether or not _other_ enterprises had already deployed using BGP on their own. >> >> Section 3.1 paragraph 4 : "will prefer to use" is out of place. Perhaps this should be stated as "will likely get better results using"? >> >> Section 3.1 paragraph 5: Can you add a reference to a discussion of how keeping the MTU congruent simplifies operations? >> >> In section 3.2 consider using the names from 4890 in the list ('Packet Too Big' rather than 'Unreachable packet-to-big') >> >> Please check whether the sentence "To be fully compliant with [RFC5095], all packets containing the routing extension header type 0 must be dropped." is perhaps too simple a description of 5095? Does context keep you out of the "Segments left is zero" branch of that RFCs requirement? >> >> In section 3.4, please remove "this may seem too time-consuming and too risky" or restate it with details. How is this observation supposed to help the reader? >> >> In section 4.1 paragraph 3 "But the major issue is probably linked to all threats" would read better as "One major issue is threats" >> >> In section 5 paragraph 3, please provide a reference to where these significant implications are discussed, or add some discussion. (Otherwise, what is the reader supposed to do with this observation?) >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 26 13:57:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D69A1A028F; Thu, 26 Jun 2014 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 4MISq4okuBhU; Thu, 26 Jun 2014 13:57:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 77C151A019E; Thu, 26 Jun 2014 13:57:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 713F21801AE; Thu, 26 Jun 2014 13:55:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140626205546.713F21801AE@rfc-editor.org> Date: Thu, 26 Jun 2014 13:55:46 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8d3wv2cU_KbfPydJvEactf1IVoY Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:57:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7278 Title: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link Author: C. Byrne, D. Drown, A. Vizdal Status: Informational Stream: IETF Date: June 2014 Mailbox: cameron.byrne@t-mobile.com, dan@drown.org, ales.vizdal@t-mobile.cz Pages: 10 Characters: 19965 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-64share-10.txt URL: http://www.rfc-editor.org/rfc/rfc7278.txt This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jun 27 02:52:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3691B2F3B for ; Fri, 27 Jun 2014 02:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 6XCFY_Xm-Vjj for ; Fri, 27 Jun 2014 02:52:09 -0700 (PDT) Received: from smtp07.msg.oleane.net (smtp07.msg.oleane.net [62.161.4.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7621B2F38 for ; Fri, 27 Jun 2014 02:52:07 -0700 (PDT) Received: from MGosseDellM6800 (LMontsouris-656-01-05-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp07.msg.oleane.net (MSA) with ESMTP id s5R9q5ot018495 for ; Fri, 27 Jun 2014 11:52:05 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Fri, 27 Jun 2014 11:52:03 +0200 Message-ID: <008c01cf91ed$729619b0$57c24d10$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01CF91FE.36204940" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+R7O5gR08NMLGNRLGXsYFHHXqfdQ== Content-Language: fr X-Backend: vm-smtp-sophos14v3 X-PMX-Spam: Probability=9% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.27.93620 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2LAElY-qTJONVotX03LzXQ4xLV0 Subject: [v6ops] Call for proposals V6 World 2015 Paris X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 09:52:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008D_01CF91FE.36204940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fifth Edition of V6 World will take place in Paris from 17 to 18 March, 2015. This edition will focus on SDN, IPv6 end-to-end, Segment Routing, IPv6 in data centers and IT tools, XLAT464 deployments and removing IPv4 in existing networks. A call for proposals is open until July 21. ------=_NextPart_000_008D_01CF91FE.36204940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fifth Edition = of V6 World will take = place in Paris from 17 to 18 March, = 2015. 

 

This edition will = focus on SDN, IPv6 end-to-end, Segment Routing, IPv6 in data centers and = IT tools, XLAT464 deployments and removing IPv4 in existing = networks. 

 

A call for proposals = is open until July 21.

 

------=_NextPart_000_008D_01CF91FE.36204940-- From nobody Fri Jun 27 03:27:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576321B2F40 for ; Fri, 27 Jun 2014 03:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 rgbk-S8s4mAM for ; Fri, 27 Jun 2014 03:27:45 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739C51B2F3F for ; Fri, 27 Jun 2014 03:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=436; q=dns/txt; s=iport; t=1403864863; x=1405074463; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=l4e75m3alOBWpYcg/M3J/RpGz8y/pa7kWczAix4i5Uc=; b=K7TC7krqwprkp+3/TAwqNICnpDDMOzIXDL3D3lXN4agy1ggpCbd21RKo G2hag6b7sdPPIlEYve6Gs268NH0dAKza+sdnKBTXpKdpZUU8yBrJDtjAe CNAIVru9pLJ5q8VWsrcnNgYAK0qDrlfIX0hk1ucZtu36nYFVOJ4J5WgRj M=; X-IronPort-AV: E=Sophos;i="5.01,559,1400025600"; d="scan'208";a="42229033" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 27 Jun 2014 10:27:41 +0000 Received: from SHTSUCHI-M-V1EK.CISCO.COM (dhcp-10-141-40-82.cisco.com [10.141.40.82]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5RARenB020198; Fri, 27 Jun 2014 10:27:40 GMT Message-ID: <53AD471B.6070009@cisco.com> Date: Fri, 27 Jun 2014 19:27:39 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: leo.liubing@huawei.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_QhnIhxPwkOsR_56DYwZI2NLvug Cc: kshimizu@juniper.net, v6ops@ietf.org, i18n@janog.gr.jp Subject: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:27:48 -0000 Leo and v6ops F.Y.I JANOG(JApan Network Operator's Group) decided to provide ula address to the JANOG34 conference network. http://www.janog.gr.jp/en/index.php?JANOG34_Meeting They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with GUA. http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 If you would like to confirm something on the network , please let me know. Regards, -Shishio From nobody Fri Jun 27 17:58:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFBA1A024F for ; Fri, 27 Jun 2014 17:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 OUbx1gH-Misj for ; Fri, 27 Jun 2014 17:58:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30481A024B for ; Fri, 27 Jun 2014 17:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2938; q=dns/txt; s=iport; t=1403917091; x=1405126691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yf/6bEsCdYU3c9bkfovvXz4C4IDwUNTt/PlH4Ri3M6k=; b=WJLgWC5LahaPs8hCVi5ruhhCF3gwP6OnzITUUs5YHHCQVyi1yZe2RFtO YwsZy7n3NCU5rxvpJsbW5Ag1FMNaHnKJWrZRMWdgpor87piRL5ClP4rjx Uu6WViEVrtTUUGBJ23R90qLCAf+iwaqxSFpDGafT7lho9kDUUuNixT82K 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAP0RrlOtJA2H/2dsb2JhbABAGoMNUk0NxEQBgQ0WdYQDAQEBAwFoEQULAgEIRjIlAgQOBQ6ILAgNNsQOF4tigyMHgy2BFgWSD4FChwyBRpI1g0JsgUQ X-IronPort-AV: E=Sophos;i="5.01,565,1400025600"; d="asc'?scan'208";a="336269594" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jun 2014 00:58:10 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5S0w9I8013695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Jun 2014 00:58:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 19:58:09 -0500 From: "Fred Baker (fred)" To: "Shishio Tsuchiya (shtsuchi)" Thread-Topic: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 Thread-Index: AQHPkmwHurzZcJqO1EuYF7jyXqLTzA== Date: Sat, 28 Jun 2014 00:58:09 +0000 Message-ID: <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> References: <53AD471B.6070009@cisco.com> In-Reply-To: <53AD471B.6070009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_B91C49F0-CF9B-4062-9F10-44387270B780"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BDTETaZI2pFZT0dJf479RkNPaCI Cc: "kshimizu@juniper.net" , "v6ops@ietf.org" , "i18n@janog.gr.jp" Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 00:58:12 -0000 --Apple-Mail=_B91C49F0-CF9B-4062-9F10-44387270B780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya = wrote: > Leo and v6ops > F.Y.I > JANOG(JApan Network Operator's Group) decided to provide ula address = to the JANOG34 conference network. > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting >=20 > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with = GUA. > = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 >=20 > If you would like to confirm something on the network , please let me = know. Thanks for this. I would expect that the key things to prove are the statements in the = draft. Also, any observations that might come up would be useful. For = example, was it fair to say that the network that was isolated remained = isolated? Did using a ULA and a GUA on a globally-accessible network = cause any issues? What, if anything, was necessary in the router(s) in = question to prevent hosts from using ULA source addresses to connect to = GUA addresses? Did hosts in fact form both ULA and GUA-based addresses = and use them appropriately when connecting to applications inside and = outside the network?=20 What one might hope would be that ULA-based addresses were used to = connect to other ULA-based addresses, as their bit strings were most = similar, and GUA-based addresses were used to connect to other GUA-based = addresses, for the same reason. One might hope that ULA prefixes were = not announced in BGP without needing extra thought, and that if they = were announced, they were not accepted. One might further hope that when = a ULA was not announced into a neighboring domain, a packet sent to the = ULA prefix didn=92t cross the domain boundary. Of course, we need to hear about any extra work that was required, and = any problems that arose. And we need to understand if the deployment of = a ULA prefix necessarily implied the deployment of an IPv6/IPv6 NAT or = NAPT. I don=92t expect that it will and am certainly not asking for it = to, but that expectation has been promoted. JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will = meet Monday and Tuesday. It would be nice if someone could make a point = of reporting on the experiment. --Apple-Mail=_B91C49F0-CF9B-4062-9F10-44387270B780 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTrhMgbjEdbHIsm0MRAvmyAJ9XjvQHgb0WAIy41tXKRKmZ0inKIwCgxSY+ dFSMAZVRJcQzXdyNQ/gztJY= =HsED -----END PGP SIGNATURE----- --Apple-Mail=_B91C49F0-CF9B-4062-9F10-44387270B780-- From nobody Sun Jun 29 21:10:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080A51A0145 for ; Sun, 29 Jun 2014 21:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 UJZzukMtRvxn for ; Sun, 29 Jun 2014 21:10:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973F91A014C for ; Sun, 29 Jun 2014 21:10:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGP82963; Mon, 30 Jun 2014 04:10:46 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 05:10:45 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 12:10:42 +0800 From: "Liubing (Leo)" To: "Shishio Tsuchiya (shtsuchi)" Thread-Topic: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 Thread-Index: AQHPkfJyy4YNtnZygkqC4I6HwJUT9JuFLg2AgAPJYdA= Date: Mon, 30 Jun 2014 04:10:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> In-Reply-To: <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cCOt-X1WFhkCZHh98NuVZzTlFSY Cc: "kshimizu@juniper.net" , "v6ops@ietf.org" , "i18n@janog.gr.jp" Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 04:10:52 -0000 Hi Shishio, Thanks much for sharing the information. It's great that JANOG34 will provi= de more experience of using ULAs. Basically I agree with Fred that it is important to see whether the stateme= nts of the draft is correct. In addition to Fred's comments, I have some ot= her concerns: - Is it easy to configure a host with ULA+PA? E.g., both through SLAAC or t= hrough SLAAC/DHCPv6 respectively. - Are there still many hosts using the old address selection algorithm [348= 4]? Since [RFC3484] hosts will face the problem of selecting un-expected UL= A-PA source/destination address pairs. - Let me confirm the ULA-only Deployment in JANOG34, did you mean "connect = to the Internet through ULA-only" or "ULA-only in an isolated network or fo= r internal use only"? (The 3.2.1 of the draft specifically means the former= .)=20 Best regards, Bing > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Saturday, June 28, 2014 8:58 AM > To: Shishio Tsuchiya (shtsuchi) > Cc: Liubing (Leo); kshimizu@juniper.net; v6ops@ietf.org; i18n@janog.gr.jp > Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 >=20 >=20 > On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya wrote: >=20 > > Leo and v6ops > > F.Y.I > > JANOG(JApan Network Operator's Group) decided to provide ula address > to the JANOG34 conference network. > > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting > > > > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with > GUA. > > > http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 > > > > If you would like to confirm something on the network , please let me > know. >=20 > Thanks for this. >=20 > I would expect that the key things to prove are the statements in the dra= ft. > Also, any observations that might come up would be useful. For example, > was it fair to say that the network that was isolated remained isolated? = Did > using a ULA and a GUA on a globally-accessible network cause any issues? > What, if anything, was necessary in the router(s) in question to prevent = hosts > from using ULA source addresses to connect to GUA addresses? Did hosts in > fact form both ULA and GUA-based addresses and use them appropriately > when connecting to applications inside and outside the network? >=20 > What one might hope would be that ULA-based addresses were used to > connect to other ULA-based addresses, as their bit strings were most simi= lar, > and GUA-based addresses were used to connect to other GUA-based > addresses, for the same reason. One might hope that ULA prefixes were not > announced in BGP without needing extra thought, and that if they were > announced, they were not accepted. One might further hope that when a > ULA was not announced into a neighboring domain, a packet sent to the ULA > prefix didn't cross the domain boundary. >=20 > Of course, we need to hear about any extra work that was required, and an= y > problems that arose. And we need to understand if the deployment of a ULA > prefix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I > don't expect that it will and am certainly not asking for it to, but that > expectation has been promoted. >=20 > JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will > meet Monday and Tuesday. It would be nice if someone could make a point > of reporting on the experiment. From nobody Sun Jun 29 21:15:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE51A0160 for ; Sun, 29 Jun 2014 21:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xOgGd9f3h9jT for ; Sun, 29 Jun 2014 21:15:17 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3928B1A014B for ; Sun, 29 Jun 2014 21:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2525; q=dns/txt; s=iport; t=1404101717; x=1405311317; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7doGdZxyAPdauJRCoGeK4ExfBOvaJGunVxsJVmWZmwA=; b=aHCeh3MyMS2Uy3ccbyV7aBqNQMfuYFAXH/cmLXCNZI4H11lykRPQbtV9 Q1gUX//xnhvRH1HfHeOwG9vaunpaPDqyVAMaTcyhoAU5PV68R2gUeya6j iQvjiQEDqNcfHqUadDaToWyUp7zveRvtlfGqLWf0iDDwvtl+BFi5ZqoM+ E=; X-IronPort-AV: E=Sophos;i="5.01,573,1400025600"; d="scan'208";a="11833521" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 30 Jun 2014 04:15:15 +0000 Received: from SHTSUCHI-M-V1EK.CISCO.COM (dhcp-10-141-41-36.cisco.com [10.141.41.36]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5U4FDCL021998; Mon, 30 Jun 2014 04:15:14 GMT Message-ID: <53B0E452.5070202@cisco.com> Date: Mon, 30 Jun 2014 13:15:14 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: fred@cisco.com References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> In-Reply-To: <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wDWBskt-hSSQE_1QWlrbxkBH5TQ Cc: kshimizu@juniper.net, v6ops@ietf.org, i18n@janog.gr.jp Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 04:15:19 -0000 Fred Thanks. Report on experience @v6ops is good idea. Unfortunately I can't go to ietf90 , so I will ask help to janoger who can attend both and report the experience to v6ops. Anyway I will post the report to v6ops after janog34. Regards, -Shishio (2014/06/28 9:58), Fred Baker (fred) wrote: > > On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya wrote: > >> Leo and v6ops >> F.Y.I >> JANOG(JApan Network Operator's Group) decided to provide ula address to the JANOG34 conference network. >> http://www.janog.gr.jp/en/index.php?JANOG34_Meeting >> >> They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with GUA. >> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 >> >> If you would like to confirm something on the network , please let me know. > > Thanks for this. > > I would expect that the key things to prove are the statements in the draft. Also, any observations that might come up would be useful. For example, was it fair to say that the network that was isolated remained isolated? Did using a ULA and a GUA on a globally-accessible network cause any issues? What, if anything, was necessary in the router(s) in question to prevent hosts from using ULA source addresses to connect to GUA addresses? Did hosts in fact form both ULA and GUA-based addresses and use them appropriately when connecting to applications inside and outside the network? > > What one might hope would be that ULA-based addresses were used to connect to other ULA-based addresses, as their bit strings were most similar, and GUA-based addresses were used to connect to other GUA-based addresses, for the same reason. One might hope that ULA prefixes were not announced in BGP without needing extra thought, and that if they were announced, they were not accepted. One might further hope that when a ULA was not announced into a neighboring domain, a packet sent to the ULA prefix didn$B!G(Bt cross the domain boundary. > > Of course, we need to hear about any extra work that was required, and any problems that arose. And we need to understand if the deployment of a ULA prefix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I don$B!G(Bt expect that it will and am certainly not asking for it to, but that expectation has been promoted. > > JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will meet Monday and Tuesday. It would be nice if someone could make a point of reporting on the experiment. From nobody Sun Jun 29 21:48:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4941F1A0164 for ; Sun, 29 Jun 2014 21:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.952 X-Spam-Level: X-Spam-Status: No, score=-13.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mHWtRvLBzHJ8 for ; Sun, 29 Jun 2014 21:48:48 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115D01A0162 for ; Sun, 29 Jun 2014 21:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3905; q=dns/txt; s=iport; t=1404103728; x=1405313328; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mGllt/ZdRDOnIa5tL3uDCxWZFF3GSotU+8f0XD596kc=; b=AssYwhDF8Mha1uceaK/b7Wp+NOcbZpklUOYbGLa+obB5oJ8ddNruhPMn iBdJ5qdrsc7rv6z+2EXNF+hFyxlFFopGHSR8RVdxnBhFRd4G7HnSg7C/J 3dMj/zeDlBd6/E348QuRPQTDxIrrPrX+ex+LSwGiwASdu345WP/Z6Y4Ff E=; X-IronPort-AV: E=Sophos;i="5.01,573,1400025600"; d="scan'208";a="42297746" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 30 Jun 2014 04:48:45 +0000 Received: from SHTSUCHI-M-V1EK.CISCO.COM (dhcp-10-141-41-36.cisco.com [10.141.41.36]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5U4mijR031516; Mon, 30 Jun 2014 04:48:44 GMT Message-ID: <53B0EC2C.1090202@cisco.com> Date: Mon, 30 Jun 2014 13:48:44 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: leo.liubing@huawei.com References: <53AD471B.6070009@cisco.com> <6015024E-05E9-4749-8D85-3943ECDA3111@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ECC41@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RQN-fDyoT7nayAe-ZmvpjOMVUrM Cc: kshimizu@juniper.net, v6ops@ietf.org, i18n@janog.gr.jp Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 04:48:50 -0000 Leo (2014/06/30 13:10), Liubing (Leo) wrote: > Hi Shishio, > > Thanks much for sharing the information. It's great that JANOG34 will provide more experience of using ULAs. > > Basically I agree with Fred that it is important to see whether the statements of the draft is correct. In addition to Fred's comments, I have some other concerns: > - Is it easy to configure a host with ULA+PA? E.g., both through SLAAC or through SLAAC/DHCPv6 respectively. This is good point. I will confirm about how to assign ipv6 address to users. > - Are there still many hosts using the old address selection algorithm [3484]? Since [RFC3484] hosts will face the problem of selecting un-expected ULA-PA source/destination address pairs. Yes, this is the most interesting for me. If we can confirm a lot of client it would be great implementation report of RFC3484. > - Let me confirm the ULA-only Deployment in JANOG34, did you mean "connect to the Internet through ULA-only" or "ULA-only in an isolated network or for internal use only"? (The 3.2.1 of the draft specifically means the former.) "connect to the Internet through ULA-only" I think we can check utilization of tcp port for each of client on CGN. Regards, -Shishio > > Best regards, > Bing > >> -----Original Message----- >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Saturday, June 28, 2014 8:58 AM >> To: Shishio Tsuchiya (shtsuchi) >> Cc: Liubing (Leo); kshimizu@juniper.net; v6ops@ietf.org; i18n@janog.gr.jp >> Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2 >> >> >> On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya wrote: >> >>> Leo and v6ops >>> F.Y.I >>> JANOG(JApan Network Operator's Group) decided to provide ula address >> to the JANOG34 conference network. >>> http://www.janog.gr.jp/en/index.php?JANOG34_Meeting >>> >>> They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with >> GUA. >>> >> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 >>> >>> If you would like to confirm something on the network , please let me >> know. >> >> Thanks for this. >> >> I would expect that the key things to prove are the statements in the draft. >> Also, any observations that might come up would be useful. For example, >> was it fair to say that the network that was isolated remained isolated? Did >> using a ULA and a GUA on a globally-accessible network cause any issues? >> What, if anything, was necessary in the router(s) in question to prevent hosts >> from using ULA source addresses to connect to GUA addresses? Did hosts in >> fact form both ULA and GUA-based addresses and use them appropriately >> when connecting to applications inside and outside the network? >> >> What one might hope would be that ULA-based addresses were used to >> connect to other ULA-based addresses, as their bit strings were most similar, >> and GUA-based addresses were used to connect to other GUA-based >> addresses, for the same reason. One might hope that ULA prefixes were not >> announced in BGP without needing extra thought, and that if they were >> announced, they were not accepted. One might further hope that when a >> ULA was not announced into a neighboring domain, a packet sent to the ULA >> prefix didn't cross the domain boundary. >> >> Of course, we need to hear about any extra work that was required, and any >> problems that arose. And we need to understand if the deployment of a ULA >> prefix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I >> don't expect that it will and am certainly not asking for it to, but that >> expectation has been promoted. >> >> JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will >> meet Monday and Tuesday. It would be nice if someone could make a point >> of reporting on the experiment. > . >