From nobody Thu Oct 6 12:03:48 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF7129740 for ; Thu, 6 Oct 2016 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWcyKfiFGX1Y for ; Thu, 6 Oct 2016 12:03:46 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0B129758 for ; Thu, 6 Oct 2016 12:03:46 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u96J3iVE018027 for ; Thu, 6 Oct 2016 15:03:44 -0400 Received: (qmail 21737 invoked by uid 0); 6 Oct 2016 19:03:44 -0000 X-TCPREMOTEIP: 204.235.114.162 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.116.238.146?) (lee@asgard.org@204.235.114.162) by 0 with ESMTPA; 6 Oct 2016 19:03:44 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Thu, 06 Oct 2016 15:03:44 -0400 From: Lee Howard To: Message-ID: <26278476-1FCD-4D37-A72D-FA9FA4792D2E@asgard.org> Thread-Topic: Sunset4 work Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3558611024_1671869391" Archived-At: Subject: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:03:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3558611024_1671869391 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit After the last WG meeting, I walked away with seven things that I thought we needed to do: Update my v4historic draft. I intend to do this in time for the Seoul meeting. Phillip Hallam-Baker suggested something like "draft-baker-ipv4status-its-complicated." I would like to hear more about this, and read a draft. The IAB should tell partner SDOs that their work should support IPv6. We're working on this, and should have an update before the meeting. The IESG or IETF community should squelch IPv4-only charters. I think the IESG would rather see a community statement, so we're hoping for a draft in the next couple of weeks. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-only examples, IPv4 dependencies, and clean them up. Does anyone see a way to structure this, or is there no followup to be had here? Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari and Jim, and they're only reluctant if doing this impedes participants getting work done. Does anyone have any ideas for how to show this? Volunteers? Update id-nits checked to look for IPv4-only examples. Done! I therefore think there's enough work to justify a meeting in Seoul, and have said so to the WG chairs. On this list, I'd like to hear ideas about how to structure work/followup on #5 and #6. Are there other topics we should discuss? Thanks, Lee --B_3558611024_1671869391 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
After the last WG meeting, I = walked away with seven things that I thought we needed to do:

=
  1. Update my v4historic draft. I intend to do this in time for th= e Seoul meeting.
  2. Phillip Hallam-Baker suggested something like "draf= t-baker-ipv4status-its-complicated." I would like to hear more about this, a= nd read a draft.
  3. The IAB should tell partner SDOs that their work sh= ould support IPv6. We're working on this, and should have an update before t= he meeting.
  4. The IESG or IETF community should squelch IPv4-only char= ters. I think the IESG would rather see a community statement, so we're hopi= ng for a draft in the next couple of weeks.
  5. WG Chairs and IETF commu= nicty looks for IPv4 literals, IPv4-only examples, IPv4 dependencies, and cl= ean them up. Does anyone see a way to structure this, or is there no followu= p to be had here?
  6. Run IPv6+NAT64 as the default IETF SSID. I've disc= ussed with Jari and Jim, and they're only reluctant if doing this impedes pa= rticipants getting work done. Does anyone have any ideas for how to show thi= s? Volunteers?
  7. Update id-nits checked to look for IPv4-only examples= . Done!
I therefore think there's enough work to justify a mee= ting in Seoul, and have said so to the WG chairs. 

=
On this list, I'd like to hear ideas about how to structure work/follow= up on #5 and #6. 

Are there other topics we sh= ould discuss?

Thanks,

Lee<= /div>

--B_3558611024_1671869391-- From nobody Thu Oct 6 12:13:07 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E721129760 for ; Thu, 6 Oct 2016 12:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inluN6sFyDae for ; Thu, 6 Oct 2016 12:12:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF64E12976F for ; Thu, 6 Oct 2016 12:12:56 -0700 (PDT) Received: from [10.0.1.45] (h126.viagenie.ca [206.123.31.126]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3FCBB47751; Thu, 6 Oct 2016 15:12:56 -0400 (EDT) From: "Marc Blanchet" To: "Lee Howard" Date: Thu, 06 Oct 2016 15:12:55 -0400 Message-ID: <67B9F410-92AB-4957-AB2F-308DA94DF4AE@viagenie.ca> In-Reply-To: <26278476-1FCD-4D37-A72D-FA9FA4792D2E@asgard.org> References: <26278476-1FCD-4D37-A72D-FA9FA4792D2E@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: sunset4@ietf.org Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:13:02 -0000 On 6 Oct 2016, at 15:03, Lee Howard wrote: > Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari and > Jim, and they're only reluctant if doing this impedes participants > getting work done. Does anyone have any ideas for how to show this? > Volunteers? I would suggest to have the IETF Chair to take a humm on this during the plenary. Marc. > > On this list, I'd like to hear ideas about how to structure > work/followup on #5 and #6. > > Are there other topics we should discuss? > > Thanks, > > Lee > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From nobody Thu Oct 6 12:30:40 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506061293F4 for ; Thu, 6 Oct 2016 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 9lZuK5hv2gJU for ; Thu, 6 Oct 2016 12:30:29 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C189D129773 for ; Thu, 6 Oct 2016 12:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1475782224; x=1476387024; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=O7msO9CmLa++3FqyuvOvvj/A0nxfsvFU53wgaNzznXk=; b=PhN/pg0eKJfvC LII9fT1PdMAbwh6hQVdkpSNCoeCV911Ohec8eIBAVn7LAdVHExt+O0rTU8vjTqXj RA6cJ/IurinSsZso5i3Qzg6Bwd13c8L07SjJdljondQ6FZfwerQKvNZT/g4KnNqk etGwrOIZSYgeLkrOMHuJACDceGhEoc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=pdz4GAFhtJg/f+4oWzjeNMuLnZEZDWDnXoBCUojTWhZ4aInvsezqwvJH1l3Y S9A0nYAh4NM9KSM0jL9WBmeWSzjrLQ80PgA9ZMNUfp0NAjZoRN5415tag zrD5A+RGhM0S3EO5Zrwklb5WnKDSOzQ2WOFgkiBmtpOYPfvYd/n5r0=; X-MDAV-Processed: mail.consulintel.es, Thu, 06 Oct 2016 21:30:24 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 06 Oct 2016 21:30:21 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005172262.msg for ; Thu, 06 Oct 2016 21:30:21 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161006:md50005172262::60fg3Rh6LY6+bo9e:00000Aqo X-Return-Path: prvs=1087734226=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Thu, 06 Oct 2016 21:30:17 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> Thread-Topic: [sunset4] Sunset4 work Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:30:33 -0000 Despite how much I like all those ideas, I don't think we are ready to have= an IPv6-only IETF network. Unfortunately, there are many applications, VPNs, etc., which will not work= just with NAT64, because literals, etc. I will suggest something alternative at this stage: Having the IETF network as a typical SME or residential customer of an ISP = which has run out of IPv4 addresses, provides an IPv6-only WAN link and use= s CLAT (464XLAT) at the customer CPE. This means having GUA addresses but only private IPv4 address, and having a= router behaving as the IETF network =E2=80=9CCPE=E2=80=9D supporting CLAT. Of course we still need the NAT64+DNS64. This way, we will have a high proportion of IPv6 traffic and we can take so= me measurements about =E2=80=9Cwhat=E2=80=9D apps and Internet end-points a= re still using the NAT64/DNS64, and what apps are using the CLAT and we can= also have the secretariat or ISOC to make sure to talk with those organiza= tions to let know them that they have a problem =E2=80=A6 Saludos, Jordi -----Mensaje original----- De: sunset4 en nombre de Lee Howard Responder a: Fecha: jueves, 6 de octubre de 2016, 21:03 Para: Asunto: [sunset4] Sunset4 work After the last WG meeting, I walked away with seven things that I thoug= ht we needed to do: =20 =20 1. Update my v4historic draft. I intend to do this in time for the Seou= l meeting. 2. Phillip Hallam-Baker suggested something like "draft-baker-ipv4statu= s-its-complicated." I would like to hear more about this, and read a draft. 3. The IAB should tell partner SDOs that their work should support IPv6= . We're working on this, and should have an update before the meeting. 4. The IESG or IETF community should squelch IPv4-only charters. I thin= k the IESG would rather see a community statement, so we're hoping for a dr= aft in the next couple of weeks. 5. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-only exa= mples, IPv4 dependencies, and clean them up. Does anyone see a way to struc= ture this, or is there no followup to be had here? 6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari an= d Jim, and they're only reluctant if doing this impedes participants gettin= g work done. Does anyone have any ideas for how to show this? Volunteers? 7. Update id-nits checked to look for IPv4-only examples. Done! =20 I therefore think there's enough work to justify a meeting in Seoul, an= d have said so to the WG chairs.=20 =20 On this list, I'd like to hear ideas about how to structure work/follow= up on #5 and #6.=20 =20 Are there other topics we should discuss? =20 Thanks, =20 Lee =20 =20 =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Oct 6 13:22:22 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D4129430 for ; Thu, 6 Oct 2016 13:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZiY_3d73JM2 for ; Thu, 6 Oct 2016 13:22:18 -0700 (PDT) Received: from atl4mhob20.registeredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id 510C91293DF for ; Thu, 6 Oct 2016 13:22:17 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob20.registeredsite.com (8.14.4/8.14.4) with ESMTP id u96KMEUo043020 for ; Thu, 6 Oct 2016 16:22:14 -0400 Received: (qmail 24443 invoked by uid 0); 6 Oct 2016 20:22:14 -0000 X-TCPREMOTEIP: 204.235.114.162 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.116.238.146?) (lee@asgard.org@204.235.114.162) by 0 with ESMTPA; 6 Oct 2016 20:22:14 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Thu, 06 Oct 2016 16:22:13 -0400 From: Lee Howard To: , Message-ID: <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> In-Reply-To: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:22:19 -0000 On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" wrote: >Despite how much I like all those ideas, I don't think we are ready to hav= e an IPv6-only IETF network. > >Unfortunately, there are many applications, VPNs, etc., which will not wor= k just with NAT64, because literals, etc. Can you make a list? Or, can we start a list, and have people add things to it at the next meeti= ng, so we can work to resolve them by the following meeting? > >I will suggest something alternative at this stage: > >Having the IETF network as a typical SME or residential customer of an ISP= which has run out of IPv4 addresses, provides an IPv6-only WAN link and use= s CLAT (464XLAT) at the customer CPE. How well-tested is that in laptop environments? The only deployments I know= of are on mobile networks, which have a different set of applications and p= rotocols using them. Do you know of others? > >This means having GUA addresses but only private IPv4 address, and having = a router behaving as the IETF network =E2=80=9CCPE=E2=80=9D supporting CLAT. > >Of course we still need the NAT64+DNS64. > >This way, we will have a high proportion of IPv6 traffic and we can take s= ome measurements about =E2=80=9Cwhat=E2=80=9D apps and Internet end-points are still usi= ng the NAT64/DNS64, and what apps are using the CLAT and we can also have th= e secretariat or ISOC to make sure to talk with those organizations to let k= now them that they have a problem =E2=80=A6 Do you mean NAT64 on a different SSID as the 464xlat? I'm confused. Lee > > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 en nombre de Lee Howard >Responder a: >Fecha: jueves, 6 de octubre de 2016, 21:03 >Para: >Asunto: [sunset4] Sunset4 work > > After the last WG meeting, I walked away with seven things that I thou= ght we needed to do: > =20 > =20 > 1. Update my v4historic draft. I intend to do this in time for the Seo= ul meeting. > 2. Phillip Hallam-Baker suggested something like "draft-baker-ipv4stat= us-its-complicated." I would like to hear more about this, and read a draft. > 3. The IAB should tell partner SDOs that their work should support IPv= 6. We're working on this, and should have an update before the meeting. > 4. The IESG or IETF community should squelch IPv4-only charters. I thi= nk the IESG would rather see a community statement, so we're hoping for a dr= aft in the next couple of weeks. > 5. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-only ex= amples, IPv4 dependencies, and clean them up. Does anyone see a way to struc= ture this, or is there no followup to be had here? > 6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari a= nd Jim, and they're only reluctant if doing this impedes participants gettin= g work done. Does anyone have any ideas for how to show this? Volunteers? > 7. Update id-nits checked to look for IPv4-only examples. Done! > =20 > I therefore think there's enough work to justify a meeting in Seoul, a= nd have said so to the WG chairs.=20 > =20 > On this list, I'd like to hear ideas about how to structure work/follo= wup on #5 and #6.=20 > =20 > Are there other topics we should discuss? > =20 > Thanks, > =20 > Lee > =20 > =20 > =20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > =20 > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any disc= losure, copying, distribution or use of the contents of this information, in= cluding attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 From nobody Thu Oct 6 13:35:42 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15F1293DF for ; Thu, 6 Oct 2016 13:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4_PsSIsr7rn for ; Thu, 6 Oct 2016 13:35:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4212129430 for ; Thu, 6 Oct 2016 13:35:37 -0700 (PDT) Received: from [10.0.1.45] (h126.viagenie.ca [206.123.31.126]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0485B476E0; Thu, 6 Oct 2016 16:35:36 -0400 (EDT) From: "Marc Blanchet" To: "Lee Howard" Date: Thu, 06 Oct 2016 16:35:36 -0400 Message-ID: <2D3415E4-DBA9-49BC-B6C4-93C525B56C60@viagenie.ca> In-Reply-To: <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: sunset4@ietf.org, jordi.palet@consulintel.es Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:35:41 -0000 On 6 Oct 2016, at 16:22, Lee Howard wrote: > > On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" > > wrote: > >> Despite how much I like all those ideas, I don't think we are ready >> to have an IPv6-only IETF network. >> >> Unfortunately, there are many applications, VPNs, etc., which will >> not work just with NAT64, because literals, etc. > > Can you make a list? I created a link to create a page on the wg trac: https://tools.ietf.org/wg/sunset4/trac/wiki. Click on the link and it will create a new wiki page so people can put data. You need to login in before with your ietf credentials. However, (speaking as individual), I’m not sure we want to start that endeavour. Others have tried in the past and it is more complicated than it appears. marc. > Or, can we start a list, and have people add things to it at the next > meeting, so we can work to resolve them by the following meeting? > >> >> I will suggest something alternative at this stage: >> >> Having the IETF network as a typical SME or residential customer of >> an ISP which has run out of IPv4 addresses, provides an IPv6-only WAN >> link and uses CLAT (464XLAT) at the customer CPE. > > How well-tested is that in laptop environments? The only deployments I > know of are on mobile networks, which have a different set of > applications and protocols using them. Do you know of others? > >> >> This means having GUA addresses but only private IPv4 address, and >> having a router behaving as the IETF network “CPE” supporting >> CLAT. >> >> Of course we still need the NAT64+DNS64. >> >> This way, we will have a high proportion of IPv6 traffic and we can >> take some measurements about “what” apps and Internet end-points >> are still using the NAT64/DNS64, and what apps are using the CLAT and >> we can also have the secretariat or ISOC to make sure to talk with >> those organizations to let know them that they have a problem … > > Do you mean NAT64 on a different SSID as the 464xlat? I'm confused. > > Lee > >> >> >> Saludos, >> Jordi >> >> >> -----Mensaje original----- >> De: sunset4 en nombre de Lee Howard >> >> Responder a: >> Fecha: jueves, 6 de octubre de 2016, 21:03 >> Para: >> Asunto: [sunset4] Sunset4 work >> >> After the last WG meeting, I walked away with seven things that I >> thought we needed to do: >> >> >> 1. Update my v4historic draft. I intend to do this in time for the >> Seoul meeting. >> 2. Phillip Hallam-Baker suggested something like >> "draft-baker-ipv4status-its-complicated." I would like to hear more >> about this, and read a draft. >> 3. The IAB should tell partner SDOs that their work should support >> IPv6. We're working on this, and should have an update before the >> meeting. >> 4. The IESG or IETF community should squelch IPv4-only charters. I >> think the IESG would rather see a community statement, so we're >> hoping for a draft in the next couple of weeks. >> 5. WG Chairs and IETF communicty looks for IPv4 literals, >> IPv4-only examples, IPv4 dependencies, and clean them up. Does anyone >> see a way to structure this, or is there no followup to be had here? >> 6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with >> Jari and Jim, and they're only reluctant if doing this impedes >> participants getting work done. Does anyone have any ideas for how to >> show this? Volunteers? >> 7. Update id-nits checked to look for IPv4-only examples. Done! >> >> I therefore think there's enough work to justify a meeting in >> Seoul, and have said so to the WG chairs. >> >> On this list, I'd like to hear ideas about how to structure >> work/followup on #5 and #6. >> >> Are there other topics we should discuss? >> >> Thanks, >> >> Lee >> >> >> >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged >> or confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the >> contents of this information, including attached files, is >> prohibited. >> >> >> >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From nobody Thu Oct 6 14:16:53 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF5129776 for ; Thu, 6 Oct 2016 14:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 TkpQOr1b2F5r for ; Thu, 6 Oct 2016 14:16:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2694C129461 for ; Thu, 6 Oct 2016 14:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1475788604; x=1476393404; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=tyECcw+4kcGxmDRU02/2s+zbL pxP6UdO8F8TAPAUY50=; b=W72LGJR0u891Yme9ewxUSWwm+3mjlhM6GSXCVUOHA iRuOWxMwt3777v/tiMNy+OjY/nht8y75O2V7XjFwS+6BvUZRnlTsWqE2SovKSKtk b7re0oe3B3ZtyscLLRKz5vQy4QRQMVJQEENAVjiSk1KcEKPeYzYryJ3HMkeyqg+3 4w= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=mWmdpJOzazOr/zj9afC9OS3Mg4nY95uWabcfLO/65H/7X2IzesuXo6pT2Pfi /10ZrytqBXRQ5nibWUpjMtgClHzq/8my/K+BLMfqmWkCTIYfE81pxJDr/ O9ZWDf4x2x19SNj7bIutkZfI/1BlC5q3K0xYupE2Ez7Df/JmeBuQbg=; X-MDAV-Processed: mail.consulintel.es, Thu, 06 Oct 2016 23:16:44 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 06 Oct 2016 23:16:43 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005172412.msg for ; Thu, 06 Oct 2016 23:16:43 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161006:md50005172412::nXy5DGjBY36vQ0s/:00001Tvs X-Return-Path: prvs=1087734226=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Thu, 06 Oct 2016 23:16:38 +0200 From: JORDI PALET MARTINEZ To: , Message-ID: <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> In-Reply-To: <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:16:52 -0000 =20 On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" wrote: =20 >Despite how much I like all those ideas, I don't think we are ready to= have an IPv6-only IETF network. > >Unfortunately, there are many applications, VPNs, etc., which will not= work just with NAT64, because literals, etc. =20 Can you make a list? Or, can we start a list, and have people add things to it at the next m= eeting, so we can work to resolve them by the following meeting? =20 =20 The idea is not to create a list, on the other way around, is to use our = =E2=80=9Cbehaviour=E2=80=9D to discover what are the apps or destinations t= hat we use and don=E2=80=99t support IPv6, to create the =E2=80=9Clist=E2= =80=9D automatically. We just need some kind of logging of everything using the DNS64 or the CLAT= , which means is not IPv6 enabled. > >I will suggest something alternative at this stage: > >Having the IETF network as a typical SME or residential customer of an= ISP which has run out of IPv4 addresses, provides an IPv6-only WAN link an= d uses CLAT (464XLAT) at the customer CPE. =20 How well-tested is that in laptop environments? The only deployments I = know of are on mobile networks, which have a different set of applications = and protocols using them. Do you know of others? I recall having seen and OpenWRT implementation, and some Japanese CPEs. I= =E2=80=99m sure there are many others. =20 > >This means having GUA addresses but only private IPv4 address, and hav= ing a router behaving as the IETF network =E2=80=9CCPE=E2=80=9D supporting = CLAT. > >Of course we still need the NAT64+DNS64. > >This way, we will have a high proportion of IPv6 traffic and we can ta= ke some measurements about =E2=80=9Cwhat=E2=80=9D apps and Internet end-poi= nts are still using the NAT64/DNS64, and what apps are using the CLAT and w= e can also have the secretariat or ISOC to make sure to talk with those org= anizations to let know them that they have a problem =E2=80=A6 =20 Do you mean NAT64 on a different SSID as the 464xlat? I'm confused. =20 Just a single SSID. 464XLAT is two folds, NAT64/DNS64 on the =E2=80=9CISP= =E2=80=9D side, and CLAT on the CE or CPE. So you have 3 possible cases of =E2=80=9Capps=E2=80=9D: Basically, whatever in the IETF network is able to use IPv6 end-to-end, wil= l pass thru directly. If something is using DNS, then it will use the NAT64/DNS64 (single transla= tion 6->4 at the network). Whatever is using literals, will use both the CLAT (translation4->6 at the = CPE), and then translation at the NAT64 (4->6) =20 Lee =20 > > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 en nombre de Lee Howard >Responder a: >Fecha: jueves, 6 de octubre de 2016, 21:03 >Para: >Asunto: [sunset4] Sunset4 work > > After the last WG meeting, I walked away with seven things that I = thought we needed to do: > =20 > =20 > 1. Update my v4historic draft. I intend to do this in time for the= Seoul meeting. > 2. Phillip Hallam-Baker suggested something like "draft-baker-ipv4= status-its-complicated." I would like to hear more about this, and read a d= raft. > 3. The IAB should tell partner SDOs that their work should support= IPv6. We're working on this, and should have an update before the meeting. > 4. The IESG or IETF community should squelch IPv4-only charters. I= think the IESG would rather see a community statement, so we're hoping for= a draft in the next couple of weeks. > 5. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-onl= y examples, IPv4 dependencies, and clean them up. Does anyone see a way to = structure this, or is there no followup to be had here? > 6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with Ja= ri and Jim, and they're only reluctant if doing this impedes participants g= etting work done. Does anyone have any ideas for how to show this? Voluntee= rs? > 7. Update id-nits checked to look for IPv4-only examples. Done! > =20 > I therefore think there's enough work to justify a meeting in Seou= l, and have said so to the WG chairs.=20 > =20 > On this list, I'd like to hear ideas about how to structure work/f= ollowup on #5 and #6.=20 > =20 > Are there other topics we should discuss? > =20 > Thanks, > =20 > Lee > =20 > =20 > =20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > =20 > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged o= r confidential. The information is intended to be for the use of the indivi= dual(s) named above. If you are not the intended recipient be aware that an= y disclosure, copying, distribution or use of the contents of this informat= ion, including attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Oct 6 16:28:43 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ACF1294CB for ; Thu, 6 Oct 2016 16:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs_BlXuGCXmF for ; Thu, 6 Oct 2016 16:28:39 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF3D1294B6 for ; Thu, 6 Oct 2016 16:28:38 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 38CC125D3857 for ; Thu, 6 Oct 2016 23:28:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 68AE9D1F807 for ; Thu, 6 Oct 2016 23:28:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id sYnTWTxpQ5BU for ; Thu, 6 Oct 2016 23:28:35 +0000 (UTC) Received: from [10.111.64.116] (unknown [IPv6:fde9:577b:c1a9:4410:b553:ed4d:91d7:8c07]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 93E46D1F7E3 for ; Thu, 6 Oct 2016 23:28:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: sunset4@ietf.org Date: Thu, 06 Oct 2016 23:28:32 +0000 Message-ID: <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-Reply-To: <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6057) Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 23:28:41 -0000 On 6 Oct 2016, at 21:16, JORDI PALET MARTINEZ wrote: > > On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" > > wrote: > > >Despite how much I like all those ideas, I don't think we are > ready to have an IPv6-only IETF network. > > > >Unfortunately, there are many applications, VPNs, etc., which > will not work just with NAT64, because literals, etc. > > Can you make a list? > Or, can we start a list, and have people add things to it at the > next meeting, so we can work to resolve them by the following meeting? > > The idea is not to create a list, on the other way around, is to use > our “behaviour” to discover what are the apps or destinations that > we use and don’t support IPv6, to create the “list” > automatically. > > We just need some kind of logging of everything using the DNS64 or the > CLAT, which means is not IPv6 enabled. Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) if you want. Then have the ietf-legacy network, which would give you IPv4 and a portal page “penalty” that you have to state the nature why you have to use this network and can’t live on the default one. I’d be so curious to see what happens when people finally have to start thinking about it.. and open internal tickets .. It was great fun doing it 6-ish years ago, .. /bz From nobody Thu Oct 6 16:46:48 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ACB1294CD for ; Thu, 6 Oct 2016 16:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.897 X-Spam-Level: X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU2n4XP6hANd for ; Thu, 6 Oct 2016 16:46:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 C8D3B1294B6 for ; Thu, 6 Oct 2016 16:46:46 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7E6EC34941E; Thu, 6 Oct 2016 23:46:43 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0B432160055; Thu, 6 Oct 2016 23:46:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E097716005C; Thu, 6 Oct 2016 23:46:42 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mtLQKaCSPJkh; Thu, 6 Oct 2016 23:46:42 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 91B23160055; Thu, 6 Oct 2016 23:46:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3399055EA1B1; Fri, 7 Oct 2016 10:46:40 +1100 (EST) To: "Bjoern A. Zeeb" From: Mark Andrews References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-reply-to: Your message of "Thu, 06 Oct 2016 23:28:32 -0000." <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> Date: Fri, 07 Oct 2016 10:46:40 +1100 Message-Id: <20161006234640.3399055EA1B1@rock.dv.isc.org> Archived-At: Cc: sunset4@ietf.org Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 23:46:48 -0000 I would do this for all the mechanisms we have designed to provide IPv4 over IPv6 with a new one each meeting (I would suggest switching each day of the meeting but I suspect Jim would kill me). e.g. DS-LITE, MAP-* For DS-LITE I would even suggest that we do DS-LITE host mode at the end. Mark In message <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net>, "Bjoern A . Zeeb" writes: > On 6 Oct 2016, at 21:16, JORDI PALET MARTINEZ wrote: > > > > > On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" > > > > wrote: > > > > >Despite how much I like all those ideas, I don't think we are > > ready to have an IPv6-only IETF network. > > > > > >Unfortunately, there are many applications, VPNs, etc., which > > will not work just with NAT64, because literals, etc. > > > > Can you make a list? > > Or, can we start a list, and have people add things to it at the > > next meeting, so we can work to resolve them by the following meeting? > > > > The idea is not to create a list, on the other way around, is to use > > our behaviour to discover what are the apps or destinations that > > we use and dont support IPv6, to create the list > > automatically. > > > > We just need some kind of logging of everything using the DNS64 or the > > CLAT, which means is not IPv6 enabled. > > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) if you > want. Then have the ietf-legacy network, which would give you IPv4 and > a portal page penalty that you have to state the nature why you > have to use this network and cant live on the default one. Id be > so curious to see what happens when people finally have to start > thinking about it.. and open internal tickets .. It was great fun doing > it 6-ish years ago, .. > > /bz > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Oct 7 03:04:36 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CFA129551 for ; Fri, 7 Oct 2016 03:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsMWL1RAOyUr for ; Fri, 7 Oct 2016 03:04:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id EAD8412954E for ; Fri, 7 Oct 2016 03:04:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bsS10-0000EYC; Fri, 7 Oct 2016 12:04:30 +0200 Message-Id: To: sunset4@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-reply-to: Your message of "Thu, 06 Oct 2016 23:28:32 +0000 ." <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> Date: Fri, 07 Oct 2016 12:04:29 +0200 Archived-At: Cc: "Bjoern A. Zeeb" Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 10:04:34 -0000 In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) > if you want. Then have the ietf-legacy network, which would give > you IPv4 and a portal page penalty that you have to state the nature > why you have to use this network and cant live on the default one. > Id be so curious to see what happens when people finally have to > start thinking about it.. and open internal tickets .. It was > great fun doing it 6-ish years ago, .. Personally, I consider offering NAT64 over wifi quite absurd. The obvious way to provide access to legacy IPv4 is some form of NAT4. How it is transported over the rest of the network is upto the network operator. But the obvious interface is RFC 894. So on networks that promote NAT64 (FOSDEM has this setup for quite a number of years now) I just connect to the legacy network. Their legacy network has perfectly fine IPv6, so I consider it way better than the NAT64 that 'everybody' likes to push. For the specific mobile weirdness, NAT64 make sense. But everywhere else, requiring every device to have 464xlat to deal with IPv4 literals is just bad engineering. If your backbone is IPv6-only, then the obvious solution is to deal with this in CPEs, wifi access points, etc. Not to require all hosts to know the details of your network. From nobody Fri Oct 7 03:27:34 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59F8129551 for ; Fri, 7 Oct 2016 03:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 cSI5508cZhyj for ; Fri, 7 Oct 2016 03:27:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907951294B1 for ; Fri, 7 Oct 2016 03:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1475836047; x=1476440847; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Z3CkLOkhrB+faz+H5yrBoMIMt 1LIslMv/FoCT8mtvFo=; b=RxzPLTKwrUyJBDYuzx0gN1+1hqET5TsMg0O92xynx APHc6SMIK265PvfYZgqcETBHmi2AszFTecko1zjm9YyZDOmKUSFe1j6moOginwoF Q4nV5K22o2YehzuWOJQnYMBd+FNjTXXOIhISkknX7YKQjeF/WOajwiUJI/sbVvDF Rs= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=flC9fR+7eo0tj5ElQlIlQZU73E9sMsou0wb/Fp07dOwqr64KX0i0TjGgM5pO BDbiDEgd7F2KoNYD3Mu+jRzThO7UMFnnyCiPMT50Hx3tpO+EaUMYuZqDZ gXC7k1dLNW37XTiNYDcxSQmaxIj/ODOym4SoMoqWDe0nkxhQUBDZLY=; X-MDAV-Processed: mail.consulintel.es, Fri, 07 Oct 2016 12:27:27 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 07 Oct 2016 12:27:26 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005174117.msg for ; Fri, 07 Oct 2016 12:27:25 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161007:md50005174117::x8sG4Z/hxpzHO5hM:0000558u X-Return-Path: prvs=1088629e2d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 12:27:23 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 10:27:33 -0000 This is what I=E2=80=99m proposing. May be I miss explained it. NOT asking EVERY device in our network to HAVE 464XLAT client (CLAT), but h= aving ONLY our =E2=80=9CCPE=E2=80=9D to have it. Nodes will not notice anything. This is what is going to happen in the future in most of the networks becau= se they will not have IPv4 for every customer, so why not trying it ourselv= es? Already happening in many cellular networks, like in US, which are clos= e to have 60% IPv6 traffic already. Saludos, Jordi -----Mensaje original----- De: sunset4 en nombre de Philip Homburg Responder a: Fecha: viernes, 7 de octubre de 2016, 12:04 Para: CC: "Bjoern A. Zeeb" Asunto: Re: [sunset4] Sunset4 work In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) > if you want. Then have the ietf-legacy network, which would give > you IPv4 and a portal page penalty that you have to state the nature > why you have to use this network and cant live on the default one. > Id be so curious to see what happens when people finally have to > start thinking about it.. and open internal tickets .. It was > great fun doing it 6-ish years ago, .. =20 Personally, I consider offering NAT64 over wifi quite absurd. The obvio= us way to provide access to legacy IPv4 is some form of NAT4. How it is=20 transported over the rest of the network is upto the network operator. = But the obvious interface is RFC 894. =20 So on networks that promote NAT64 (FOSDEM has this setup for quite a nu= mber of years now) I just connect to the legacy network. Their legacy network h= as perfectly fine IPv6, so I consider it way better than the NAT64 that 'everybody' likes to push. =20 For the specific mobile weirdness, NAT64 make sense. But everywhere els= e, requiring every device to have 464xlat to deal with IPv4 literals is ju= st bad engineering. If your backbone is IPv6-only, then the obvious soluti= on is to deal with this in CPEs, wifi access points, etc. Not to require a= ll hosts to know the details of your network. =20 =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Oct 7 11:37:00 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411DE1296CB for ; Fri, 7 Oct 2016 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXJYnHTKQTM4 for ; Fri, 7 Oct 2016 11:36:57 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 943091296C3 for ; Fri, 7 Oct 2016 11:36:57 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u97IatXD019689 for ; Fri, 7 Oct 2016 14:36:55 -0400 Received: (qmail 7133 invoked by uid 0); 7 Oct 2016 18:36:55 -0000 X-TCPREMOTEIP: 204.235.114.162 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.116.238.146?) (lee@asgard.org@204.235.114.162) by 0 with ESMTPA; 7 Oct 2016 18:36:55 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Fri, 07 Oct 2016 14:36:54 -0400 From: Lee Howard To: Philip Homburg , Message-ID: Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "Bjoern A. Zeeb" Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:36:59 -0000 On 10/7/16, 6:04 AM, "sunset4 on behalf of Philip Homburg" wrote: >In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: >> Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) >> if you want. Then have the ietf-legacy network, which would give >> you IPv4 and a portal page penalty that you have to state the nature >> why you have to use this network and cant live on the default one. >> Id be so curious to see what happens when people finally have to >> start thinking about it.. and open internal tickets .. It was >> great fun doing it 6-ish years ago, .. > >Personally, I consider offering NAT64 over wifi quite absurd. The obvious >way to provide access to legacy IPv4 is some form of NAT4. How it is >transported over the rest of the network is upto the network operator. But >the obvious interface is RFC 894. We should do what we can to get ahead of the transition, noting what applications break, improving our experience with transition mechanisms, or whatever we can to make the transition smoother for the rest of the Internet. The fact that there is an IPv4 assignment to the IETF network does not mean other networks also have one, and we need to get ahead of what others will experience on their networks. > >So on networks that promote NAT64 (FOSDEM has this setup for quite a number of >years now) I just connect to the legacy network. Their legacy network has >perfectly fine IPv6, so I consider it way better than the NAT64 that >'everybody' likes to push. The ietf-legacy SSID would still be evailable. > >For the specific mobile weirdness, NAT64 make sense. But everywhere else, >requiring every device to have 464xlat to deal with IPv4 literals is just >bad engineering. If your backbone is IPv6-only, then the obvious solution >is to deal with this in CPEs, wifi access points, etc. Not to require all >hosts to know the details of your network. I mostly agree. Hosts (and users) shouldn't have to know what's going on. But the use of IPv4 literals is bad engineering; the fact that hacks are required to make it work is inherent. A lack of IPv6 support is abdication by application developers. Lee From nobody Fri Oct 7 11:40:35 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477961296CD for ; Fri, 7 Oct 2016 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93DWrLh8fXP7 for ; Fri, 7 Oct 2016 11:40:29 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id 47CD01296C5 for ; Fri, 7 Oct 2016 11:40:29 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u97IeQxr010001 for ; Fri, 7 Oct 2016 14:40:26 -0400 Received: (qmail 16825 invoked by uid 0); 7 Oct 2016 18:40:26 -0000 X-TCPREMOTEIP: 204.235.114.162 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.116.238.146?) (lee@asgard.org@204.235.114.162) by 0 with ESMTPA; 7 Oct 2016 18:40:26 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Fri, 07 Oct 2016 14:40:26 -0400 From: Lee Howard To: , Message-ID: <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:40:33 -0000 On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" wrote: >This is what I=E2=80=99m proposing. May be I miss explained it. > >NOT asking EVERY device in our network to HAVE 464XLAT client (CLAT), but = having ONLY our =E2=80=9CCPE=E2=80=9D to have it. > >Nodes will not notice anything. > >This is what is going to happen in the future in most of the networks beca= use they will not have IPv4 for every customer, so why not trying it ourselv= es? Already happening in many cellular networks, like in US, which are close= to have 60% IPv6 traffic already. You think 464xlat is what's going to happen in the future in most networks? Mobile networks, yes, it's a primary transition mechanisms. Wi-fi networks operated by ISPs or enterprises are more likely to use NAT64= , DS-Lite, or MAP, based on what I'm seeing people working on. My fear with 464xlat is that it's largely untested in environments like the= IETF. I would not support making it the default SSID. We've had a NAT64 SSI= D for several years; it could be promoted to default, if we can demonstrate = with confidence that everyone can still get their work done. Lee > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 en nombre de Philip Homburg >Responder a: >Fecha: viernes, 7 de octubre de 2016, 12:04 >Para: >CC: "Bjoern A. Zeeb" >Asunto: Re: [sunset4] Sunset4 work > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) > > if you want. Then have the ietf-legacy network, which would give > > you IPv4 and a portal page penalty that you have to state the nature > > why you have to use this network and cant live on the default one. > > Id be so curious to see what happens when people finally have to > > start thinking about it.. and open internal tickets .. It was > > great fun doing it 6-ish years ago, .. > =20 > Personally, I consider offering NAT64 over wifi quite absurd. The obvi= ous > way to provide access to legacy IPv4 is some form of NAT4. How it is=20 > transported over the rest of the network is upto the network operator.= But > the obvious interface is RFC 894. > =20 > So on networks that promote NAT64 (FOSDEM has this setup for quite a n= umber of > years now) I just connect to the legacy network. Their legacy network = has > perfectly fine IPv6, so I consider it way better than the NAT64 that > 'everybody' likes to push. > =20 > For the specific mobile weirdness, NAT64 make sense. But everywhere el= se, > requiring every device to have 464xlat to deal with IPv4 literals is j= ust > bad engineering. If your backbone is IPv6-only, then the obvious solut= ion > is to deal with this in CPEs, wifi access points, etc. Not to require = all > hosts to know the details of your network. > =20 > =20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > =20 > =20 > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any disc= losure, copying, distribution or use of the contents of this information, in= cluding attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 From nobody Fri Oct 7 13:02:08 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E821296FC for ; Fri, 7 Oct 2016 13:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 ye2py-NQBTO0 for ; Fri, 7 Oct 2016 13:02:05 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD72812943D for ; Fri, 7 Oct 2016 13:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1475870520; x=1476475320; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=IBNSzVo08xuOjNho9z3HCL8Eq RQJdn30kbPfxg4gvBI=; b=LQ48XCVlCzabLuWXpnoNbI/EJCyghRMUKZ2oOCw1s c1sICtEGpFN4pjffWpKWG/00D82G9ksoDR3A54/iKKYdrG8OhoEHJyDZlgaMB9bJ /zsTvMGbbCpVdiVDRCE7jsdgV3KNClYLMtZLTg9rxC9zCJbbsKRADN0zxgMwqJuR kw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=WPElkdBMypCSbDqGvJezPRtci1kHqHFM31aYrwenUmDKQckkwnVzg36kGrp5 CZVXwgCs7RKRDUsBtTqnT1IjcZ4jTGDoPXaZyYbx5p22Yi+I+jB6EZZWN pfNKndMVw1gKxiBa6kKhx7uc1SmAYR2KuCAOxRWXkjFPkQKTjEeOj0=; X-MDAV-Processed: mail.consulintel.es, Fri, 07 Oct 2016 22:02:00 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 07 Oct 2016 22:01:57 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005174489.msg for ; Fri, 07 Oct 2016 22:01:56 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161007:md50005174489::vnL/r0eHhZ0x2EkD:00000okY X-Return-Path: prvs=1088629e2d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 22:01:56 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> In-Reply-To: <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:02:07 -0000 On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" wrote: =20 >This is what I=E2=80=99m proposing. May be I miss explained it. > >NOT asking EVERY device in our network to HAVE 464XLAT client (CLAT), = but having ONLY our =E2=80=9CCPE=E2=80=9D to have it. > >Nodes will not notice anything. > >This is what is going to happen in the future in most of the networks = because they will not have IPv4 for every customer, so why not trying it ou= rselves? Already happening in many cellular networks, like in US, which are= close to have 60% IPv6 traffic already. =20 You think 464xlat is what's going to happen in the future in most netwo= rks? Mobile networks, yes, it's a primary transition mechanisms. Wi-fi networks operated by ISPs or enterprises are more likely to use N= AT64, DS-Lite, or MAP, based on what I'm seeing people working on. I disagree in several points: 1) 464XLAT is not only for cellular networks, just read the draft. 2) It has been implemented by some CPE vendors. It can be run in Virtual Ma= chines as well. a. http://www.necat.co.jp/en/ipv6/index.html b. https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_apni= c_464xlat.pdf 3) I=E2=80=99ve tested it in several ISP network. Trials at the time being,= but coming into production. 4) NAT64 is WORST than 464XLAT. NAT64 doesn=E2=80=99t sort out the problems= for apps using literals. 464XLAT sort it out. Yes, NAT64 was developed fir= st, but that=E2=80=99s the reason 464XLAT was needed, because not everythin= g was working in NAT64. 5) If you don=E2=80=99t trust 464XLAT, then you can=E2=80=99t trust in NAT6= 4, because is just an =E2=80=9Cincomplete=E2=80=9D version of 464XLAT. I agree with you that DS-Lite and MAP are other choices, comparable with 46= 4XLAT. They will be a better test, for sure than just NAT64. If you want something more lightweight than DS-Lite, probably will be bette= r to use lw4o6.=20 Just to make sure it has been understood: I=E2=80=99m not asking to impleme= nt anything in the clients of our network. Nobody needs to install anything= . We just need to have a VM or a set of them if we don=E2=80=99t trust on t= he hardware performance, as the =E2=80=9CCPE router=E2=80=9D of the IETF SS= IDs that we want to run this. This VM need to incorporate the CLAT client. = Our network will behave as an enterprise network which as only IPv6 native = connectivity to Internet, and the ISP (in this case our own network) will r= unning the PLAT (NAT64/DNS64). If you still want to try the NAT64 one more, you can have the NAT64 SSID, t= hat has been already tested in all the RIR meetings, etc. But this will not= run any apps that use literals, old APIs, etc. My fear with 464xlat is that it's largely untested in environments like= the IETF. I would not support making it the default SSID. We've had a NAT6= 4 SSID for several years; it could be promoted to default, if we can demons= trate with confidence that everyone can still get their work done. =E2=87=92 NAT64 as default is not and option. It breaks everything using li= terals. We want to have a good experience I guess, and be able to detect wh= at will fail in the future (logging CLAT and NAT64/DNS64 usage), not break = the IETF network. =20 Lee =20 > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 en nombre de Philip Homburg >Responder a: >Fecha: viernes, 7 de octubre de 2016, 12:04 >Para: >CC: "Bjoern A. Zeeb" >Asunto: Re: [sunset4] Sunset4 work > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) > > if you want. Then have the ietf-legacy network, which would giv= e > > you IPv4 and a portal page penalty that you have to state the na= ture > > why you have to use this network and cant live on the default on= e. > > Id be so curious to see what happens when people finally have to > > start thinking about it.. and open internal tickets .. It was > > great fun doing it 6-ish years ago, .. > =20 > Personally, I consider offering NAT64 over wifi quite absurd. The = obvious > way to provide access to legacy IPv4 is some form of NAT4. How it = is=20 > transported over the rest of the network is upto the network opera= tor. But > the obvious interface is RFC 894. > =20 > So on networks that promote NAT64 (FOSDEM has this setup for quite= a number of > years now) I just connect to the legacy network. Their legacy netw= ork has > perfectly fine IPv6, so I consider it way better than the NAT64 th= at > 'everybody' likes to push. > =20 > For the specific mobile weirdness, NAT64 make sense. But everywher= e else, > requiring every device to have 464xlat to deal with IPv4 literals = is just > bad engineering. If your backbone is IPv6-only, then the obvious s= olution > is to deal with this in CPEs, wifi access points, etc. Not to requ= ire all > hosts to know the details of your network. > =20 > =20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > =20 > =20 > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged o= r confidential. The information is intended to be for the use of the indivi= dual(s) named above. If you are not the intended recipient be aware that an= y disclosure, copying, distribution or use of the contents of this informat= ion, including attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Oct 17 09:04:24 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A012988F for ; Mon, 17 Oct 2016 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ken5Z4fvhbYv for ; Mon, 17 Oct 2016 09:04:19 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.109]) (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 F1487129882 for ; Mon, 17 Oct 2016 09:04:15 -0700 (PDT) Received: from [193.109.254.147] by server-5.bemta-6.messagelabs.com id 15/D5-29563-E76F4085; Mon, 17 Oct 2016 16:04:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleJIrShJLcpLzFFi42KZ+u+jj27tN5Y Ig74v0hZ/j39mtli5Zz+7A5PHuv0BHkuW/GQKYIpizcxLyq9IYM3o/7KftWDGVMaKPXc+sjQw LpjM2MXIxSEksIVRYsbsW1DOAUaJJxPeMEM4JxglZs2aBeRwcrAJ6Eq0z1oFZosIpEosePWFD cQWFlCW+PygkREiriIxY+J1Vgg7SWLLtY1gNouAqkTrtEtANRwcvAKhEq03dCHmr2eWmH3+Cl gNp4CTxN4HZ8DmMArISnxpXA22i1lAXOLWk/lMILaEgIDEkj3nmSFsUYmXj/+xQtgKEpcWdbG CzGcW0JRYv0sfolVRYkr3Q3YQm1dAUOLkzCcsExhFZiGZOguhYxaSjllIOhYwsqxi1ChOLSpL LdI1MtdLKspMzyjJTczM0TU0MNPLTS0uTkxPzUlMKtZLzs/dxAiMFgYg2MG4eG3gIUZJDiYlU d64DywRQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4q78C5QSLUtNTK9Iyc4BxC5OW4OBREuE99Q UozVtckJhbnJkOkTrFqMvxo+P+WiYhlrz8vFQpcd4okBkCIEUZpXlwI2Ap5BKjrJQwLyPQUUI 8BalFuZklqPKvGMU5GJWEeV+CrOLJzCuB2/QK6AgmoCPO5YEdUZKIkJJqYIzvrw0xfhJmmXVB oc+gXVnlQ6JZea/hhSnv911I29n6vXffvIAI1wo57qqcRbOXvZ03UfHBGpGtasq9crzeTpaSc 18qtQeve35/RZHXDcuDDjfcWrfm6E+c8KXsSZLs19ndyo4H+PRVVRXvr/7OwZgvkrTJqac8wu ekxeZ1VivObH+59vjJLUosxRmJhlrMRcWJADOUSiMcAwAA X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-14.tower-27.messagelabs.com!1476720253!53334705!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 41063 invoked from network); 17 Oct 2016 16:04:13 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Oct 2016 16:04:13 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Mon, 17 Oct 2016 17:04:11 +0100 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Mon, 17 Oct 2016 17:04:12 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0279.002; Mon, 17 Oct 2016 17:04:12 +0100 From: "Heatley, Nick" To: "jordi.palet@consulintel.es" , "sunset4@ietf.org" Thread-Topic: [sunset4] Sunset4 work Thread-Index: AQHSIAgRtByCj90yWkOply3Hcs4up6CbzdGAgAAPNACAACTaAIAAwoBd///1lYCAAInCAIAAFsUAgApY3sA= Date: Mon, 17 Oct 2016 16:04:11 +0000 Message-ID: <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> In-Reply-To: <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:04:22 -0000 QSB0aG91Z2h0IHByb3Zva2luZyBkaXNjdXNzaW9uLgpJIGRvbid0IHRoaW5rIHRoZSBzcGVjaWZp YyB0cmFuc2l0aW9uIHRlY2hub2xvZ3kgbWF0dGVycyBzbyBtdWNoIGFzIHRoZSAiZmFtaWx5IiBp dCBmYWxscyBpbnRvLiAKV2hhdCBtYXR0ZXJzIGlzIHdoZXRoZXIgSUVURiB3aXNoZXMgdG8gc2hv d2Nhc2UgSVB2Ni1vbmx5IGRvd24gdG8gdGhlIGN1c3RvbWVyIGNsaWVudCBkZXZpY2VzIChhbmQg dGhlbiB0byBoYXJ2ZXN0IHRoZSBleHBlY3RlZCBjbGllbnQgaXNzdWVzLCBJUHNlYyBmYWlsaW5n PyksIG9yIHdoZXRoZXIgaXQgd2lzaGVzIHRvIHNob3djYXNlICJsb2NhbCBkdWFsc3RhY2sgb24g dGhlIHNtYWxsLXN0dWItbmV0d29yaywgd2l0aCBhbiBJUHY2LW9ubHkgcHJvdmlkZXIgY29ubmVj dGlvbiIgdG8gc2hvdyBob3cgc21hbGwtc3R1Yi1uZXR3b3JrcyBjb3VsZCBiZSBjb25uZWN0ZWQg aW4gdGhlIGZ1dHVyZS4KCkxldCBtZSBleHBsYWluIChsb25nZXIgYW5zd2VyKS4KSW4gYSBudW1i ZXIgb2YgeWVhcnMnIHRpbWUsIGFzIHByb3ZpZGVycyBydW4gb3V0IG9mIElQdjQgcHVibGljcywg ZWRnZSAibmV0d29ya3MiIHdpbGwgYmUgYnJvdWdodCBvbiB3aXRoIG9ubHkgZ2xvYmFsIElQdjYg YWRkcmVzc2luZyBhdmFpbGFibGUgYXMgdGhlIHBlcnNpc3RlbnQgaWRlbnRpZmllciBmb3IgY29u bmVjdGVkIGVuZHBvaW50cy4gKEkgYW0gYXNzdW1pbmcgaW4gU3Vuc2V0NCB3ZSBjYW4gYWdyZWUg b24gdGhhdCkuCkJ1dCB3aGF0IGFkZHJlc3NpbmcgaXMgd2l0aGluIHRoZSBlZGdlIG5ldHdvcms/ CjEuIEZvciBsYXJnZSBlZGdlIG5ldHdvcmtzIHdoZXJlIHByaXZhdGUgYWRkcmVzc2luZyBudW1i ZXJzIGFyZSBub3Qgc3VmZmljaWVudCB0byBtZWV0IHRoZSBudW1iZXIgb2YgY29ubmVjdGVkIGRl dmljZXMsIHRoZXkgd2lsbCBuZWVkIHRvIGdvIElQdjYtb25seSwgYXMgd2UgaGF2ZSBzZWVuIHdp dGggbGFyZ2UgbW9iaWxlIG9wZXJhdG9ycywgYW5kIGxlYXJudCB3aXRoIE1pY3Jvc29mdCBFbnRl cnByaXNlLCBGYWNlYm9vayBldGMuIFRoZXNlIG5ldHdvcmtzIGFsbCBzYXkgcHJpdmF0ZSBJUHY0 IGFkZHJlc3NpbmcgaXMgbm90IHN1ZmZpY2llbnQuCjIuIEZvciBzbWFsbGVyIGVudGVycHJpc2Ug ZWRnZSBuZXR3b3JrcyB0aGVuIHRoZXkgbWF5IHdlbGwgYmUgc2l0dGluZyBhbmQgd2FpdGluZywg b3IgZm9sbG93aW5nIHRoZSBhYm92ZSwgdGltZSB3aWxsIHRlbGwuCjMuIEZvciAic21hbGwtc3R1 Yi1uZXR3b3JrcyIgKFNTTiksIHdoZXJlIHRoZSBudW1iZXIgb2YgY29ubmVjdGVkIGRldmljZXMg aXMgbWFuYWdlYWJsZSB0aGVuIGNsZWFybHkgSVB2NCBwcml2YXRlIGFkZHJlc3NpbmcgaXMgc3Vm ZmljaWVudC4gIFB1YmxpYyBXaWZpIGFjY2VzcyBiZWluZyBhIHBlcmZlY3QgZXhhbXBsZSBvZiBT U04sIG9yIGFueSBtb2RlbCB1c2luZyBhIGNvbnN1bWVyIENQRSBJIHN1cHBvc2UuIFNvIHRoaXMg aXMgdGhlIHF1ZXN0aW9uIGZvciBzdW5zZXQ0OgooQSkgRG8gd2Ugd2lzaCB0byBhZHZvY2F0ZSBJ UHY2LW9ubHkgaW4gdGhpcyBTU04gc2NlbmFyaW8/IGluIHdoaWNoIGNhc2UgYWxsIGN1cnJlbnQg YW5kIGZ1dHVyZSBjbGllbnQgaXNzdWVzIG11c3QgYmUgcmVzb2x2ZWQgKElQdjQgbGl0ZXJhbHMp IHN1Y2ggdGhhdCB0aGUgY2xpZW50cyB3b3JrIGluIHRoZSBhYnNlbmNlIG9mIGFuIElQdjQgYWRk cmVzcz8gVGhpcyBjYXNlIGlzIHR5cGlmaWVkIGJ5IE5BVDY0L0ROUzY0LCBvdGhlciB0cmFuc2l0 aW9uIG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJsZS4KKEIpIERvIHdlIHdpc2ggdG8gYWR2b2NhdGUg ZHVhbHN0YWNrIG5ldHdvcmtpbmcgdG8gdGhlIGNsaWVudCBpbiB0aGlzIFNTTiBzY2VuYXJpbz8g QXZvaWQgY2xpZW50IGlzc3VlcyBieSBwcm92aWRpbmcgdGhlbSB3aXRoIGEgR1VBIGFuZCBhIElQ djQgcHJpdmF0ZT8gSW4gd2hpY2ggY2FzZSB0aGUgdHJhbnNpdGlvbiB0ZWNobm9sb2d5IChoZWxk IHdpdGhpbiB0aGUgQ1BFKSBuZWVkcyB0byBlbmFibGUgZHVhbHN0YWNrIG9uIHRoZSBhY2Nlc3Mg c2lkZSBidXQgb24gdGhlIHByb3ZpZGVyIHNpZGUsIGNvcGUgd2l0aCBvbmx5IGFuIElQdjYtb25s eSBwcm92aWRlciBjb25uZWN0aW9uLiA0NjR4bGF0IGluIHRoZSBDUEUgKGxpa2UgNDY0eGxhdCBi YXNlZCB0ZXRoZXJpbmcgZnJvbSBhIGNlbGx1bGFyIGhhbmRzZXQpIGlzIGFuIGV4YW1wbGUgb2Yg YSB0cmFuc2l0aW9uIHRlY2hub2xvZ3kgaW4gdGhpcyBmYW1pbHksIG90aGVycyBhcmUgYXZhaWxh YmxlLgoKQm90aCBvZiB0aGVzZSBTU04gYXBwcm9hY2hlcyBhc3N1bWUgdGhhdCB3aXRoaW4gdGhl IGNvcmUgb2YgdGhlIGludGVybmV0IHRoZWlyIHJlbWFpbnMgdGhlIGxlZ2FjeSBJUHY0LW9ubHkg Y29udGVudCwgd2hpY2ggc2VlbXMgdmFsaWQgZm9yICJjb25zdW1lciBlbGVjdHJvbmljcyBuZXR3 b3JraW5nIiBpbiBnZW5lcmFsLgpUaGV5IGRpZmZlciBvbiBob3cgd2UgZXhwZWN0IGNvbnN1bWVy IGVsZWN0cm9uaWNzIG5ldHdvcmtpbmcgdG8gZXZvbHZlIChvciBob3cgd2UgKndhbnQqIGl0IHRv IGV2b2x2ZSkuIFdlIGNvdWxkIGFkdm9jYXRlIGJvdGggZm9yIHN1cmUsIGJ1dCBub3Qgc3VyZSBp ZiB0aGF0IGhlbHBzIG1vdmUgc3Vuc2V0NCBmb3J3YXJkIQoKTXkgb3BpbmlvbiwgdGFrZSBpdCBv ciBsZWF2ZSBpdCwgaXMgdGhhdCBwcmFnbWF0aWNhbGx5LCBhIFNTTiB2aXNpb24gYmFzZWQgb24g KEIpIGlzIGxlc3MgcHJvYmxlbWF0aWMuIEl0IGlzIGxlc3MgZGVwZW5kZW50IG9uIG1vdmluZyBh IHdob2xlIGNvbGxlY3Rpb24gb2YgQ29uc3VtZXIgRWxlY3Ryb25pY3MgYXdheSBmcm9tIHRvZGF5 J3MgZGVmaWNpZW50IHN0YXRlLCBiZWNhdXNlIChBKSBlc3NlbnRpYWwgZGVtYW5kcyB0aGV5IHdv cmsgaW4gYWJzZW5jZSBvZiBJUHY0LiBUaGlzIHJlcXVpcmVzIGNvbmNlcnRlZCBlZmZvcnQgdG8g cmVtb3ZlIHRoZSAiSVB2Ni1vbmx5IiBtb2RlIGJ1Z3MgdGhhdCB3ZSBrbm93IGV4aXN0LgpUaGUg YmlnZ2VzdCBwcm9ibGVtIHdpdGggKEEpIGlzIHRoYXQgeW91IGNhbm5vdCBtYWtlIHRoZSBuZXR3 b3JrIG1vZGVsIHRoZSBjb21wdWxzb3J5IG1vZGVsLCB1bnRpbCB0aGUgbWFqb3JpdHkgb2YgQ29u c3VtZXIgRWxlY3Ryb25pY3MgaXMgZnVsbHkgcmVhZHksIHdoaWNoIGNyZWF0ZXMgYW5vdGhlciBu ZXR3b3JrIHByb3ZpZGVyIGNoaWNrZW4tZWdnIHByb2JsZW0uIFlvdSBjYW4gZG8gT1MgYnkgT1Mg KHNvbWV0aGluZyB0aGF0IGEgcG9wdWxhciBzbWFydHBob25lIGFuZCBQQyB2ZW5kb3IgaXMgYXR0 ZW1wdGluZyB3aXRoIElQdjYtb25seSwgTkFUNjQpIGJ1dCBuZXR3b3JrIHByb3ZpZGVycyBkb24n dCB3aXNoIHRvIGNyZWF0ZSBpbmRpdmlkdWFsIG5ldHdvcmsgcGFyYWRpZ21zIGZvciBlYWNoIE9T LgoKVGhlbiB3ZSBsb29rIGJhY2sgYXQgMi4sIGFib3ZlLiBFbnRlcnByaXNlcyBtb3ZpbmcgdG8g SVB2Ni1vbmx5IC0gZG8gd2UgaGF2ZSBzb21lIG5lZWQgYW5kIG9ibGlnYXRpb24gd2l0aGluIFN1 bnNldDQgdG8gcHVzaCAoQSkgdG8gYXZvaWQgRW50ZXJwcmlzZXMgYmVpbmcgdHJhcHBlZCBpbiBh biBJUHY0IHdvcmxkPyBUbyBsZWF2ZSBkdWFsc3RhY2sgaW4gb25lIHBhcnQgb2YgdGhlIGVkZ2Ug KFNTTikgLSBkb2VzIGl0IHVuZGVybWluZSB0aGUgYmVuZWZpdHMgd2UgYXJlIHRlbGxpbmcgZW50 ZXJwcmlzZXMgb24gSVB2Ni1vbmx5IGUuZy4gcmVtb3ZhbCBvZiBkdWFsIGFkZHJlc3MgY29tcGxl eGl0eS4gUGVyc29uYWxseSBJIGJlbGlldmUgdGhpcyBpcyBvbmx5IHJlYWxseSBhbiBpc3N1ZSBp biBwcmFjdGljZSB3aGVyZSB0aGUgZW50ZXJwcmlzZSBpcyBzbyBsYXJnZSB0aGF0IHRoZSAyME0g cHJpdmF0ZSBhZGRyZXNzZXMgYXJlIG5vdCBzdWZmaWNpZW50IGZvciB0aGVpciBvcmdhbmlzYXRp b24gLSBhbmQgSSB0aGluayBzdWNoIGVudGVycHJpc2VzIGFyZSBiaWcgZW5vdWdoIHRvIHByb2dy ZXNzIHRoaXMgaXNzdWUgdGhlbXNlbHZlcyBpZiB0aGV5IHdpc2ggSVB2Ni1vbmx5IHRvIHdvcmsg Zm9yIHRoZW0uIEJ1dCBpZiAoQSkgaXMgY29uc2Vuc3VzIHRoZW4gU3Vuc2V0NCBzaG91bGQgc3Rh cnQgdG8gZGVmaW5lIHRoZSBjbGllbnQgcmVxdWlyZW1lbnRzIGZvciBhYnNlbmNlIG9mIElQdjQg aW4gYSBTU04uIEFuZCB1bmxpa2UgcHJvdmlkZXIgbmV0d29ya3MsIGVudGVycHJpc2UgbmV0d29y a3Mgb3duIGFuZCBtYW5hZ2UgdGhlIGVuZCB0byBlbmQgbmV0d29yayB1c2UgY2FzZSB0aGVtc2Vs dmVzLgoKVGhlIG90aGVyIGNvbmNlcm4gZm9yIG1lIGFib3V0IChBKSBpcyB0aGF0IEkgaGF2ZSBh bHJlYWR5IG92ZXJzaW1wbGlmaWVkIGRldmljZXMgYXMgImNvbnN1bWVyIGVsZWN0cm9uaWNzIiBh cyB0aG91Z2ggdGhleSBvbmx5IGZhbGwgaW50byB0aGUgaGFuZHMgb2YgY29uc3VtZXJzIGluIGNv bnN1bWVyIHVzZWNhc2VzLgpPbmUgb2YgdGhlIGJpZyBpc3N1ZXMgSSBmb3Jlc2VlIHdpdGggdGhl IElQdjYtb25seSBhcHByb2FjaCBvZiBjZXJ0YWluIE9TIHZlbmRvcihzKSBpcyB0aGF0IHNvbWV0 aGluZyBsaWtlIGEgc21hcnRwaG9uZSBjYW4gYmUgYW4gZW5kIGRldmljZSB3aXRoIGl0cyBuZXR3 b3JrIGludGVyZmFjZSBzZXJ2aWNpbmcgIm9uIGJvYXJkIEFwcHMiICh0eXBpY2FsIG1vYmlsZSBj b25uZWN0aXZpdHkpLCBidXQgaXQgY2FuIGFsc28gYmUgYSBuZXR3b3JrIGdhdGV3YXkgd2hlbiB1 c2VkIGZvciB0ZXRoZXJpbmcgb3IgImludGVybmV0IHNoYXJpbmciLiBUaGUgZW5kIGRldmljZSAo dGhlIGRldmljZSB0ZXRoZXJlZCBvbiB0aGUgZW5kIG9mIHRoZSB3aWZpIGxpbmspIG1heSBhY3R1 YWxseSBiZSBpbiBhbiBlbnRlcnByaXNlIHVzZSBjYXNlICgiVlBOIGludG8gYW4gb2ZmaWNlIG5l dHdvcmsiIGZvciBleGFtcGxlKS4gQnkgbWFraW5nIHRoZSBTU04gSVB2Ni1vbmx5IHdlIG1heSBy aXNrIHBsYWNpbmcgcmVxdWlyZW1lbnRzIG9uIHRoZSBlbnRlcnByaXNlIG5ldHdvcmsgKGkuZS4g b3V0c2lkZS1pbiBjb25uZWN0aXZpdHkgbGlrZSB0aGUgVlBOIGNvbmNlbnRyYXRvciwgbWF5IG5l ZWQgY2VydGFpbiBmdW5jdGlvbmFsaXR5IHRvIHRlcm1pbmF0ZSBhbiBJUHY2IElQc2VjIFZQTiBl dGMuKS4gV2UgbWF5IG5lZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgKEEpIG5vdCBqdXN0IGJlIGFi b3V0IGVuZCBkZXZpY2VzIGJ1dCBhbHNvIGNvb3JkaW5hdGluZyByZXF1aXJlbWVudHMgZm9yIHZh cmlvdXMgZ2F0ZXdheXMgaW4gZW50ZXJwcmlzZSBuZXR3b3Jrcz8gSWYgeW91IGJlbGlldmUgdGhh dCwgaXQgaXMgYW5vdGhlciBzZXJpb3VzIGNoaWNrZW4tZWdnIHByb2JsZW07IGRvIHdlIG5lZWQg ZW50ZXJwcmlzZSBuZXR3b3JrcyB1cGdyYWRlZCBiZWZvcmUgd2UgY2FuIG1vdmUgdG8gYSBzb2x1 dGlvbiBmb3IgU1NOcz8gKFNlZSB0aGUgSVBzZWMgY29tbWVudHMgaW4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzcyNjkjc2VjdGlvbi02LjEgYnV0IGluIHRoZSBnZW5lcmFsIGNhc2Ug SVBzZWMgVlBOIGlzIGEgZmFpbCwgcmlnaHQ/KQogSSBhbSB2ZXJ5IG11Y2ggaW4gZmF2b3VyIG9m IHRoZSBmYW1pbHkgb2YgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgdGhhdCBlbmFibGUgKEIpLgoK U08gSSBpbmZlcnJlZCBhIGRlZmluaXRpb24gb2YgdGhlIHRlcm0gU1NOIHRvIHN1aXQgbXkgbmVl ZHMgaW4gdGhpcyBtYWlsLiBXaGF0IGlzIHJlYWxseSBib2lscyBkb3duIHRvIGlzIHRoYXQgZWRn ZSBuZXR3b3JrcyBuZWVkIHNvbWUgc29ydCBvZiBDUEUgb3IgR2F0ZXdheSB0byB0aGUgcHJvdmlk ZXIgbmV0d29yay4gRG8gd2Ugd2FudCB0aGF0IENQRSB0byBwcm92aWRlIGR1YWxzdGFjayBsb2Nh bGx5IG9yIElQdjYtb25seSB3aGVuIHRoZSBwcm92aWRlciBhZGRyZXNzZXMgcnVuIG91dC4KQmFj ayB0byB0aGUgSUVURiBTU0lELCB3aGF0IFNTTiB2aXNpb24gZG8geW91IHdpc2ggdG8gc2hvd2Nh c2U/IChJJ2QgcHJlZmVyIGEgY2hvaWNlIGZvciBsb25nIHRlcm0gcmF0aGVyIHRoYW4gImZvciBu ZXh0IG1lZXRpbmciIGFuZCBJJ2QgZ28gZm9yIHNvbWV0aGluZyBsaWtlIEpvcmRpJ3MgNDY0eGxh dCBpbiB0aGUgQ1BFISBDaG9vc2Ugd2lzZWx5IDotKQpJZiBhbiBJUHY2LW9ubHkgU1NJRCBpcyBq dXN0IHRvIHNob3djYXNlIElQc2VjIFZQTnMgc3RpbGwgZmFpbGluZywgaXQgaXMgYSBiaXQgb2Yg YSB3YXN0ZSBvZiBwZW9wbGUncyB0aW1lKS4KUmVnYXJkcywKTmljawoKCgoKCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCkZyb206IHN1bnNldDQgW21haWx0bzpzdW5zZXQ0LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKT1JESSBQQUxFVCBNQVJUSU5FWgpTZW50OiAwNyBPY3RvYmVy IDIwMTYgMjE6MDIKVG86IApTdWJqZWN0OiBSZTogW3N1bnNldDRdIFN1bnNldDQgd29yawoKICAg IE9uIDEwLzcvMTYsIDY6MjcgQU0sICJzdW5zZXQ0IG9uIGJlaGFsZiBvZiBKT1JESSBQQUxFVCBN QVJUSU5FWiIgPHN1bnNldDQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam9yZGkucGFs ZXRAY29uc3VsaW50ZWwuZXM+IHdyb3RlOgogICAgCiAgICA+VGhpcyBpcyB3aGF0IEnigJltIHBy b3Bvc2luZy4gTWF5IGJlIEkgbWlzcyBleHBsYWluZWQgaXQuCiAgICA+CiAgICA+Tk9UIGFza2lu ZyBFVkVSWSBkZXZpY2UgaW4gb3VyIG5ldHdvcmsgdG8gSEFWRSA0NjRYTEFUIGNsaWVudCAoQ0xB VCksIGJ1dCBoYXZpbmcgT05MWSBvdXIg4oCcQ1BF4oCdIHRvIGhhdmUgaXQuCiAgICA+CiAgICA+ Tm9kZXMgd2lsbCBub3Qgbm90aWNlIGFueXRoaW5nLgogICAgPgogICAgPlRoaXMgaXMgd2hhdCBp cyBnb2luZyB0byBoYXBwZW4gaW4gdGhlIGZ1dHVyZSBpbiBtb3N0IG9mIHRoZSBuZXR3b3JrcyBi ZWNhdXNlIHRoZXkgd2lsbCBub3QgaGF2ZSBJUHY0IGZvciBldmVyeSBjdXN0b21lciwgc28gd2h5 IG5vdCB0cnlpbmcgaXQgb3Vyc2VsdmVzPyBBbHJlYWR5IGhhcHBlbmluZyBpbiBtYW55IGNlbGx1 bGFyIG5ldHdvcmtzLCBsaWtlIGluIFVTLCB3aGljaCBhcmUgY2xvc2UgdG8gaGF2ZSA2MCUgSVB2 NiB0cmFmZmljIGFscmVhZHkuCiAgICAKICAgIFlvdSB0aGluayA0NjR4bGF0IGlzIHdoYXQncyBn b2luZyB0byBoYXBwZW4gaW4gdGhlIGZ1dHVyZSBpbiBtb3N0IG5ldHdvcmtzPwogICAgTW9iaWxl IG5ldHdvcmtzLCB5ZXMsIGl0J3MgYSBwcmltYXJ5IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4KICAg IFdpLWZpIG5ldHdvcmtzIG9wZXJhdGVkIGJ5IElTUHMgb3IgZW50ZXJwcmlzZXMgYXJlIG1vcmUg bGlrZWx5IHRvIHVzZSBOQVQ2NCwgRFMtTGl0ZSwgb3IgTUFQLCBiYXNlZCBvbiB3aGF0IEknbSBz ZWVpbmcgcGVvcGxlIHdvcmtpbmcgb24uCgpJIGRpc2FncmVlIGluIHNldmVyYWwgcG9pbnRzOgox KSA0NjRYTEFUIGlzIG5vdCBvbmx5IGZvciBjZWxsdWxhciBuZXR3b3JrcywganVzdCByZWFkIHRo ZSBkcmFmdC4KMikgSXQgaGFzIGJlZW4gaW1wbGVtZW50ZWQgYnkgc29tZSBDUEUgdmVuZG9ycy4g SXQgY2FuIGJlIHJ1biBpbiBWaXJ0dWFsIE1hY2hpbmVzIGFzIHdlbGwuCmEuIGh0dHA6Ly93d3cu bmVjYXQuY28uanAvZW4vaXB2Ni9pbmRleC5odG1sCmIuIGh0dHBzOi8vY29uZmVyZW5jZS5hcG5p Yy5uZXQvX19kYXRhL2Fzc2V0cy9wZGZfZmlsZS8wMDEzLzUwNzAxLzM0dGhfYXBuaWNfNDY0eGxh dC5wZGYKMykgSeKAmXZlIHRlc3RlZCBpdCBpbiBzZXZlcmFsIElTUCBuZXR3b3JrLiBUcmlhbHMg YXQgdGhlIHRpbWUgYmVpbmcsIGJ1dCBjb21pbmcgaW50byBwcm9kdWN0aW9uLgo0KSBOQVQ2NCBp cyBXT1JTVCB0aGFuIDQ2NFhMQVQuIE5BVDY0IGRvZXNu4oCZdCBzb3J0IG91dCB0aGUgcHJvYmxl bXMgZm9yIGFwcHMgdXNpbmcgbGl0ZXJhbHMuIDQ2NFhMQVQgc29ydCBpdCBvdXQuIFllcywgTkFU NjQgd2FzIGRldmVsb3BlZCBmaXJzdCwgYnV0IHRoYXTigJlzIHRoZSByZWFzb24gNDY0WExBVCB3 YXMgbmVlZGVkLCBiZWNhdXNlIG5vdCBldmVyeXRoaW5nIHdhcyB3b3JraW5nIGluIE5BVDY0Lgo1 KSBJZiB5b3UgZG9u4oCZdCB0cnVzdCA0NjRYTEFULCB0aGVuIHlvdSBjYW7igJl0IHRydXN0IGlu IE5BVDY0LCBiZWNhdXNlIGlzIGp1c3QgYW4g4oCcaW5jb21wbGV0ZeKAnSB2ZXJzaW9uIG9mIDQ2 NFhMQVQuCgpJIGFncmVlIHdpdGggeW91IHRoYXQgRFMtTGl0ZSBhbmQgTUFQIGFyZSBvdGhlciBj aG9pY2VzLCBjb21wYXJhYmxlIHdpdGggNDY0WExBVC4gVGhleSB3aWxsIGJlIGEgYmV0dGVyIHRl c3QsIGZvciBzdXJlIHRoYW4ganVzdCBOQVQ2NC4KCklmIHlvdSB3YW50IHNvbWV0aGluZyBtb3Jl IGxpZ2h0d2VpZ2h0IHRoYW4gRFMtTGl0ZSwgcHJvYmFibHkgd2lsbCBiZSBiZXR0ZXIgdG8gdXNl IGx3NG82LiAKCkp1c3QgdG8gbWFrZSBzdXJlIGl0IGhhcyBiZWVuIHVuZGVyc3Rvb2Q6IEnigJlt IG5vdCBhc2tpbmcgdG8gaW1wbGVtZW50IGFueXRoaW5nIGluIHRoZSBjbGllbnRzIG9mIG91ciBu ZXR3b3JrLiBOb2JvZHkgbmVlZHMgdG8gaW5zdGFsbCBhbnl0aGluZy4gV2UganVzdCBuZWVkIHRv IGhhdmUgYSBWTSBvciBhIHNldCBvZiB0aGVtIGlmIHdlIGRvbuKAmXQgdHJ1c3Qgb24gdGhlIGhh cmR3YXJlIHBlcmZvcm1hbmNlLCBhcyB0aGUg4oCcQ1BFIHJvdXRlcuKAnSBvZiB0aGUgSUVURiBT U0lEcyB0aGF0IHdlIHdhbnQgdG8gcnVuIHRoaXMuIFRoaXMgVk0gbmVlZCB0byBpbmNvcnBvcmF0 ZSB0aGUgQ0xBVCBjbGllbnQuIE91ciBuZXR3b3JrIHdpbGwgYmVoYXZlIGFzIGFuIGVudGVycHJp c2UgbmV0d29yayB3aGljaCBhcyBvbmx5IElQdjYgbmF0aXZlIGNvbm5lY3Rpdml0eSB0byBJbnRl cm5ldCwgYW5kIHRoZSBJU1AgKGluIHRoaXMgY2FzZSBvdXIgb3duIG5ldHdvcmspIHdpbGwgcnVu bmluZyB0aGUgUExBVCAoTkFUNjQvRE5TNjQpLgoKSWYgeW91IHN0aWxsIHdhbnQgdG8gdHJ5IHRo ZSBOQVQ2NCBvbmUgbW9yZSwgeW91IGNhbiBoYXZlIHRoZSBOQVQ2NCBTU0lELCB0aGF0IGhhcyBi ZWVuIGFscmVhZHkgdGVzdGVkIGluIGFsbCB0aGUgUklSIG1lZXRpbmdzLCBldGMuIEJ1dCB0aGlz IHdpbGwgbm90IHJ1biBhbnkgYXBwcyB0aGF0IHVzZSBsaXRlcmFscywgb2xkIEFQSXMsIGV0Yy4K CiAgICBNeSBmZWFyIHdpdGggNDY0eGxhdCBpcyB0aGF0IGl0J3MgbGFyZ2VseSB1bnRlc3RlZCBp biBlbnZpcm9ubWVudHMgbGlrZSB0aGUgSUVURi4gSSB3b3VsZCBub3Qgc3VwcG9ydCBtYWtpbmcg aXQgdGhlIGRlZmF1bHQgU1NJRC4gV2UndmUgaGFkIGEgTkFUNjQgU1NJRCBmb3Igc2V2ZXJhbCB5 ZWFyczsgaXQgY291bGQgYmUgcHJvbW90ZWQgdG8gZGVmYXVsdCwgaWYgd2UgY2FuIGRlbW9uc3Ry YXRlIHdpdGggY29uZmlkZW5jZSB0aGF0IGV2ZXJ5b25lIGNhbiBzdGlsbCBnZXQgdGhlaXIgd29y ayBkb25lLgoK4oeSIE5BVDY0IGFzIGRlZmF1bHQgaXMgbm90IGFuZCBvcHRpb24uIEl0IGJyZWFr cyBldmVyeXRoaW5nIHVzaW5nIGxpdGVyYWxzLiBXZSB3YW50IHRvIGhhdmUgYSBnb29kIGV4cGVy aWVuY2UgSSBndWVzcywgYW5kIGJlIGFibGUgdG8gZGV0ZWN0IHdoYXQgd2lsbCBmYWlsIGluIHRo ZSBmdXR1cmUgKGxvZ2dpbmcgQ0xBVCBhbmQgTkFUNjQvRE5TNjQgdXNhZ2UpLCBub3QgYnJlYWsg dGhlIElFVEYgbmV0d29yay4KICAgICAgICAgICAgICAgCiAgICBMZWUKICAgIAogICAgPgogICAg PlNhbHVkb3MsCiAgICA+Sm9yZGkKICAgID4KICAgID4KICAgID4tLS0tLU1lbnNhamUgb3JpZ2lu YWwtLS0tLQogICAgPkRlOiBzdW5zZXQ0IDxzdW5zZXQ0LWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5v bWJyZSBkZSBQaGlsaXAgSG9tYnVyZyA8cGNoLXN1bnNldDQtMUB1LTEucGhpY29oLmNvbT4KICAg ID5SZXNwb25kZXIgYTogPHBjaC1zdW5zZXQ0LTFAdS0xLnBoaWNvaC5jb20+CiAgICA+RmVjaGE6 IHZpZXJuZXMsIDcgZGUgb2N0dWJyZSBkZSAyMDE2LCAxMjowNAogICAgPlBhcmE6IDxzdW5zZXQ0 QGlldGYub3JnPgogICAgPkNDOiAiQmpvZXJuIEEuIFplZWIiIDxiemVlYi1saXN0c0BsaXN0cy56 YWJiYWRvei5uZXQ+CiAgICA+QXN1bnRvOiBSZTogW3N1bnNldDRdIFN1bnNldDQgd29yawogICAg PgogICAgPiAgICBJbiB5b3VyIGxldHRlciBkYXRlZCBUaHUsIDA2IE9jdCAyMDE2IDIzOjI4OjMy ICswMDAwIHlvdSB3cm90ZToKICAgID4gICAgPiBOYXN0eWdyYW0uICBTbyBtYWtlIHRoZSBkZWZh dWx0IElFVEYgU1NJRHMgSVB2Ni1vbmx5IG9yICgrTkFUNjQpCiAgICA+ICAgID4gaWYgeW91IHdh bnQuICBUaGVuIGhhdmUgdGhlIGlldGYtbGVnYWN5IG5ldHdvcmssIHdoaWNoIHdvdWxkIGdpdmUK ICAgID4gICAgPiB5b3UgSVB2NCBhbmQgYSBwb3J0YWwgcGFnZSBwZW5hbHR5IHRoYXQgeW91IGhh dmUgdG8gc3RhdGUgdGhlIG5hdHVyZQogICAgPiAgICA+IHdoeSB5b3UgaGF2ZSB0byB1c2UgdGhp cyBuZXR3b3JrIGFuZCBjYW50IGxpdmUgb24gdGhlIGRlZmF1bHQgb25lLgogICAgPiAgICA+IElk IGJlIHNvIGN1cmlvdXMgdG8gc2VlIHdoYXQgaGFwcGVucyB3aGVuIHBlb3BsZSBmaW5hbGx5IGhh dmUgdG8KICAgID4gICAgPiBzdGFydCB0aGlua2luZyBhYm91dCBpdC4uIGFuZCBvcGVuIGludGVy bmFsIHRpY2tldHMgLi4gIEl0IHdhcwogICAgPiAgICA+IGdyZWF0IGZ1biBkb2luZyBpdCA2LWlz aCB5ZWFycyBhZ28sIC4uCiAgICA+ICAgIAogICAgPiAgICBQZXJzb25hbGx5LCBJIGNvbnNpZGVy IG9mZmVyaW5nIE5BVDY0IG92ZXIgd2lmaSBxdWl0ZSBhYnN1cmQuIFRoZSBvYnZpb3VzCiAgICA+ ICAgIHdheSB0byBwcm92aWRlIGFjY2VzcyB0byBsZWdhY3kgSVB2NCBpcyBzb21lIGZvcm0gb2Yg TkFUNC4gSG93IGl0IGlzIAogICAgPiAgICB0cmFuc3BvcnRlZCBvdmVyIHRoZSByZXN0IG9mIHRo ZSBuZXR3b3JrIGlzIHVwdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IuIEJ1dAogICAgPiAgICB0aGUg b2J2aW91cyBpbnRlcmZhY2UgaXMgUkZDIDg5NC4KICAgID4gICAgCiAgICA+ICAgIFNvIG9uIG5l dHdvcmtzIHRoYXQgcHJvbW90ZSBOQVQ2NCAoRk9TREVNIGhhcyB0aGlzIHNldHVwIGZvciBxdWl0 ZSBhIG51bWJlciBvZgogICAgPiAgICB5ZWFycyBub3cpIEkganVzdCBjb25uZWN0IHRvIHRoZSBs ZWdhY3kgbmV0d29yay4gVGhlaXIgbGVnYWN5IG5ldHdvcmsgaGFzCiAgICA+ICAgIHBlcmZlY3Rs eSBmaW5lIElQdjYsIHNvIEkgY29uc2lkZXIgaXQgd2F5IGJldHRlciB0aGFuIHRoZSBOQVQ2NCB0 aGF0CiAgICA+ICAgICdldmVyeWJvZHknIGxpa2VzIHRvIHB1c2guCiAgICA+ICAgIAogICAgPiAg ICBGb3IgdGhlIHNwZWNpZmljIG1vYmlsZSB3ZWlyZG5lc3MsIE5BVDY0IG1ha2Ugc2Vuc2UuIEJ1 dCBldmVyeXdoZXJlIGVsc2UsCiAgICA+ICAgIHJlcXVpcmluZyBldmVyeSBkZXZpY2UgdG8gaGF2 ZSA0NjR4bGF0IHRvIGRlYWwgd2l0aCBJUHY0IGxpdGVyYWxzIGlzIGp1c3QKICAgID4gICAgYmFk IGVuZ2luZWVyaW5nLiBJZiB5b3VyIGJhY2tib25lIGlzIElQdjYtb25seSwgdGhlbiB0aGUgb2J2 aW91cyBzb2x1dGlvbgogICAgPiAgICBpcyB0byBkZWFsIHdpdGggdGhpcyBpbiBDUEVzLCB3aWZp IGFjY2VzcyBwb2ludHMsIGV0Yy4gTm90IHRvIHJlcXVpcmUgYWxsCiAgICA+ICAgIGhvc3RzIHRv IGtub3cgdGhlIGRldGFpbHMgb2YgeW91ciBuZXR3b3JrLgogICAgPiAgICAKICAgID4gICAgCiAg ICA+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiAg ICA+ICAgIHN1bnNldDQgbWFpbGluZyBsaXN0CiAgICA+ICAgIHN1bnNldDRAaWV0Zi5vcmcKICAg ID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdW5zZXQ0CiAgICA+ ICAgIAogICAgPiAgICAKICAgID4KICAgID4KICAgID4KICAgID4qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCiAgICA+SVB2NCBpcyBvdmVyCiAgICA+QXJlIHlv dSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/CiAgICA+aHR0cDovL3d3dy5jb25zdWxpbnRl bC5lcwogICAgPlRoZSBJUHY2IENvbXBhbnkKICAgID4KICAgID5UaGlzIGVsZWN0cm9uaWMgbWVz c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBpbmNs dWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQuCiAgICA+CiAgICA+CiAgICA+CiAg ICA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KICAgID5z dW5zZXQ0IG1haWxpbmcgbGlzdAogICAgPnN1bnNldDRAaWV0Zi5vcmcKICAgID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1bnNldDQKICAgIAogICAgCiAgICAKCgoKKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpJUHY0IGlzIG92ZXIK QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/Cmh0dHA6Ly93d3cuY29uc3VsaW50 ZWwuZXMKVGhlIElQdjYgQ29tcGFueQoKVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUg aW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVz ZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBwcm9oaWJpdGVkLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpzdW5zZXQ0IG1haWxpbmcgbGlzdApzdW5zZXQ0QGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Vuc2V0NAoKTk9USUNFIEFORCBE SVNDTEFJTUVSClRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBi ZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5k aXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIApJZiB5b3UncmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRp bmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiAKSWYgeW91J3ZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVs eSBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91LgoKV2UgbW9uaXRvciBvdXIg ZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWlscy4KCkVFIExpbWl0ZWQgClJl Z2lzdGVyZWQgb2ZmaWNlOlRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhl cnRmb3Jkc2hpcmUsIEFMMTAgOUJXClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMDIzODIxNjEK CkVFIExpbWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQgc3Vic2lkaWFyeSBvZjoKCkJyaXRpc2ggVGVs ZWNvbW11bmljYXRpb25zIHBsYwpSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQg TG9uZG9uIEVDMUEgN0FKClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMAo= From nobody Mon Oct 17 09:20:17 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4C1298BA for ; Mon, 17 Oct 2016 09:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFUrqbYFJqmN for ; Mon, 17 Oct 2016 09:20:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57B11298CF for ; Mon, 17 Oct 2016 09:19:45 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id 4so55568072itv.0 for ; Mon, 17 Oct 2016 09:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=GBPAk4AsDw0ftqHtENwjHtPwfAYVcZAPkJDjaH7ZTGA=; b=oELhvlVNTqnhfJGGEqEGiLqmg46EHQQcwtf7HkuqmUAk9019H94QzdrMQM3TTbATKd AOizfdYU05ren4ewhWbXMpFchGyuhEshzJprVQewuZFVQzeQmeIO1mYIeMHsBkj1KcCI 7e4tTTPuRZ4K6rRZHWjnF4883dQlAzlAs2RsWmELw5IsOLVgLaFsC7CUjOEUSDWeImWy 7MDkCVsan0BTrToM91sFi/QS7SRpAMiSdA3QVAZdxS3Wjqz7Ime0DsVQC5wDQuKWi0Om HJ5iUHfKsD8GXQbBUI2L4N9q3iTu8qMvX7wECV9OASWcVdEb/7S5PWujKTzPZJ3Hg7Qy 9fcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=GBPAk4AsDw0ftqHtENwjHtPwfAYVcZAPkJDjaH7ZTGA=; b=kxIOsHBP+ph0IKfCBQGhJkselT7KFUjH/BEzegukD3cJYEVmquoyJkhkQ0jmfntf6F OmP07YH5SRX3DKUIIiDur22+7ancgqoK8vCNcMGJWlPYkDA+elZ7QXam0HqWGNhFz187 l8fliCOPbtbO/m8009+TFIX6Wchdbw5iq8BB8l65pSkh3F6Gy0cpFcrAyLLgyuuGeuxX PzWY4dlGOLwiHRGF/7j0rZ8cwhxxAqbolwIRKENZG21udX6cnNjdelAaEY4IlCstQ/bW 0sEituMwvX4ntWk7iuPPpBHEAVcrNIrmwUV/6O1Oi0/JrDM/dV1zYpnUoxtnchFfB2Go mdmA== X-Gm-Message-State: AA6/9RkVoK7qs4eXZTpLz7b2oN1e8zCZJ3V7hPrGDoiy5kBI+HbGzbWzzsE6rNvf7+aw2ebjOpedKQrbXaETpw== X-Received: by 10.36.206.69 with SMTP id v66mr8296559itg.112.1476721184858; Mon, 17 Oct 2016 09:19:44 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.169.12 with HTTP; Mon, 17 Oct 2016 09:19:44 -0700 (PDT) From: Erik Nygren Date: Mon, 17 Oct 2016 12:19:44 -0400 X-Google-Sender-Auth: VpPkpmBB9ohIRcvbG-LUaQtz0z8 Message-ID: To: sunset4@ietf.org, Mike West Content-Type: multipart/alternative; boundary=94eb2c0b0c62a7f1be053f11f1c9 Archived-At: Subject: [sunset4] let 'localhost' be localhost X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:20:15 -0000 --94eb2c0b0c62a7f1be053f11f1c9 Content-Type: text/plain; charset=UTF-8 In the hopes of allowing devices to some day drop their IPv4 stacks, one thing we will need to keep an eye out for is any behavior that encourages hard-coding 127.0.0.1 or ::1 rather than using a "localhost" abstraction. In the W3C WebAppSec Secure Context discussion, there has been concern that "localhost" shouldn't be a "secure context" (unlike 127.0.0.1 and ::1) due to resolvers not always returning localhost. I worry that this could result in increased use of "127.0.0.1" (such as by web pages containing URLs instructing clients to talk to a localhost resource service). Mike West has written up a "let localhost be localhost" draft to cover this: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02 I'm sure feedback is quite welcome (and I wonder if sunset4 might be one reasonable place to pick up this work?). Some background: https://github.com/w3c/webappsec-secure-contexts/issues/43 - Erik --94eb2c0b0c62a7f1be053f11f1c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the hopes of allowing devices to some day drop the= ir IPv4 stacks, one thing we will need to keep an eye out for is any behavi= or that encourages hard-coding 127.0.0.1 or ::1 rather than using a "l= ocalhost" abstraction.=C2=A0 In the W3C WebAppSec Secure Context discu= ssion, there has been concern that "localhost" shouldn't be a= "secure context" (unlike 127.0.0.1 and ::1) due to resolvers not= always returning localhost.=C2=A0 I worry that this could result in increa= sed use of "127.0.0.1" (such as by web pages containing URLs inst= ructing clients to talk to a localhost resource service).

Mike= West has written up a "let localhost be localhost" draft to cove= r this:
I'm sure feedback is quite welcome (and I wonder if sunset4 might be = one reasonable place to pick up this work?).

Some backgro= und:=C2=A0=C2=A0=C2=A0=C2=A0 https://github.com/w3c/webappsec-secure-contexts/i= ssues/43

- Erik


--94eb2c0b0c62a7f1be053f11f1c9-- From nobody Mon Oct 17 09:32:29 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCA12995E for ; Mon, 17 Oct 2016 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 tBORhTfXGQ2H for ; Mon, 17 Oct 2016 09:32:24 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C42C129929 for ; Mon, 17 Oct 2016 09:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1476721939; x=1477326739; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=YCPPJuIzpAYhqL72tiidoeZRi 3yAKc8g47SsWxbHXY4=; b=l9hBn/6aeI7g/q3JrKvtuSNvy1XQ9DxngJ9Qa+B56 qcpDEAoRje8Qwrn688PaT28HEd8gRzHHT8tAj/pPi4lFdRXJecGPGPSfRsJ/L9Yf bguecs7++QVaKkbjy4CMnYnq8tqEMXSCbUaq1fLi29+b2PMaFxqAsP287p+gnkd6 Ps= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Dcp6X6PLv53gc0oeG5B+wdDMBCDqfXrRpQlXE4a4REAzyXJ3mXNliWc78zsP zBvS+kXoK+41Tp69Pg5+w1hBQsxrm3PMQ7zci+SnEi3tTdGqOx/dlcLnU AgXJ9E1uia23h2KajPHIgkaxzqpSrEWU6j2+gkAcxGwcAJIiqe/Iz4=; X-MDAV-Processed: mail.consulintel.es, Mon, 17 Oct 2016 18:32:19 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 17 Oct 2016 18:32:08 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005179763.msg for ; Mon, 17 Oct 2016 18:32:07 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161017:md50005179763::L2oeFQzH8rZmLesi:00005py9 X-Return-Path: prvs=10985a49bb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 17 Oct 2016 18:32:03 +0200 From: JORDI PALET MARTINEZ To: , "sunset4@ietf.org" Message-ID: Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:32:27 -0000 Nice summary ;-) Let=E2=80=99s put in this way regarding the IETF SSID and =E2=80=9Cdogfoodi= ng=E2=80=9D: B allows us to *detect* what will fail when we go to A, but not creating th= e users a lot of problems and waste of time, complains to the NOG, etc. Then, once we have warned those services and apps that fail, exposing publi= cly the results of what is subjected to failure if we go to A, keep using B= in our network at each following IETF, see the evolution of those =E2=80= =9Cdetected failures=E2=80=9D and may be in one year from one decide if we = want to move to A. Saludos, Jordi -----Mensaje original----- De: sunset4 en nombre de "Heatley, Nick" Responder a: Fecha: lunes, 17 de octubre de 2016, 18:04 Para: "jordi.palet@consulintel.es" , "sunset4@i= etf.org" Asunto: Re: [sunset4] Sunset4 work A thought provoking discussion. I don't think the specific transition technology matters so much as the= "family" it falls into.=20 What matters is whether IETF wishes to showcase IPv6-only down to the c= ustomer client devices (and then to harvest the expected client issues, IPs= ec failing?), or whether it wishes to showcase "local dualstack on the smal= l-stub-network, with an IPv6-only provider connection" to show how small-st= ub-networks could be connected in the future. =20 Let me explain (longer answer). In a number of years' time, as providers run out of IPv4 publics, edge = "networks" will be brought on with only global IPv6 addressing available as= the persistent identifier for connected endpoints. (I am assuming in Sunse= t4 we can agree on that). But what addressing is within the edge network? 1. For large edge networks where private addressing numbers are not suf= ficient to meet the number of connected devices, they will need to go IPv6-= only, as we have seen with large mobile operators, and learnt with Microsof= t Enterprise, Facebook etc. These networks all say private IPv4 addressing = is not sufficient. 2. For smaller enterprise edge networks then they may well be sitting a= nd waiting, or following the above, time will tell. 3. For "small-stub-networks" (SSN), where the number of connected devic= es is manageable then clearly IPv4 private addressing is sufficient. Publi= c Wifi access being a perfect example of SSN, or any model using a consumer= CPE I suppose. So this is the question for sunset4: (A) Do we wish to advocate IPv6-only in this SSN scenario? in which cas= e all current and future client issues must be resolved (IPv4 literals) suc= h that the clients work in the absence of an IPv4 address? This case is typ= ified by NAT64/DNS64, other transition mechanisms are available. (B) Do we wish to advocate dualstack networking to the client in this S= SN scenario? Avoid client issues by providing them with a GUA and a IPv4 pr= ivate? In which case the transition technology (held within the CPE) needs = to enable dualstack on the access side but on the provider side, cope with = only an IPv6-only provider connection. 464xlat in the CPE (like 464xlat bas= ed tethering from a cellular handset) is an example of a transition technol= ogy in this family, others are available. =20 Both of these SSN approaches assume that within the core of the interne= t their remains the legacy IPv4-only content, which seems valid for "consum= er electronics networking" in general. They differ on how we expect consumer electronics networking to evolve = (or how we *want* it to evolve). We could advocate both for sure, but not s= ure if that helps move sunset4 forward! =20 My opinion, take it or leave it, is that pragmatically, a SSN vision ba= sed on (B) is less problematic. It is less dependent on moving a whole coll= ection of Consumer Electronics away from today's deficient state, because (= A) essential demands they work in absence of IPv4. This requires concerted = effort to remove the "IPv6-only" mode bugs that we know exist. The biggest problem with (A) is that you cannot make the network model = the compulsory model, until the majority of Consumer Electronics is fully r= eady, which creates another network provider chicken-egg problem. You can d= o OS by OS (something that a popular smartphone and PC vendor is attempting= with IPv6-only, NAT64) but network providers don't wish to create individu= al network paradigms for each OS. =20 Then we look back at 2., above. Enterprises moving to IPv6-only - do we= have some need and obligation within Sunset4 to push (A) to avoid Enterpri= ses being trapped in an IPv4 world? To leave dualstack in one part of the e= dge (SSN) - does it undermine the benefits we are telling enterprises on IP= v6-only e.g. removal of dual address complexity. Personally I believe this = is only really an issue in practice where the enterprise is so large that t= he 20M private addresses are not sufficient for their organisation - and I = think such enterprises are big enough to progress this issue themselves if = they wish IPv6-only to work for them. But if (A) is consensus then Sunset4 = should start to define the client requirements for absence of IPv4 in a SSN= . And unlike provider networks, enterprise networks own and manage the end = to end network use case themselves. =20 The other concern for me about (A) is that I have already oversimplifie= d devices as "consumer electronics" as though they only fall into the hands= of consumers in consumer usecases. One of the big issues I foresee with the IPv6-only approach of certain = OS vendor(s) is that something like a smartphone can be an end device with = its network interface servicing "on board Apps" (typical mobile connectivit= y), but it can also be a network gateway when used for tethering or "intern= et sharing". The end device (the device tethered on the end of the wifi lin= k) may actually be in an enterprise use case ("VPN into an office network" = for example). By making the SSN IPv6-only we may risk placing requirements = on the enterprise network (i.e. outside-in connectivity like the VPN concen= trator, may need certain functionality to terminate an IPv6 IPsec VPN etc.)= . We may need the requirements for (A) not just be about end devices but al= so coordinating requirements for various gateways in enterprise networks? I= f you believe that, it is another serious chicken-egg problem; do we need e= nterprise networks upgraded before we can move to a solution for SSNs? (See= the IPsec comments in https://tools.ietf.org/html/rfc7269#section-6.1 but = in the general case IPsec VPN is a fail, right?) I am very much in favour of the family of transition technologies that= enable (B). =20 SO I inferred a definition of the term SSN to suit my needs in this mai= l. What is really boils down to is that edge networks need some sort of CPE= or Gateway to the provider network. Do we want that CPE to provide dualsta= ck locally or IPv6-only when the provider addresses run out. Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd pr= efer a choice for long term rather than "for next meeting" and I'd go for s= omething like Jordi's 464xlat in the CPE! Choose wisely :-) If an IPv6-only SSID is just to showcase IPsec VPNs still failing, it i= s a bit of a waste of people's time). Regards, Nick =20 =20 =20 =20 =20 -----Original Message----- From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of JORDI PALE= T MARTINEZ Sent: 07 October 2016 21:02 To:=20 Subject: Re: [sunset4] Sunset4 work =20 On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" wrote: =20 >This is what I=E2=80=99m proposing. May be I miss explained it. > >NOT asking EVERY device in our network to HAVE 464XLAT client (CLA= T), but having ONLY our =E2=80=9CCPE=E2=80=9D to have it. > >Nodes will not notice anything. > >This is what is going to happen in the future in most of the netwo= rks because they will not have IPv4 for every customer, so why not trying i= t ourselves? Already happening in many cellular networks, like in US, which= are close to have 60% IPv6 traffic already. =20 You think 464xlat is what's going to happen in the future in most n= etworks? Mobile networks, yes, it's a primary transition mechanisms. Wi-fi networks operated by ISPs or enterprises are more likely to u= se NAT64, DS-Lite, or MAP, based on what I'm seeing people working on. =20 I disagree in several points: 1) 464XLAT is not only for cellular networks, just read the draft. 2) It has been implemented by some CPE vendors. It can be run in Virtua= l Machines as well. a. http://www.necat.co.jp/en/ipv6/index.html b. https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_= apnic_464xlat.pdf 3) I=E2=80=99ve tested it in several ISP network. Trials at the time be= ing, but coming into production. 4) NAT64 is WORST than 464XLAT. NAT64 doesn=E2=80=99t sort out the prob= lems for apps using literals. 464XLAT sort it out. Yes, NAT64 was developed= first, but that=E2=80=99s the reason 464XLAT was needed, because not every= thing was working in NAT64. 5) If you don=E2=80=99t trust 464XLAT, then you can=E2=80=99t trust in = NAT64, because is just an =E2=80=9Cincomplete=E2=80=9D version of 464XLAT. =20 I agree with you that DS-Lite and MAP are other choices, comparable wit= h 464XLAT. They will be a better test, for sure than just NAT64. =20 If you want something more lightweight than DS-Lite, probably will be b= etter to use lw4o6.=20 =20 Just to make sure it has been understood: I=E2=80=99m not asking to imp= lement anything in the clients of our network. Nobody needs to install anyt= hing. We just need to have a VM or a set of them if we don=E2=80=99t trust = on the hardware performance, as the =E2=80=9CCPE router=E2=80=9D of the IET= F SSIDs that we want to run this. This VM need to incorporate the CLAT clie= nt. Our network will behave as an enterprise network which as only IPv6 nat= ive connectivity to Internet, and the ISP (in this case our own network) wi= ll running the PLAT (NAT64/DNS64). =20 If you still want to try the NAT64 one more, you can have the NAT64 SSI= D, that has been already tested in all the RIR meetings, etc. But this will= not run any apps that use literals, old APIs, etc. =20 My fear with 464xlat is that it's largely untested in environments = like the IETF. I would not support making it the default SSID. We've had a = NAT64 SSID for several years; it could be promoted to default, if we can de= monstrate with confidence that everyone can still get their work done. =20 =E2=87=92 NAT64 as default is not and option. It breaks everything usin= g literals. We want to have a good experience I guess, and be able to detec= t what will fail in the future (logging CLAT and NAT64/DNS64 usage), not br= eak the IETF network. =20 Lee =20 > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 en nombre de Philip Homburg= >Responder a: >Fecha: viernes, 7 de octubre de 2016, 12:04 >Para: >CC: "Bjoern A. Zeeb" >Asunto: Re: [sunset4] Sunset4 work > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote= : > > Nastygram. So make the default IETF SSIDs IPv6-only or (+NA= T64) > > if you want. Then have the ietf-legacy network, which would= give > > you IPv4 and a portal page penalty that you have to state th= e nature > > why you have to use this network and cant live on the defaul= t one. > > Id be so curious to see what happens when people finally hav= e to > > start thinking about it.. and open internal tickets .. It w= as > > great fun doing it 6-ish years ago, .. > =20 > Personally, I consider offering NAT64 over wifi quite absurd. = The obvious > way to provide access to legacy IPv4 is some form of NAT4. How= it is=20 > transported over the rest of the network is upto the network o= perator. But > the obvious interface is RFC 894. > =20 > So on networks that promote NAT64 (FOSDEM has this setup for q= uite a number of > years now) I just connect to the legacy network. Their legacy = network has > perfectly fine IPv6, so I consider it way better than the NAT6= 4 that > 'everybody' likes to push. > =20 > For the specific mobile weirdness, NAT64 make sense. But every= where else, > requiring every device to have 464xlat to deal with IPv4 liter= als is just > bad engineering. If your backbone is IPv6-only, then the obvio= us solution > is to deal with this in CPEs, wifi access points, etc. Not to = require all > hosts to know the details of your network. > =20 > =20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > =20 > =20 > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileg= ed or confidential. The information is intended to be for the use of the in= dividual(s) named above. If you are not the intended recipient be aware tha= t any disclosure, copying, distribution or use of the contents of this info= rmation, including attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, di= stributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately = on the email address above. Thank you. =20 We monitor our email system, and may record your emails. =20 EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire,= AL10 9BW Registered in England no: 02382161 =20 EE Limited is a wholly owned subsidiary of: =20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Oct 17 10:51:15 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6897F129449 for ; Mon, 17 Oct 2016 10:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGVR_7IZtNRm for ; Mon, 17 Oct 2016 10:51:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE74A128E18 for ; Mon, 17 Oct 2016 10:51:11 -0700 (PDT) Received: from [10.0.1.45] (h126.viagenie.ca [206.123.31.126]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 162B14768F; Mon, 17 Oct 2016 13:51:11 -0400 (EDT) From: "Marc Blanchet" To: "Erik Nygren" Date: Mon, 17 Oct 2016 13:51:10 -0400 Message-ID: <9D1C5C76-417A-4AF4-9FB0-8354FA8B5A60@viagenie.ca> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: Mike West , sunset4@ietf.org Subject: Re: [sunset4] let 'localhost' be localhost X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 17:51:13 -0000 On 17 Oct 2016, at 12:19, Erik Nygren wrote: > In the hopes of allowing devices to some day drop their IPv4 stacks, > one > thing we will need to keep an eye out for is any behavior that > encourages > hard-coding 127.0.0.1 or ::1 rather than using a "localhost" > abstraction. > In the W3C WebAppSec Secure Context discussion, there has been concern > that > "localhost" shouldn't be a "secure context" (unlike 127.0.0.1 and ::1) > due > to resolvers not always returning localhost. I worry that this could > result in increased use of "127.0.0.1" (such as by web pages > containing > URLs instructing clients to talk to a localhost resource service). > > Mike West has written up a "let localhost be localhost" draft to cover > this: > > https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02 > > I'm sure feedback is quite welcome (and I wonder if sunset4 might be > one > reasonable place to pick up this work?). interesting issue. It certainly relates to name resolution not behaving the way it should. But yes, sunset4 make sense to pick up this work. would one of you two be in Seoul? If yes, we could carve up 5-10 minutes in the agenda for that topic. Marc. > > Some background: > https://github.com/w3c/webappsec-secure-contexts/issues/43 > > - Erik > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From nobody Mon Oct 17 12:50:32 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4321E1295C6 for ; Mon, 17 Oct 2016 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM0V7N693X3o for ; Mon, 17 Oct 2016 12:50:24 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 1DF23129472 for ; Mon, 17 Oct 2016 12:50:24 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E679B3493CD; Mon, 17 Oct 2016 19:50:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9D30E160046; Mon, 17 Oct 2016 19:50:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 86812160076; Mon, 17 Oct 2016 19:50:18 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 62I1EASoFMLP; Mon, 17 Oct 2016 19:50:18 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CDFEA160046; Mon, 17 Oct 2016 19:50:17 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 50EEC56DFD2A; Tue, 18 Oct 2016 06:50:15 +1100 (EST) To: "Heatley, Nick" From: Mark Andrews References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> In-reply-to: Your message of "Mon, 17 Oct 2016 16:04:11 -0000." <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Tue, 18 Oct 2016 06:50:15 +1100 Message-Id: <20161017195015.50EEC56DFD2A@rock.dv.isc.org> Archived-At: Cc: "sunset4@ietf.org" , "jordi.palet@consulintel.es" Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 19:50:31 -0000 In message <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK>, "Heatley, Nick" writes: > A thought provoking discussion. > I don't think the specific transition technology matters so much as the > "family" it falls into. Actually the specific transition technology does matter. It impacts on what works and what doesn't in the IPv6 connected dual stack island. Can the client get a "listening" port to accept externally originating traffic? Games need to be able to get listening ports. Does the transition technology break DNSSEC? Do the nodes support it especially when the local net is ipv6-only. Just because the phones went 464xlat doesn't mean that it is the right fit for the home or office. Mark > What matters is whether IETF wishes to showcase IPv6-only down to the > customer client devices (and then to harvest the expected client issues, > IPsec failing?), or whether it wishes to showcase "local dualstack on the > small-stub-network, with an IPv6-only provider connection" to show how > small-stub-networks could be connected in the future. > > Let me explain (longer answer). > In a number of years' time, as providers run out of IPv4 publics, edge > "networks" will be brought on with only global IPv6 addressing available > as the persistent identifier for connected endpoints. (I am assuming in > Sunset4 we can agree on that). > But what addressing is within the edge network? > 1. For large edge networks where private addressing numbers are not > sufficient to meet the number of connected devices, they will need to go > IPv6-only, as we have seen with large mobile operators, and learnt with > Microsoft Enterprise, Facebook etc. These networks all say private IPv4 > addressing is not sufficient. > 2. For smaller enterprise edge networks then they may well be sitting and > waiting, or following the above, time will tell. > 3. For "small-stub-networks" (SSN), where the number of connected devices > is manageable then clearly IPv4 private addressing is sufficient. Public > Wifi access being a perfect example of SSN, or any model using a consumer > CPE I suppose. So this is the question for sunset4: > (A) Do we wish to advocate IPv6-only in this SSN scenario? in which case > all current and future client issues must be resolved (IPv4 literals) > such that the clients work in the absence of an IPv4 address? This case > is typified by NAT64/DNS64, other transition mechanisms are available. > (B) Do we wish to advocate dualstack networking to the client in this SSN > scenario? Avoid client issues by providing them with a GUA and a IPv4 > private? In which case the transition technology (held within the CPE) > needs to enable dualstack on the access side but on the provider side, > cope with only an IPv6-only provider connection. 464xlat in the CPE (like > 464xlat based tethering from a cellular handset) is an example of a > transition technology in this family, others are available. > > Both of these SSN approaches assume that within the core of the internet > their remains the legacy IPv4-only content, which seems valid for > "consumer electronics networking" in general. > They differ on how we expect consumer electronics networking to evolve > (or how we *want* it to evolve). We could advocate both for sure, but not > sure if that helps move sunset4 forward! > > My opinion, take it or leave it, is that pragmatically, a SSN vision > based on (B) is less problematic. It is less dependent on moving a whole > collection of Consumer Electronics away from today's deficient state, > because (A) essential demands they work in absence of IPv4. This requires > concerted effort to remove the "IPv6-only" mode bugs that we know exist. > The biggest problem with (A) is that you cannot make the network model > the compulsory model, until the majority of Consumer Electronics is fully > ready, which creates another network provider chicken-egg problem. You > can do OS by OS (something that a popular smartphone and PC vendor is > attempting with IPv6-only, NAT64) but network providers don't wish to > create individual network paradigms for each OS. > > Then we look back at 2., above. Enterprises moving to IPv6-only - do we > have some need and obligation within Sunset4 to push (A) to avoid > Enterprises being trapped in an IPv4 world? To leave dualstack in one > part of the edge (SSN) - does it undermine the benefits we are telling > enterprises on IPv6-only e.g. removal of dual address complexity. > Personally I believe this is only really an issue in practice where the > enterprise is so large that the 20M private addresses are not sufficient > for their organisation - and I think such enterprises are big enough to > progress this issue themselves if they wish IPv6-only to work for them. > But if (A) is consensus then Sunset4 should start to define the client > requirements for absence of IPv4 in a SSN. And unlike provider networks, > enterprise networks own and manage the end to end network use case > themselves. > > The other concern for me about (A) is that I have already oversimplified > devices as "consumer electronics" as though they only fall into the hands > of consumers in consumer usecases. > One of the big issues I foresee with the IPv6-only approach of certain OS > vendor(s) is that something like a smartphone can be an end device with > its network interface servicing "on board Apps" (typical mobile > connectivity), but it can also be a network gateway when used for > tethering or "internet sharing". The end device (the device tethered on > the end of the wifi link) may actually be in an enterprise use case ("VPN > into an office network" for example). By making the SSN IPv6-only we may > risk placing requirements on the enterprise network (i.e. outside-in > connectivity like the VPN concentrator, may need certain functionality to > terminate an IPv6 IPsec VPN etc.). We may need the requirements for (A) > not just be about end devices but also coordinating requirements for > various gateways in enterprise networks? If you believe that, it is > another serious chicken-egg problem; do we need enterprise networks > upgraded before we can move to a solution for SSNs? (See the IPsec > comments in https://tools.ietf.org/html/rfc7269#section-6.1 but in the > general case IPsec VPN is a fail, right?) > I am very much in favour of the family of transition technologies that > enable (B). > > SO I inferred a definition of the term SSN to suit my needs in this mail. > What is really boils down to is that edge networks need some sort of CPE > or Gateway to the provider network. Do we want that CPE to provide > dualstack locally or IPv6-only when the provider addresses run out. > Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd > prefer a choice for long term rather than "for next meeting" and I'd go > for something like Jordi's 464xlat in the CPE! Choose wisely :-) > If an IPv6-only SSID is just to showcase IPsec VPNs still failing, it is > a bit of a waste of people's time). > Regards, > Nick > > > > > > -----Original Message----- > From: sunset4 mailto:sunset4-bounces@ietf.org On Behalf Of JORDI PALET > MARTINEZ > Sent: 07 October 2016 21:02 > To: > Subject: Re: sunset4 Sunset4 work > > On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" > wrote: > > >This is what Im proposing. May be I miss explained it. > > > >NOT asking EVERY device in our network to HAVE 464XLAT client > (CLAT), but having ONLY our CPE to have it. > > > >Nodes will not notice anything. > > > >This is what is going to happen in the future in most of the > networks because they will not have IPv4 for every customer, so why not > trying it ourselves? Already happening in many cellular networks, like in > US, which are close to have 60% IPv6 traffic already. > > You think 464xlat is what's going to happen in the future in most > networks? > Mobile networks, yes, it's a primary transition mechanisms. > Wi-fi networks operated by ISPs or enterprises are more likely to use > NAT64, DS-Lite, or MAP, based on what I'm seeing people working on. > > I disagree in several points: > 1) 464XLAT is not only for cellular networks, just read the draft. > 2) It has been implemented by some CPE vendors. It can be run in Virtual > Machines as well. > a. http://www.necat.co.jp/en/ipv6/index.html > b. > https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_apnic_ > 464xlat.pdf > 3) Ive tested it in several ISP network. Trials at the time being, but > coming into production. > 4) NAT64 is WORST than 464XLAT. NAT64 doesnt sort out the problems for > apps using literals. 464XLAT sort it out. Yes, NAT64 was developed first, > but thats the reason 464XLAT was needed, because not everything was > working in NAT64. > 5) If you dont trust 464XLAT, then you cant trust in NAT64, because is > just an incomplete version of 464XLAT. > > I agree with you that DS-Lite and MAP are other choices, comparable with > 464XLAT. They will be a better test, for sure than just NAT64. > > If you want something more lightweight than DS-Lite, probably will be > better to use lw4o6. > > Just to make sure it has been understood: Im not asking to implement > anything in the clients of our network. Nobody needs to install anything. > We just need to have a VM or a set of them if we dont trust on the > hardware performance, as the CPE router of the IETF SSIDs that we want to > run this. This VM need to incorporate the CLAT client. Our network will > behave as an enterprise network which as only IPv6 native connectivity to > Internet, and the ISP (in this case our own network) will running the > PLAT (NAT64/DNS64). > > If you still want to try the NAT64 one more, you can have the NAT64 SSID, > that has been already tested in all the RIR meetings, etc. But this will > not run any apps that use literals, old APIs, etc. > > My fear with 464xlat is that it's largely untested in environments > like the IETF. I would not support making it the default SSID. We've had > a NAT64 SSID for several years; it could be promoted to default, if we > can demonstrate with confidence that everyone can still get their work > done. > > NAT64 as default is not and option. It breaks everything using literals. > We want to have a good experience I guess, and be able to detect what > will fail in the future (logging CLAT and NAT64/DNS64 usage), not break > the IETF network. > > Lee > > > > >Saludos, > >Jordi > > > > > >-----Mensaje original----- > >De: sunset4 en nombre de Philip Homburg > > >Responder a: > >Fecha: viernes, 7 de octubre de 2016, 12:04 > >Para: > >CC: "Bjoern A. Zeeb" > >Asunto: Re: sunset4 Sunset4 work > > > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > > > Nastygram. So make the default IETF SSIDs IPv6-only or > (+NAT64) > > > if you want. Then have the ietf-legacy network, which would > give > > > you IPv4 and a portal page penalty that you have to state the > nature > > > why you have to use this network and cant live on the default > one. > > > Id be so curious to see what happens when people finally have > to > > > start thinking about it.. and open internal tickets .. It was > > > great fun doing it 6-ish years ago, .. > > > > Personally, I consider offering NAT64 over wifi quite absurd. > The obvious > > way to provide access to legacy IPv4 is some form of NAT4. How > it is > > transported over the rest of the network is upto the network > operator. But > > the obvious interface is RFC 894. > > > > So on networks that promote NAT64 (FOSDEM has this setup for > quite a number of > > years now) I just connect to the legacy network. Their legacy > network has > > perfectly fine IPv6, so I consider it way better than the NAT64 > that > > 'everybody' likes to push. > > > > For the specific mobile weirdness, NAT64 make sense. But > everywhere else, > > requiring every device to have 464xlat to deal with IPv4 > literals is just > > bad engineering. If your backbone is IPv6-only, then the obvious > solution > > is to deal with this in CPEs, wifi access points, etc. Not to > require all > > hosts to know the details of your network. > > > > > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > > > > > >********************************************** > >IPv4 is over > >Are you ready for the new Internet ? > >http://www.consulintel.es > >The IPv6 Company > > > >This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > >_______________________________________________ > >sunset4 mailing list > >sunset4@ietf.org > >https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named > above. > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. > If you've received this email in error, please let me know immediately on > the email address above. Thank you. > > We monitor our email system, and may record your emails. > > EE Limited > Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, > AL10 9BW > Registered in England no: 02382161 > > EE Limited is a wholly owned subsidiary of: > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Oct 17 16:54:02 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643DB1299AF for ; Mon, 17 Oct 2016 16:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppKjIYfXmFW5 for ; Mon, 17 Oct 2016 16:53:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9BF08129495 for ; Mon, 17 Oct 2016 16:53:58 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2B404349528; Mon, 17 Oct 2016 23:53:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EBB3C160046; Mon, 17 Oct 2016 23:53:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CCE89160076; Mon, 17 Oct 2016 23:53:55 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JkvylwC8YsOw; Mon, 17 Oct 2016 23:53:55 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6EA2F160046; Mon, 17 Oct 2016 23:53:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 49B3B56E6613; Tue, 18 Oct 2016 10:53:53 +1100 (EST) To: "Marc Blanchet" From: Mark Andrews References: <9D1C5C76-417A-4AF4-9FB0-8354FA8B5A60@viagenie.ca> In-reply-to: Your message of "Mon, 17 Oct 2016 13:51:10 -0400." <9D1C5C76-417A-4AF4-9FB0-8354FA8B5A60@viagenie.ca> Date: Tue, 18 Oct 2016 10:53:53 +1100 Message-Id: <20161017235353.49B3B56E6613@rock.dv.isc.org> Archived-At: Cc: Erik Nygren , Mike West , sunset4@ietf.org Subject: Re: [sunset4] let 'localhost' be localhost X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:54:00 -0000 I would argue that sunset4 doesn't have the depth of expertise to do this properly. That the issues are much more nuanced than the draft makes out. I would argue that there needs to be the equivalent of a local DNS server for the zone localhost. More than A and AAAA records need to be able to be returned. I would argue that the root zone needs a insecure delegation for localhost. I would argue that the input string "localhost" needs to be treated as absolute. i.e. search lists don't apply. Mark In message <9D1C5C76-417A-4AF4-9FB0-8354FA8B5A60@viagenie.ca>, "Marc Blanchet" writes: > On 17 Oct 2016, at 12:19, Erik Nygren wrote: > > > In the hopes of allowing devices to some day drop their IPv4 stacks, > > one > > thing we will need to keep an eye out for is any behavior that > > encourages > > hard-coding 127.0.0.1 or ::1 rather than using a "localhost" > > abstraction. > > In the W3C WebAppSec Secure Context discussion, there has been concern > > that > > "localhost" shouldn't be a "secure context" (unlike 127.0.0.1 and ::1) > > due > > to resolvers not always returning localhost. I worry that this could > > result in increased use of "127.0.0.1" (such as by web pages > > containing > > URLs instructing clients to talk to a localhost resource service). > > > > Mike West has written up a "let localhost be localhost" draft to cover > > this: > > > > https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02 > > > > I'm sure feedback is quite welcome (and I wonder if sunset4 might be > > one > > reasonable place to pick up this work?). > > interesting issue. It certainly relates to name resolution not behaving > the way it should. > > But yes, sunset4 make sense to pick up this work. > > would one of you two be in Seoul? If yes, we could carve up 5-10 minutes > in the agenda for that topic. > > Marc. > > > > > Some background: > > https://github.com/w3c/webappsec-secure-contexts/issues/43 > > > > - Erik > > > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Oct 18 01:48:13 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EF129997 for ; Tue, 18 Oct 2016 01:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpcf92XHqYyh for ; Tue, 18 Oct 2016 01:48:08 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (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 C8DFF1295AE for ; Tue, 18 Oct 2016 01:48:07 -0700 (PDT) Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id E4/F9-15788-5C1E5085; Tue, 18 Oct 2016 08:48:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRWlGSWpSXmKPExsUy9d9HH91DD1k jDC72ilj8Pf6Z2eLKi/ssFiv37Gd3YPZYtz/AY8mSn0weDx6/Yw5gjmLNzEvKr0hgzXi0+wVr wfZWxoqe3RfYGhiPZncxcnEICWxhlHh+ZxcLhHOAUeL+/r2MEM4JRokvG18BZTg52AR0Jdpnr WIGsUUEFCTa3r5iArGZBVIlNq6bAmYLCyhLfH7QyAhRoyIxY+J1Vgg7T+Lpyl9gcRYBVYmbvX vA5vAKhEos7ZvADrFsJYvE4d3tbCAJTgEricUNz8CaGQVkJb40rmaGWCYucevJfLBlEgICEkv 2nGeGsEUlXj7+xwphK0hcWtTFClGvI7Fg9yc2CFtbYtnC11CLBSVOznzCMoFRdBaSsbOQtMxC 0jILScsCRpZVjBrFqUVlqUW6hgZ6SUWZ6RkluYmZOUCesV5uanFxYnpqTmJSsV5yfu4mRmB01 TMwMO5g3NblfIhRkoNJSZR31g3WCCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvGsfAOUEi1LTUy vSMnOAcQ6TluDgURLhtQRJ8xYXJOYWZ6ZDpE4x6nL86Li/lkmIJS8/L1VKnLcVpEgApCijNA9 uBCzlXGKUlRLmZWRgYBDiKUgtys0sQZV/xSjOwagkzHsSZApPZl4J3KZXQEcwAR1xLo8F5IiS RISUVAOj2ixG38fXT6RKuVkUKpXOWWeyw0e5bfsxK5vPZ9y0Dz+Ir3v3SuupuEkYo+GSjQeKJ llqFjTu2/dQf5vPIrXXLRPu6iXLxmTu/nvit6lFPsMT7em+e3fwNEgrOXgF7Jtdcf3HhFke6a pbH0XN+VfC22FxqmM3q2tJ0Tl39ty1l6N1ltUan9qqxFKckWioxVxUnAgAVJrHGzQDAAA= X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-31.messagelabs.com!1476780481!66736700!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 63285 invoked from network); 18 Oct 2016 08:48:02 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 18 Oct 2016 08:48:02 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Tue, 18 Oct 2016 09:47:59 +0100 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Tue, 18 Oct 2016 09:48:01 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0279.002; Tue, 18 Oct 2016 09:48:01 +0100 From: "Heatley, Nick" To: Mark Andrews Thread-Topic: [sunset4] Sunset4 work Thread-Index: AQHSIAgRtByCj90yWkOply3Hcs4up6CbzdGAgAAPNACAACTaAIAAwoBd///1lYCAAInCAIAAFsUAgApY3sCABWwCYYAA11PA Date: Tue, 18 Oct 2016 08:48:01 +0000 Message-ID: <6536E263028723489CCD5B6821D4B2132C3C15BA@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> <20161017195015.50EEC56DFD2A@rock.dv.isc.org> In-Reply-To: <20161017195015.50EEC56DFD2A@rock.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sunset4@ietf.org" , "jordi.palet@consulintel.es" Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 08:48:12 -0000 Hi Mark, In my mail, you misunderstood if you thought I was simply sugges= ting xlat. Rather I was contrasting two "families" of tech that either pr= ovide IPv6-only or some type of dualstack, as some first decision point. Nevertheless you are right, in any solution the technology does matter. Your comments suggest that you have concerns that something more than IPv= 6-only + NAT64 is required? Nick -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: 17 October 2016 20:50 To: Heatley, Nick Cc: jordi.palet@consulintel.es; sunset4@ietf.org Subject: Re: [sunset4] Sunset4 work In message <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.E= EINT.CO.UK>, "Heatley, Nick" writes: > A thought provoking discussion. > I don't think the specific transition technology matters so much as=20 > the "family" it falls into. Actually the specific transition technology does matter. It impacts on w= hat works and what doesn't in the IPv6 connected dual stack island. Can the client get a "listening" port to accept externally originating tr= affic? Games need to be able to get listening ports. Does the transition technology break DNSSEC? Do the nodes support it especially when the local net is ipv6-only. Just because the phones went 464xlat doesn't mean that it is the right fi= t for the home or office. Mark > What matters is whether IETF wishes to showcase IPv6-only down to the=20 > customer client devices (and then to harvest the expected client=20 > issues, IPsec failing?), or whether it wishes to showcase "local=20 > dualstack on the small-stub-network, with an IPv6-only provider=20 > connection" to show how small-stub-networks could be connected in the f= uture. > > Let me explain (longer answer). > In a number of years' time, as providers run out of IPv4 publics, edge = > "networks" will be brought on with only global IPv6 addressing=20 > available as the persistent identifier for connected endpoints. (I am=20 > assuming in > Sunset4 we can agree on that). > But what addressing is within the edge network? > 1. For large edge networks where private addressing numbers are not=20 > sufficient to meet the number of connected devices, they will need to=20 > go IPv6-only, as we have seen with large mobile operators, and learnt=20 > with Microsoft Enterprise, Facebook etc. These networks all say=20 > private IPv4 addressing is not sufficient. > 2. For smaller enterprise edge networks then they may well be sitting=20 > and waiting, or following the above, time will tell. > 3. For "small-stub-networks" (SSN), where the number of connected=20 > devices is manageable then clearly IPv4 private addressing is=20 > sufficient. Public Wifi access being a perfect example of SSN, or any = > model using a consumer CPE I suppose. So this is the question for sunse= t4: > (A) Do we wish to advocate IPv6-only in this SSN scenario? in which=20 > case all current and future client issues must be resolved (IPv4=20 > literals) such that the clients work in the absence of an IPv4=20 > address? This case is typified by NAT64/DNS64, other transition mechani= sms are available. > (B) Do we wish to advocate dualstack networking to the client in this=20 > SSN scenario? Avoid client issues by providing them with a GUA and a=20 > IPv4 private? In which case the transition technology (held within the = > CPE) needs to enable dualstack on the access side but on the provider=20 > side, cope with only an IPv6-only provider connection. 464xlat in the=20 > CPE (like 464xlat based tethering from a cellular handset) is an=20 > example of a transition technology in this family, others are available= . > > Both of these SSN approaches assume that within the core of the=20 > internet their remains the legacy IPv4-only content, which seems valid = > for "consumer electronics networking" in general. > They differ on how we expect consumer electronics networking to evolve = > (or how we *want* it to evolve). We could advocate both for sure, but=20 > not sure if that helps move sunset4 forward! > > My opinion, take it or leave it, is that pragmatically, a SSN vision=20 > based on (B) is less problematic. It is less dependent on moving a=20 > whole collection of Consumer Electronics away from today's deficient=20 > state, because (A) essential demands they work in absence of IPv4.=20 > This requires concerted effort to remove the "IPv6-only" mode bugs that= =20we know exist. > The biggest problem with (A) is that you cannot make the network model = > the compulsory model, until the majority of Consumer Electronics is=20 > fully ready, which creates another network provider chicken-egg=20 > problem. You can do OS by OS (something that a popular smartphone and=20 > PC vendor is attempting with IPv6-only, NAT64) but network providers=20 > don't wish to create individual network paradigms for each OS. > > Then we look back at 2., above. Enterprises moving to IPv6-only - do=20 > we have some need and obligation within Sunset4 to push (A) to avoid=20 > Enterprises being trapped in an IPv4 world? To leave dualstack in one=20 > part of the edge (SSN) - does it undermine the benefits we are telling = > enterprises on IPv6-only e.g. removal of dual address complexity. > Personally I believe this is only really an issue in practice where=20 > the enterprise is so large that the 20M private addresses are not=20 > sufficient for their organisation - and I think such enterprises are=20 > big enough to progress this issue themselves if they wish IPv6-only to = work for them. > But if (A) is consensus then Sunset4 should start to define the client = > requirements for absence of IPv4 in a SSN. And unlike provider=20 > networks, enterprise networks own and manage the end to end network=20 > use case themselves. > > The other concern for me about (A) is that I have already=20 > oversimplified devices as "consumer electronics" as though they only=20 > fall into the hands of consumers in consumer usecases. > One of the big issues I foresee with the IPv6-only approach of certain = > OS > vendor(s) is that something like a smartphone can be an end device=20 > with its network interface servicing "on board Apps" (typical mobile=20 > connectivity), but it can also be a network gateway when used for=20 > tethering or "internet sharing". The end device (the device tethered=20 > on the end of the wifi link) may actually be in an enterprise use case = > ("VPN into an office network" for example). By making the SSN=20 > IPv6-only we may risk placing requirements on the enterprise network=20 > (i.e. outside-in connectivity like the VPN concentrator, may need=20 > certain functionality to terminate an IPv6 IPsec VPN etc.). We may=20 > need the requirements for (A) not just be about end devices but also=20 > coordinating requirements for various gateways in enterprise networks? = > If you believe that, it is another serious chicken-egg problem; do we=20 > need enterprise networks upgraded before we can move to a solution for = > SSNs? (See the IPsec comments in=20 > https://tools.ietf.org/html/rfc7269#section-6.1 but in the general=20 > case IPsec VPN is a fail, right?) I am very much in favour of the=20 > family of transition technologies that enable (B). > > SO I inferred a definition of the term SSN to suit my needs in this mai= l. > What is really boils down to is that edge networks need some sort of=20 > CPE or Gateway to the provider network. Do we want that CPE to provide = > dualstack locally or IPv6-only when the provider addresses run out. > Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd=20 > prefer a choice for long term rather than "for next meeting" and I'd=20 > go for something like Jordi's 464xlat in the CPE! Choose wisely :-) If = > an IPv6-only SSID is just to showcase IPsec VPNs still failing, it is=20 > a bit of a waste of people's time). > Regards, > Nick > > > > > > -----Original Message----- > From: sunset4 mailto:sunset4-bounces@ietf.org On Behalf Of JORDI PALET = > MARTINEZ > Sent: 07 October 2016 21:02 > To: > Subject: Re: sunset4 Sunset4 work > > On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" > wrot= e: > > >This is what Im proposing. May be I miss explained it. > > > >NOT asking EVERY device in our network to HAVE 464XLAT client=20 > (CLAT), but having ONLY our CPE to have it. > > > >Nodes will not notice anything. > > > >This is what is going to happen in the future in most of the=20 > networks because they will not have IPv4 for every customer, so why=20 > not trying it ourselves? Already happening in many cellular networks,=20 > like in US, which are close to have 60% IPv6 traffic already. > > You think 464xlat is what's going to happen in the future in most=20 > networks? > Mobile networks, yes, it's a primary transition mechanisms. > Wi-fi networks operated by ISPs or enterprises are more likely to=20 > use NAT64, DS-Lite, or MAP, based on what I'm seeing people working on.= > > I disagree in several points: > 1) 464XLAT is not only for cellular networks, just read the draft. > 2) It has been implemented by some CPE vendors. It can be run in=20 > Virtual Machines as well. > a. http://www.necat.co.jp/en/ipv6/index.html > b. > https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_ap > nic_ > 464xlat.pdf > 3) Ive tested it in several ISP network. Trials at the time being, but = > coming into production. > 4) NAT64 is WORST than 464XLAT. NAT64 doesnt sort out the problems for = > apps using literals. 464XLAT sort it out. Yes, NAT64 was developed=20 > first, but thats the reason 464XLAT was needed, because not everything = > was working in NAT64. > 5) If you dont trust 464XLAT, then you cant trust in NAT64, because is = > just an incomplete version of 464XLAT. > > I agree with you that DS-Lite and MAP are other choices, comparable=20 > with 464XLAT. They will be a better test, for sure than just NAT64. > > If you want something more lightweight than DS-Lite, probably will be=20 > better to use lw4o6. > > Just to make sure it has been understood: Im not asking to implement=20 > anything in the clients of our network. Nobody needs to install anythin= g. > We just need to have a VM or a set of them if we dont trust on the=20 > hardware performance, as the CPE router of the IETF SSIDs that we want = > to run this. This VM need to incorporate the CLAT client. Our network=20 > will behave as an enterprise network which as only IPv6 native=20 > connectivity to Internet, and the ISP (in this case our own network)=20 > will running the PLAT (NAT64/DNS64). > > If you still want to try the NAT64 one more, you can have the NAT64=20 > SSID, that has been already tested in all the RIR meetings, etc. But=20 > this will not run any apps that use literals, old APIs, etc. > > My fear with 464xlat is that it's largely untested in environments = > like the IETF. I would not support making it the default SSID. We've=20 > had a NAT64 SSID for several years; it could be promoted to default,=20 > if we can demonstrate with confidence that everyone can still get=20 > their work done. > > NAT64 as default is not and option. It breaks everything using literal= s. > We want to have a good experience I guess, and be able to detect what=20 > will fail in the future (logging CLAT and NAT64/DNS64 usage), not=20 > break the IETF network. > > Lee > > > > >Saludos, > >Jordi > > > > > >-----Mensaje original----- > >De: sunset4 en nombre de Philip=20 > Homburg > >Responder a: > >Fecha: viernes, 7 de octubre de 2016, 12:04 > >Para: > >CC: "Bjoern A. Zeeb" > >Asunto: Re: sunset4 Sunset4 work > > > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote= : > > > Nastygram. So make the default IETF SSIDs IPv6-only or > (+NAT64) > > > if you want. Then have the ietf-legacy network, which would= > give > > > you IPv4 and a portal page penalty that you have to state th= e > nature > > > why you have to use this network and cant live on the defaul= t > one. > > > Id be so curious to see what happens when people finally hav= e > to > > > start thinking about it.. and open internal tickets .. It w= as > > > great fun doing it 6-ish years ago, .. > > > > Personally, I consider offering NAT64 over wifi quite absurd. > The obvious > > way to provide access to legacy IPv4 is some form of NAT4. How= > it is > > transported over the rest of the network is upto the network > operator. But > > the obvious interface is RFC 894. > > > > So on networks that promote NAT64 (FOSDEM has this setup for > quite a number of > > years now) I just connect to the legacy network. Their legacy > network has > > perfectly fine IPv6, so I consider it way better than the NAT6= 4 > that > > 'everybody' likes to push. > > > > For the specific mobile weirdness, NAT64 make sense. But > everywhere else, > > requiring every device to have 464xlat to deal with IPv4 > literals is just > > bad engineering. If your backbone is IPv6-only, then the obvio= us > solution > > is to deal with this in CPEs, wifi access points, etc. Not to > require all > > hosts to know the details of your network. > > > > > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > > > > > >********************************************** > >IPv4 is over > >Are you ready for the new Internet ? > >http://www.consulintel.es > >The IPv6 Company > > > >This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be for the=20 > use of the > individual(s) named above. If you are not the intended recipient be=20 > aware that any disclosure, copying, distribution or use of the=20 > contents of this information, including attached files, is prohibited. > > > > > > > >_______________________________________________ > >sunset4 mailing list > >sunset4@ietf.org > >https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged=20 > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be=20 > aware that any disclosure, copying, distribution or use of the=20 > contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or=20 > confidential. It's meant only for the individual(s) or entity named=20 > above. > If you're not the intended recipient, note that disclosing, copying,=20 > distributing or using this information is prohibited. > If you've received this email in error, please let me know immediately = > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > EE Limited > Registered office:Trident Place, Mosquito Way, Hatfield,=20 > Hertfordshire, > AL10 9BW > Registered in England no: 02382161 > > EE Limited is a wholly owned subsidiary of: > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 > England no: 1800000 _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, dist= ributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately on= =20the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, A= L10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From nobody Tue Oct 18 02:05:08 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F751295AC for ; Tue, 18 Oct 2016 02:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 yTa4b_V1wSJl for ; Tue, 18 Oct 2016 02:05:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6473127078 for ; Tue, 18 Oct 2016 02:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1476781499; x=1477386299; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=KA9N9MH4qVhB7qXBYCA6/jaTD aLoV5S403sc2ggBCQc=; b=X+YPDZUG5nouiQARV+OZOwq2aQYUQIuMwDvVCX6B/ r0Xe5VA8qehUjEXiDt6Tg3ryWMFzIdMwv9ZwmiKzeaZ2/wItu4Pl1/2svXtZKVBK h3P/wT6RC9NW4aq/VB1F+5pZjKAbaCqJWA32PV8oy3TX4dW1zt1DN1/Tzx/Zcud4 Hk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=MA6bQ5ktwUHzh8oXNuYJVmrGKdn8PhzB30Vr1ub9QHPINE3uliFdIQ3INQFN PcZDmEiK7LVKJELNSpHGWnzxo6tX6Sagge2U33xLVnL51rPdYBdJrzL8B QTT8N2jMvyT1Fan4R1c/dg3GWzz3KYlXF2cdE+1EyMj9tWe0+d8NAQ=; X-MDAV-Processed: mail.consulintel.es, Tue, 18 Oct 2016 11:04:59 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 18 Oct 2016 11:04:56 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005180144.msg for ; Tue, 18 Oct 2016 11:04:56 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:161018:md50005180144::0SU83sAS7kvV+unT:0000HRnD X-Return-Path: prvs=10990f100e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: sunset4@ietf.org User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Tue, 18 Oct 2016 11:04:53 +0200 From: JORDI PALET MARTINEZ To: "sunset4@ietf.org" Message-ID: <54BFB02D-3C78-47DB-AD3E-C2F4744AF496@consulintel.es> Thread-Topic: [sunset4] Sunset4 work References: <48A585E4-3517-4AEE-BD54-7E85640389BF@consulintel.es> <784DF5BC-C901-4C7C-9637-AAB85A506B03@asgard.org> <528F265D-FB3E-4719-AC72-B227AE0FD490@consulintel.es> <8C661EDC-4D87-4CB6-9C42-24BF5B0DD805@lists.zabbadoz.net> <8E20C154-3B5B-4B6F-9AF2-2A4173943581@asgard.org> <6D50BB96-B0BA-4828-BF10-418278F5CD9A@consulintel.es> <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD.EEINT.CO.UK> <20161017195015.50EEC56DFD2A@rock.dv.isc.org> In-Reply-To: <20161017195015.50EEC56DFD2A@rock.dv.isc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] Sunset4 work X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 09:05:07 -0000 If we want the customer to be listening ports to accept incoming traffic, t= hen IPv6-only access technologies don=E2=80=99t make sense, because that wi= ll mean 1 to 1 IPv4 to IPv6 mapping, right? In real world, the problem we have is that we are not having sufficient IPv= 4 addresses for all the =E2=80=9Cresidential=E2=80=9D and cellular networks= . Those networks most of the time don=E2=80=99t need this mapping, so don= =E2=80=99t need the IPv4 address. Even corporate networks most of the time = (specially SMEs), don=E2=80=99t need to expose internal services to outside= . So all those cases could survive without a =E2=80=9Cstatic=E2=80=9D 1 to = 1 IPv4 mapping, and if app developers know that the path is IPv6, new servi= ces, IP cameras, VPNs, etc., could work with just native IPv6. At this way, we can =E2=80=9Crelease=E2=80=9D most of the IPv4 addresses th= at are being used in those networks, world-wide, so the ISP that have them,= can keep growing using pure dual-stack (or another transition that allows = 1 to 1 mapping), for those customers that really need that. In that context, yes, both 464XLAT and MAP-T/E, work fine for those custome= rs that don=E2=80=99t need the 1-1 mapping, regardless of being a cellular = or a wired network. Saludos, Jordi -----Mensaje original----- De: sunset4 en nombre de Mark Andrews Responder a: Fecha: lunes, 17 de octubre de 2016, 21:50 Para: "Heatley, Nick" CC: "sunset4@ietf.org" , "jordi.palet@consulintel.es" Asunto: Re: [sunset4] Sunset4 work =20 In message <6536E263028723489CCD5B6821D4B2132C3B8AA9@UK30S005EXS06.EEAD= .EEINT.CO.UK>, "Heatley, Nick" writes: > A thought provoking discussion. > I don't think the specific transition technology matters so much as t= he > "family" it falls into. =20 Actually the specific transition technology does matter. It impacts on what works and what doesn't in the IPv6 connected dual stack island. =20 Can the client get a "listening" port to accept externally originating traffic? Games need to be able to get listening ports. =20 Does the transition technology break DNSSEC? =20 Do the nodes support it especially when the local net is ipv6-only. =20 Just because the phones went 464xlat doesn't mean that it is the right fit for the home or office. =20 Mark =20 > What matters is whether IETF wishes to showcase IPv6-only down to the > customer client devices (and then to harvest the expected client issu= es, > IPsec failing?), or whether it wishes to showcase "local dualstack on= the > small-stub-network, with an IPv6-only provider connection" to show ho= w > small-stub-networks could be connected in the future. > > Let me explain (longer answer). > In a number of years' time, as providers run out of IPv4 publics, edg= e > "networks" will be brought on with only global IPv6 addressing availa= ble > as the persistent identifier for connected endpoints. (I am assuming = in > Sunset4 we can agree on that). > But what addressing is within the edge network? > 1. For large edge networks where private addressing numbers are not > sufficient to meet the number of connected devices, they will need to= go > IPv6-only, as we have seen with large mobile operators, and learnt wi= th > Microsoft Enterprise, Facebook etc. These networks all say private IP= v4 > addressing is not sufficient. > 2. For smaller enterprise edge networks then they may well be sitting= and > waiting, or following the above, time will tell. > 3. For "small-stub-networks" (SSN), where the number of connected dev= ices > is manageable then clearly IPv4 private addressing is sufficient. Pu= blic > Wifi access being a perfect example of SSN, or any model using a cons= umer > CPE I suppose. So this is the question for sunset4: > (A) Do we wish to advocate IPv6-only in this SSN scenario? in which c= ase > all current and future client issues must be resolved (IPv4 literals) > such that the clients work in the absence of an IPv4 address? This ca= se > is typified by NAT64/DNS64, other transition mechanisms are available= . > (B) Do we wish to advocate dualstack networking to the client in this= SSN > scenario? Avoid client issues by providing them with a GUA and a IPv4 > private? In which case the transition technology (held within the CPE= ) > needs to enable dualstack on the access side but on the provider side= , > cope with only an IPv6-only provider connection. 464xlat in the CPE (= like > 464xlat based tethering from a cellular handset) is an example of a > transition technology in this family, others are available. > > Both of these SSN approaches assume that within the core of the inter= net > their remains the legacy IPv4-only content, which seems valid for > "consumer electronics networking" in general. > They differ on how we expect consumer electronics networking to evolv= e > (or how we *want* it to evolve). We could advocate both for sure, but= not > sure if that helps move sunset4 forward! > > My opinion, take it or leave it, is that pragmatically, a SSN vision > based on (B) is less problematic. It is less dependent on moving a wh= ole > collection of Consumer Electronics away from today's deficient state, > because (A) essential demands they work in absence of IPv4. This requ= ires > concerted effort to remove the "IPv6-only" mode bugs that we know exi= st. > The biggest problem with (A) is that you cannot make the network mode= l > the compulsory model, until the majority of Consumer Electronics is f= ully > ready, which creates another network provider chicken-egg problem. Yo= u > can do OS by OS (something that a popular smartphone and PC vendor is > attempting with IPv6-only, NAT64) but network providers don't wish to > create individual network paradigms for each OS. > > Then we look back at 2., above. Enterprises moving to IPv6-only - do = we > have some need and obligation within Sunset4 to push (A) to avoid > Enterprises being trapped in an IPv4 world? To leave dualstack in one > part of the edge (SSN) - does it undermine the benefits we are tellin= g > enterprises on IPv6-only e.g. removal of dual address complexity. > Personally I believe this is only really an issue in practice where t= he > enterprise is so large that the 20M private addresses are not suffici= ent > for their organisation - and I think such enterprises are big enough = to > progress this issue themselves if they wish IPv6-only to work for the= m. > But if (A) is consensus then Sunset4 should start to define the clien= t > requirements for absence of IPv4 in a SSN. And unlike provider networ= ks, > enterprise networks own and manage the end to end network use case > themselves. > > The other concern for me about (A) is that I have already oversimplif= ied > devices as "consumer electronics" as though they only fall into the h= ands > of consumers in consumer usecases. > One of the big issues I foresee with the IPv6-only approach of certai= n OS > vendor(s) is that something like a smartphone can be an end device wi= th > its network interface servicing "on board Apps" (typical mobile > connectivity), but it can also be a network gateway when used for > tethering or "internet sharing". The end device (the device tethered = on > the end of the wifi link) may actually be in an enterprise use case (= "VPN > into an office network" for example). By making the SSN IPv6-only we = may > risk placing requirements on the enterprise network (i.e. outside-in > connectivity like the VPN concentrator, may need certain functionalit= y to > terminate an IPv6 IPsec VPN etc.). We may need the requirements for (= A) > not just be about end devices but also coordinating requirements for > various gateways in enterprise networks? If you believe that, it is > another serious chicken-egg problem; do we need enterprise networks > upgraded before we can move to a solution for SSNs? (See the IPsec > comments in https://tools.ietf.org/html/rfc7269#section-6.1 but in th= e > general case IPsec VPN is a fail, right?) > I am very much in favour of the family of transition technologies th= at > enable (B). > > SO I inferred a definition of the term SSN to suit my needs in this m= ail. > What is really boils down to is that edge networks need some sort of = CPE > or Gateway to the provider network. Do we want that CPE to provide > dualstack locally or IPv6-only when the provider addresses run out. > Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd > prefer a choice for long term rather than "for next meeting" and I'd = go > for something like Jordi's 464xlat in the CPE! Choose wisely :-) > If an IPv6-only SSID is just to showcase IPsec VPNs still failing, it= is > a bit of a waste of people's time). > Regards, > Nick > > > > > > -----Original Message----- > From: sunset4 mailto:sunset4-bounces@ietf.org On Behalf Of JORDI PALE= T > MARTINEZ > Sent: 07 October 2016 21:02 > To: > Subject: Re: sunset4 Sunset4 work > > On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" > wr= ote: > > >This is what Im proposing. May be I miss explained it. > > > >NOT asking EVERY device in our network to HAVE 464XLAT client > (CLAT), but having ONLY our CPE to have it. > > > >Nodes will not notice anything. > > > >This is what is going to happen in the future in most of the > networks because they will not have IPv4 for every customer, so why n= ot > trying it ourselves? Already happening in many cellular networks, lik= e in > US, which are close to have 60% IPv6 traffic already. > > You think 464xlat is what's going to happen in the future in most > networks? > Mobile networks, yes, it's a primary transition mechanisms. > Wi-fi networks operated by ISPs or enterprises are more likely to= use > NAT64, DS-Lite, or MAP, based on what I'm seeing people working on. > > I disagree in several points: > 1) 464XLAT is not only for cellular networks, just read the draft. > 2) It has been implemented by some CPE vendors. It can be run in Virt= ual > Machines as well. > a. http://www.necat.co.jp/en/ipv6/index.html > b. > https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_a= pnic_ > 464xlat.pdf > 3) Ive tested it in several ISP network. Trials at the time being, bu= t > coming into production. > 4) NAT64 is WORST than 464XLAT. NAT64 doesnt sort out the problems fo= r > apps using literals. 464XLAT sort it out. Yes, NAT64 was developed fi= rst, > but thats the reason 464XLAT was needed, because not everything was > working in NAT64. > 5) If you dont trust 464XLAT, then you cant trust in NAT64, because i= s > just an incomplete version of 464XLAT. > > I agree with you that DS-Lite and MAP are other choices, comparable w= ith > 464XLAT. They will be a better test, for sure than just NAT64. > > If you want something more lightweight than DS-Lite, probably will be > better to use lw4o6. > > Just to make sure it has been understood: Im not asking to implement > anything in the clients of our network. Nobody needs to install anyth= ing. > We just need to have a VM or a set of them if we dont trust on the > hardware performance, as the CPE router of the IETF SSIDs that we wan= t to > run this. This VM need to incorporate the CLAT client. Our network wi= ll > behave as an enterprise network which as only IPv6 native connectivit= y to > Internet, and the ISP (in this case our own network) will running the > PLAT (NAT64/DNS64). > > If you still want to try the NAT64 one more, you can have the NAT64 S= SID, > that has been already tested in all the RIR meetings, etc. But this w= ill > not run any apps that use literals, old APIs, etc. > > My fear with 464xlat is that it's largely untested in environment= s > like the IETF. I would not support making it the default SSID. We've = had > a NAT64 SSID for several years; it could be promoted to default, if w= e > can demonstrate with confidence that everyone can still get their wor= k > done. > > NAT64 as default is not and option. It breaks everything using liter= als. > We want to have a good experience I guess, and be able to detect what > will fail in the future (logging CLAT and NAT64/DNS64 usage), not bre= ak > the IETF network. > > Lee > > > > >Saludos, > >Jordi > > > > > >-----Mensaje original----- > >De: sunset4 en nombre de Philip Hombu= rg > > >Responder a: > >Fecha: viernes, 7 de octubre de 2016, 12:04 > >Para: > >CC: "Bjoern A. Zeeb" > >Asunto: Re: sunset4 Sunset4 work > > > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wro= te: > > > Nastygram. So make the default IETF SSIDs IPv6-only or > (+NAT64) > > > if you want. Then have the ietf-legacy network, which wou= ld > give > > > you IPv4 and a portal page penalty that you have to state = the > nature > > > why you have to use this network and cant live on the defa= ult > one. > > > Id be so curious to see what happens when people finally h= ave > to > > > start thinking about it.. and open internal tickets .. It= was > > > great fun doing it 6-ish years ago, .. > > > > Personally, I consider offering NAT64 over wifi quite absurd= . > The obvious > > way to provide access to legacy IPv4 is some form of NAT4. H= ow > it is > > transported over the rest of the network is upto the network > operator. But > > the obvious interface is RFC 894. > > > > So on networks that promote NAT64 (FOSDEM has this setup for > quite a number of > > years now) I just connect to the legacy network. Their legac= y > network has > > perfectly fine IPv6, so I consider it way better than the NA= T64 > that > > 'everybody' likes to push. > > > > For the specific mobile weirdness, NAT64 make sense. But > everywhere else, > > requiring every device to have 464xlat to deal with IPv4 > literals is just > > bad engineering. If your backbone is IPv6-only, then the obv= ious > solution > > is to deal with this in CPEs, wifi access points, etc. Not t= o > require all > > hosts to know the details of your network. > > > > > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > > > > > >********************************************** > >IPv4 is over > >Are you ready for the new Internet ? > >http://www.consulintel.es > >The IPv6 Company > > > >This electronic message contains information which may be privil= eged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. > > > > > > > >_______________________________________________ > >sunset4 mailing list > >sunset4@ietf.org > >https://www.ietf.org/mailman/listinfo/sunset4 > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. > > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named > above. > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. > If you've received this email in error, please let me know immediatel= y on > the email address above. Thank you. > > We monitor our email system, and may record your emails. > > EE Limited > Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshir= e, > AL10 9BW > Registered in England no: 02382161 > > EE Limited is a wholly owned subsidiary of: > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Oct 18 09:45:14 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4161296BC for ; Tue, 18 Oct 2016 09:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMflEduwJP9p for ; Tue, 18 Oct 2016 09:45:10 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 27B0712957E for ; Tue, 18 Oct 2016 09:45:10 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u9IGj8XL006475 for ; Tue, 18 Oct 2016 12:45:08 -0400 Received: (qmail 15851 invoked by uid 0); 18 Oct 2016 16:45:08 -0000 X-TCPREMOTEIP: 204.235.114.162 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.116.238.146?) (lee@asgard.org@204.235.114.162) by 0 with ESMTPA; 18 Oct 2016 16:45:08 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Tue, 18 Oct 2016 12:45:10 -0400 From: Lee Howard To: Message-ID: <10E93FFE-29B4-454C-9C59-6A5D248CC80C@asgard.org> Thread-Topic: draft-howard-ipv6-ietf "IETF: End Work on IPv4" Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3559639510_95277591" Archived-At: Subject: [sunset4] draft-howard-ipv6-ietf "IETF: End Work on IPv4" X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:45:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3559639510_95277591 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Submitted for discussion: https://tools.ietf.org/html/draft-howard-ipv6-ietf-00 This may look like things we've talked about before. I hope it reflects what the WG has consensus on, but it will be interesting to discuss it in Seoul. It is very, very short. Lee --B_3559639510_95277591 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Th= is may look like things we've talked about before. I hope it reflects what t= he WG has consensus on, but it will be interesting to discuss it in Seoul.

It is very, very short.

Lee

--B_3559639510_95277591-- From nobody Fri Oct 21 16:26:27 2016 Return-Path: X-Original-To: sunset4@ietf.org Delivered-To: sunset4@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FAD129865; Fri, 21 Oct 2016 16:21:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207881.28214.17769321930329288081.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:18 -0700 Archived-At: Cc: sunset4@ietf.org, terry.manderson@icann.org Subject: [sunset4] sunset4 - Requested session has been scheduled for IETF 97 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:19 -0000 Dear Marc Blanchet, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sunset4 Session 1 (1:00:00) Thursday, Morning Session II 1110-1210 Room Name: Studio 2 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Sunsetting IPv4 Area Name: Internet Area Session Requester: Marc Blanchet Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops intarea homenet dhc Special Requests: monday or tuesday ---------------------------------------------------------