From nobody Thu May 2 20:14:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA51200DE; Thu, 2 May 2019 20:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 b8E7Lq__X2PB; Thu, 2 May 2019 20:14:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219B8120058; Thu, 2 May 2019 20:14:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 41962B824FA; Thu, 2 May 2019 20:14:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190503031422.41962B824FA@rfc-editor.org> Date: Thu, 2 May 2019 20:14:22 -0700 (PDT) Archived-At: Subject: [v6ops] =?utf-8?q?RFC_8585_on_Requirements_for_IPv6_Customer_Edg?= =?utf-8?q?e_Routers_to_Support_IPv4-as-a-Service?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 03:14:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8585 Title: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service Author: J. Palet Martinez, H. M.-H. Liu, M. Kawashima Status: Informational Stream: IETF Date: May 2019 Mailbox: jordi.palet@theipv6company.com, hans.liu@dlinkcorp.com, kawashimam@vx.jp.nec.com Pages: 21 Characters: 49405 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-transition-ipv4aas-15.txt URL: https://www.rfc-editor.org/info/rfc8585 DOI: 10.17487/RFC8585 This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market. Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri May 3 02:26:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3119F1200E5 for ; Fri, 3 May 2019 02:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_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 mTx9ScYPCRrf for ; Fri, 3 May 2019 02:26:32 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 5632512006D for ; Fri, 3 May 2019 02:26:32 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x439QK6h048760 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 3 May 2019 11:26:27 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: v6ops@ietf.org References: From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: <77004251-b478-696d-8e7b-a1f460a88c9e@hit.bme.hu> Date: Fri, 3 May 2019 18:26:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9085BB3FA3679070FAB61536" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 09:26:35 -0000 This is a multi-part message in MIME format. --------------9085BB3FA3679070FAB61536 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear v6ops Members, Yes, as Fread wrote, we would like our draft be adopted by the WG. IMHO, RFC 6180 covers a much wider topic than our I-D, thus I recommend that our I-D should only update it (and not obsolete it). It seemed to me from the minutes ( https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html ) that several people considered our draft useful. Please, react now: Do you consider it useful and support its adoption as a WG item? What do you think is missing from it? Which direction should we go? Are there any questionable statements? Anything, which is biased? Best regards, Gábor On 4/30/2019 11:03, Fred Baker wrote: > At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180. > >> On Apr 29, 2019, at 10:32 AM, Ron Bonica wrote: >> >> Folks, >> >> Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it. >> >> This week, please review and comment on draft-lmhp-v6ops-transition-comparison. >> >> Fred and Ron >> >> Non-Juniper >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------9085BB3FA3679070FAB61536 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dear v6ops Members,

Yes, as Fread wrote, we would like our draft be adopted by the WG.

IMHO, RFC 6180 covers a much wider topic than our I-D, thus I recommend that our I-D should only update it (and not obsolete it).

It seemed to me from the minutes ( https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html ) that several people considered our draft useful.

Please, react now: Do you consider it useful and support its adoption as a WG item?

What do you think is missing from it? Which direction should we go?

Are there any questionable statements? Anything, which is biased?

Best regards,

Gábor


On 4/30/2019 11:03, Fred Baker wrote:
At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180.


On Apr 29, 2019, at 10:32 AM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:

Folks,

Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-lmhp-v6ops-transition-comparison.

                                                            Fred and Ron

Non-Juniper

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


      

      

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


    

  


--------------9085BB3FA3679070FAB61536--


From nobody Fri May  3 09:24:49 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E51200EF for ; Fri,  3 May 2019 09:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 wLKruBw7i-0n for ; Fri,  3 May 2019 09:24:45 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367AA1200E3 for ; Fri,  3 May 2019 09:24:45 -0700 (PDT)
Received: from tpw09926dag05h.domain1.systemhost.net (10.9.202.32) by RDW083A011ED67.bt.com (10.187.98.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 3 May 2019 17:28:58 +0100
Received: from tpw09926dag13f.domain1.systemhost.net (10.9.212.21) by tpw09926dag05h.domain1.systemhost.net (10.9.202.32) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 3 May 2019 17:24:42 +0100
Received: from bwp09926084.bt.com (10.36.82.115) by tpw09926dag13f.domain1.systemhost.net (10.9.212.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 3 May 2019 17:24:41 +0100
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.55) by smtpe1.intersmtp.com (10.36.82.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Fri, 3 May 2019 17:24:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykB0y27eBDPg0uhT0JoO0tXyHe+8qYTxGR3f8ayLG/4=; b=Kz+gqMk8U3IW0N+GMJwEY45bA47K/pkJ/OjUS23VFx+sm3cAKa23i5AZ6NbeTFlpZjAnw0oWB5UAW4iuT0sfK61z5rfWLZi0Rk7GiLfoVuM1HhCiuMWdh8apfU4sifGAnDQfT4ljwelvcdoLiNqg3h58L2jTdJm2xfWLdNxTgKs=
Received: from CWXP123MB2423.GBRP123.PROD.OUTLOOK.COM (20.179.110.147) by CWXP123MB2568.GBRP123.PROD.OUTLOOK.COM (20.179.111.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Fri, 3 May 2019 16:24:41 +0000
Received: from CWXP123MB2423.GBRP123.PROD.OUTLOOK.COM ([fe80::f0b1:1580:565d:a897]) by CWXP123MB2423.GBRP123.PROD.OUTLOOK.COM ([fe80::f0b1:1580:565d:a897%5]) with mapi id 15.20.1856.012; Fri, 3 May 2019 16:24:41 +0000
From: 
To: , 
Thread-Topic: state of IPv4v6/IPv6 roaming in 3GPP networks
Thread-Index: AdUBzJC+nlehT8qnTkSqIANfVudR4w==
Date: Fri, 3 May 2019 16:24:41 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; 
x-originating-ip: [2a00:23c5:311:7100:a1e3:547e:1330:ad09]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7acb3516-00f2-4dbe-1163-08d6cfe3d84a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CWXP123MB2568; 
x-ms-traffictypediagnostic: CWXP123MB2568:
x-antispam-2: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0026334A56
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(346002)(396003)(366004)(189003)(199004)(186003)(102836004)(52536014)(6116002)(790700001)(46003)(316002)(5024004)(2906002)(450100002)(99286004)(54896002)(476003)(486006)(256004)(14444005)(6306002)(2501003)(6436002)(9686003)(8936002)(68736007)(53936002)(55016002)(7736002)(478600001)(66446008)(71200400001)(5660300002)(76116006)(8676002)(66946007)(73956011)(64756008)(81156014)(66476007)(81166006)(66556008)(71190400001)(25786009)(7696005)(4744005)(110136005)(6506007)(86362001)(14454004)(33656002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:CWXP123MB2568; H:CWXP123MB2423.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dyS0kubSARhtjP9Lq+OYk2ICkvqdyGABZO2CS36om2be5Y5gq3nJrxqRzsLynsBPjZ15w1xFYnhjFs9L/azInGE5at+1pslFxMimXHS2UqcwagxEyYf352sNC//RLyTj+MeZpj93tYXPvW3LfIlYGdr+dsZ3PA/IR0RcX6wgDZ6q29aQLd2zr5FcHxKCIoao4flYVqjgR0oZeezHieHSp6iNVWaod2YEk5y3sUwXMLK0WZj1p8SInUnbVRRA/47PdgrMlyB4bWazE5cTck680QAEro42gAjjWlWPkrVYiUKrn9AfNDVe7OcXqW5RHKyMPMK9JZXTfNP6lZCCkRfxmSWToB+ujaS8FsJ47b3G5HkwFAkEgWQY4jKHCKY7ytN31qHdLvMTRogYPO9ur+Pri0VCmBgQJ98odCfvR9maOvg=
Content-Type: multipart/alternative; boundary="_000_CWXP123MB2423E30FAF89BC30C1D64584EA350CWXP123MB2423GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7acb3516-00f2-4dbe-1163-08d6cfe3d84a
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 16:24:41.1951 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP123MB2568
X-OriginatorOrg: bt.com
Archived-At: 
Subject: [v6ops] state of IPv4v6/IPv6 roaming in 3GPP networks
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 May 2019 16:24:48 -0000

--_000_CWXP123MB2423E30FAF89BC30C1D64584EA350CWXP123MB2423GBRP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi there, its been a few years since IPv6 roaming analysis RFC7445 was rele=
ased.
I would appreciate if anyone can comment on if they have found the landscap=
e has changed?
I am most interested in problem of section 3: Failure Case in the Network A=
ttachment. Is it still a concern to Operators?
Thanks,
Nick



--_000_CWXP123MB2423E30FAF89BC30C1D64584EA350CWXP123MB2423GBRP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi there, its been a few years since IPv6 roaming an=
alysis RFC7445 was released.


I would appreciate if anyone can comment on if they =
have found the landscape has changed?


I am most interested in problem of section 3: Failur=
e Case in the Network Attachment. Is it still a concern to Operators?<=
/o:p>


Thanks,


Nick


 


 






--_000_CWXP123MB2423E30FAF89BC30C1D64584EA350CWXP123MB2423GBRP_--


From nobody Sat May  4 05:58:28 2019
Return-Path: 
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE356120019; Sat,  4 May 2019 05:58:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: v6ops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: v6ops@ietf.org
Message-ID: <155697469785.18577.1400701835898354355@ietfa.amsl.com>
Date: Sat, 04 May 2019 05:58:17 -0700
Archived-At: 
Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-06.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 04 May 2019 12:58:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
        Author          : Jordi Palet Martinez
	Filename        : draft-ietf-v6ops-nat64-deployment-06.txt
	Pages           : 43
	Date            : 2019-05-04

Abstract:
   This document describes how NAT64 (including 464XLAT) can be deployed
   in an IPv6 network, whether cellular ISP, broadband ISP, or
   enterprise, and possible optimizations.  The document also discusses
   issues to be considered when having IPv6-only connectivity,
   regarding: a) DNS64, b) applications or devices that use literal IPv4
   addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
   applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-06
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon May  6 07:36:30 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FDB1201EB for ; Mon,  6 May 2019 07:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 HY2Pd_IbKE1W for ; Mon,  6 May 2019 07:36:17 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1439D12019B for ; Mon,  6 May 2019 07:36:17 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x46EYlnR024618 for ; Mon, 6 May 2019 07:36:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=jvsjbd4jQgGX06YILHvChPgsb/ik2vBkiICXQr1aiW8=; b=QFsQ5AUcq52MIj+NQzJHWDZoqcyq8DKggpDDRvSlWyNhD6J4ZjGLboOcJy+1ePvB8RLT RH3NIap80kpXjFbEVjDlPGjQm1EXpFkAtPSJY2MCfwe5GDLt2sb00I6O4QdZc0N/xojU ZyKmr0WzNeSGBRszfiH/9s9fNqiEm+G/Ju3HAaxMv0rnktXTdjsoS7I6iR03ysPNFUIF IAAJF3h991JmRMqwqN4ufxuH5/wqD+0XjR7eb9c2ELiS+w1WgrS44n8p6ph/eAIjf3jh jFgMthcJGY17lOzMNa6X+ZI1BiYz1GIWxevOzLjT8tIK/MHWGQatYt1y7zVLH+vpw0aQ zg== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2053.outbound.protection.outlook.com [104.47.38.53]) by mx0a-00273201.pphosted.com with ESMTP id 2sah2srfx6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 06 May 2019 07:36:16 -0700
Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4647.namprd05.prod.outlook.com (52.135.233.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.18; Mon, 6 May 2019 14:36:09 +0000
Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29%7]) with mapi id 15.20.1878.014; Mon, 6 May 2019 14:36:09 +0000
From: Ron Bonica 
To: "v6ops@ietf.org" 
Thread-Topic: draft-gont-6man-slaac-renum
Thread-Index: AdUEGPlS/gA5giKBS/q1PKK98cDXOw==
Content-Class: 
Date: Mon, 6 May 2019 14:36:09 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
msip_labels: MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Enabled=True; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Owner=rbonica@juniper.net; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SetDate=2019-05-06T14:36:03.3707337Z; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Name=Non-Juniper; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Application=Microsoft Azure Information Protection; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Extended_MSFT_Method=Manual; Sensitivity=Non-Juniper
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d658dd71-ab14-4ef9-cf33-08d6d2302e47
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4647; 
x-ms-traffictypediagnostic: BYAPR05MB4647:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:3826;
x-forefront-prvs: 0029F17A3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(136003)(189003)(199004)(476003)(68736007)(2906002)(2501003)(66476007)(8676002)(81156014)(81166006)(6116002)(3846002)(7736002)(305945005)(6916009)(33656002)(8936002)(486006)(53936002)(25786009)(2351001)(55016002)(6506007)(71200400001)(71190400001)(6436002)(5640700003)(558084003)(14454004)(73956011)(76116006)(66946007)(478600001)(186003)(64756008)(66556008)(66446008)(86362001)(256004)(26005)(102836004)(52536014)(7696005)(74316002)(66066001)(5660300002)(99286004)(316002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4647; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: edi2pcz2FrdcN8pEahH5KBYSOVVvxOpH7Epg5gpnDqXbpF1r7izAe4Nb1fAqzk6kVIZTKcnRJU32wgYeJKANp0nt/xYDhHeDp71oqOEHczmwvBHu0Hrfhs+xLtkx3YVNNOhB+WfU0JBHbhJ8SyQAEKjJab61BtPZ+DLPaPUhOnd0uKV1AExzMelv58TfGyDKmyeeY2dm/OjyUKbQ8+YdtU1GW9CtnrGCllzcmogtbg3/RAL31lfMwuQU7K3DzVlhixgq7v7xkwsVf/xrKV38hhEKAja7hzaYXRRCwPCcOE/pm+GqijnjwnQuhowGiGnxb9blrNJxeOjp6PodvDRxMnzFXCw4ubApM1oiQQr4kn0fPmqbNG+2wsujMDrXTDf11CEl5lzwOugzpyKBrCHO9R2gyL/K6R12lHOcDWrwUbw=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d658dd71-ab14-4ef9-cf33-08d6d2302e47
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2019 14:36:09.4406 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4647
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-06_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=431 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905060126
Archived-At: 
Subject: [v6ops] draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 May 2019 14:36:28 -0000

Folks,

Each week between now and IETF 105, we will review and discuss one draft wi=
th an eye towards progressing it.

This week, please review and comment on draft-gont-6man-slaac-renum.

                                                             Fred and Ron

Non-Juniper


From nobody Tue May  7 01:52:18 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAF712001B for ; Tue,  7 May 2019 01:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtHrHgkCvAuU for ; Tue,  7 May 2019 01:52:15 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F551200A2 for ; Tue,  7 May 2019 01:52:15 -0700 (PDT)
Received: from astfgl.hanazo.no (77.16.61.110.tmi.telenormobil.no [77.16.61.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 9F5C4FECC00E; Tue,  7 May 2019 08:52:14 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 218AB14B684A; Tue,  7 May 2019 10:52:11 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Ole Troan 
In-Reply-To: 
Date: Tue, 7 May 2019 10:52:10 +0200
Cc: "v6ops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Ron Bonica 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 08:52:17 -0000

Ron,

> Each week between now and IETF 105, we will review and discuss one =
draft with an eye towards progressing it.
>=20
> This week, please review and comment on draft-gont-6man-slaac-renum.

This document got lots of discussion and concerns raised in 6man/v6ops.
There was also a side meeting on it, in Bangkok (or Prague, it's all a =
blur to me)
Perhaps a start would be for the chairs/authors to summarise the issues =
already voiced?

Cheers,
Ole=


From nobody Tue May  7 13:54:15 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED1120179 for ; Tue,  7 May 2019 13:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EAdWASN0NADu for ; Tue,  7 May 2019 13:54:02 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 D1E00120086 for ; Tue,  7 May 2019 13:54:02 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id 85so8910334pgc.3 for ; Tue, 07 May 2019 13:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NeqDJlTJRbKi/P7F3hsHfkOyXhcyG4AEAT6Z3ZYvWqs=; b=bWD5vNupwFZ0pdadUenWDTIrDoQdtw629Gk2dkLWdkm+9KJ4FsiiJNk/005ocO8Ru3 y/k+ZV4bHUlD+i9rpUbjRvKV1vjh4Z4bE7UX6ZKO8J0NZiMzuoDMXZBmJlZ8wtoELS2R pH88QgbNGgVamK3+GnkSKO+nfc0Q57jOxbT8KlVKTeHtnCetNSdmbAVvj5H1modjyHoQ MPGXiKEHM3fT0voXaOk+Cp/P/iNjpEeWvb7vqSVWTmIiObgKZJ1wdFPiREb6tS7EcSwT yBjnK92m8OoRkcsyPatZKmAC4LA5SFh9wN2fQfOMv0b1qHrV/pEWEccQLJImXwsReF3P CJ6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NeqDJlTJRbKi/P7F3hsHfkOyXhcyG4AEAT6Z3ZYvWqs=; b=UotmYh5oAdxVdHq6U+Ga1Ebt2Atd1O8e6isKCkQ4tjw/AH2tRTAf4sMB+eUOpmybsn JFVOO5w1639Gze20ThwOuc7ufXxe2fMSqShyfpsz+ZnljIBDem18b3q+M+CsXZfCwpQX 3XKBlaIHDbpgBNo59KBxI0s1nPp8G/zyU5YYQbn7ZFiuNmDOtNVEBOspAj0+WUz6JwO8 OzDCHodqYm81kHb9Rap5LSxElkgfzjfk/OoMYOOZFFNXAbVpdLxifkka8PqtHvs7DuEB msocTH91fGbuxBDyJt2y+1eqR2lBn3lOobko9NTyEH2Fvj18aeV3l/lQD74tSx/M/5L0 leDQ==
X-Gm-Message-State: APjAAAV6dAXYCGNUl4l0c9x7BH/E2V07loE+gfchnaQ0xBwH1IEK4mtT ZftN5TMjOfmkI4JDVBDptJqiDEWq
X-Google-Smtp-Source: APXvYqzyT8MkHv5AjpUBBjYI5CVcEJYE/GYdsgVex6jfWzlanRA2Me6DD9u4bGbbzJNDQl+VObQFng==
X-Received: by 2002:a65:610a:: with SMTP id z10mr42447300pgu.54.1557262442275;  Tue, 07 May 2019 13:54:02 -0700 (PDT)
Received: from ?IPv6:2600:8801:d004:600:891c:833:ae74:b7e5? ([2600:8801:d004:600:891c:833:ae74:b7e5]) by smtp.gmail.com with ESMTPSA id a129sm17979316pfa.152.2019.05.07.13.54.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 13:54:01 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_2A49E06C-1152-4BDF-9D0A-876D8A163EB2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 7 May 2019 13:53:59 -0700
In-Reply-To: 
Cc: Ron Bonica , "v6ops@ietf.org" 
To: Ole Troan , Fernando Gont , jan@go6.si
References:  
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [v6ops] draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 20:54:06 -0000

--Apple-Mail=_2A49E06C-1152-4BDF-9D0A-876D8A163EB2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

If you wish. I'd suggest we ask the authors to do that.

> On May 7, 2019, at 1:52 AM, Ole Troan  wrote:
>=20
> Ron,
>=20
>> Each week between now and IETF 105, we will review and discuss one =
draft with an eye towards progressing it.
>>=20
>> This week, please review and comment on draft-gont-6man-slaac-renum.
>=20
> This document got lots of discussion and concerns raised in =
6man/v6ops.
> There was also a side meeting on it, in Bangkok (or Prague, it's all a =
blur to me)
> Perhaps a start would be for the chairs/authors to summarise the =
issues already voiced?
>=20
> Cheers,
> Ole
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_2A49E06C-1152-4BDF-9D0A-876D8A163EB2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlzR8GcACgkQEhdRnd2G
P+Awtg//eYKt8txuH01TxeGseLX1WvNkS9QyTGZDi6VErnSQ5AymV1zeHrIE3ruZ
WhSPZt6u8uIa/YRDfw3ENl0nBercn3OMvkEHHAyeVvImTViM089lx0caW16hZ+0B
Vn+d6+xFm3NssQNeYY2ZGuhxQ1rCVU8PlSJPr858hbIYj9LrBUio7IA38hnR8A62
3yBJF3lSG2lmNveUQpGrGchwef0KrPnlnWZpnuRopa6UQQgYJX1d5pdMFDizo20g
j1QHJAyH3Qm+N5g0r0vB1JfqMGhO0IVIc5EuInE9QdLXt3+/xezqKSba743aEbk9
iZsSRzcFKFY3smCZVoWwtRydZ5qjBh8LrF1TlM5D9RhOa42Zky/iuZtjef8StIkO
sdIyKGtRqF7hmst8NwBUkZymTqU3BkWkk0jsMVo4GAjf5OgpoUh1ug9xsCW+MBNM
+VbeozwvuELf/+BxYMsY+OCNa8hZiyinNibWCRSYAo57GwcXS9HazislUMuParDj
LVC1Lu68x+BQHBzv9lepU/bCXjSB9pZ2Cc8iCy+ef3oRpVUwyiHqGl8TfQMb3d17
rUDIePhmjCHgy/LFElqPsY2jebUoD75bg1g1jW99a1/23Lyi8b5oFYKU40FOJf9q
YIMkp9kwtw/Xbluu0H5Qjaac9yHpICIJoFk5EKOo7PGL/UPmFWU=
=GbuM
-----END PGP SIGNATURE-----

--Apple-Mail=_2A49E06C-1152-4BDF-9D0A-876D8A163EB2--


From nobody Thu May  9 00:53:14 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C086612008C; Thu,  9 May 2019 00:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urq_okOIx8rb; Thu,  9 May 2019 00:53:09 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F23412011A; Thu,  9 May 2019 00:53:09 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C39BB7; Thu,  9 May 2019 09:53:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557388387; bh=/hWDAeWCa5tfsiNHP7bGvBreaZKycDrW6MFSW5WVrKM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kYwsTBGHolHoYnSruUBC48vdhgn7et1nRSbaciVRs47+0okHXFDTuGNz8Rk0pkQB3 dn3USQdJlHz2eo6xEYyEhCQYAMSYzZDY1JBtm+WuH6VtlicMhLifWnz8iAPFvrt7yf 3tNkywcoFqNZgxSOzIH69EidkPB/vg6YIeAnmNJ0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 885D7B2; Thu,  9 May 2019 09:53:07 +0200 (CEST)
Date: Thu, 9 May 2019 09:53:07 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ron Bonica 
cc: "v6ops@ietf.org" ,  "draft-ietf-v6ops-nat64-deployment@ietf.org" 
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2019 07:53:12 -0000

On Mon, 22 Apr 2019, Ron Bonica wrote:

> Folks,
>
> This ends WG Last Call on draft-ietf-v6ops-nat64-deployment-04.
>
> Mikael,
>
> Would you provide the shepherd's write-up.

As part of this write-up I realised RFC2119/RFC8174 language in there, is 
this really applicable for this kind of draft? Do we need more text on 
what this really means?

Can an informational draft even use RFC2119/RFC8174 language in it with 
the boilerplate RFC8174 header? RFC7084 is informational but has a 
different RFC2119/8174 reference section that spells out what it means 
when it's using this language.

There are things like:

"Taking in consideration that discussion and other issues, we can
    summarize the possible decision points as:

    a.  The WKP MUST NOT be used to represent non-global IPv4 addresses.
        If this is required because the network to be translated use non-
        global addresses, then an NSP is required."

So first there is some kind of considerations/summary list and then we get 
RFC2119 language?

Also, the lists in the document are either as 1,2,3 or a,b,c or bullet 
lists with "o" before. Is there a difference between these different 
methods of "numbering" lists?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu May  9 14:38:30 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5A51200F7; Thu,  9 May 2019 14:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 P1ib8y-foJ4v; Thu,  9 May 2019 14:38:26 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD18120026; Thu,  9 May 2019 14:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1557437903; x=1558042703; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=ElKvWCa+NqbW2XJDQ9inl6adI/c/mieDObarcpshC6s=; b=APukJgzMyEXU2 GPDPIMq9CURzScHfSi3vP1X20jJokL/7sVCZEZiF8r0rUVlHqNlUCB1ghQMRxuTc tv4QR3JRwWsfBV2HIissp4s+w9CggpZqtiM8tj2cwdu/rLxF36XBSQXoDP4KLq7l a5dC9TyQV99Y+oXTvz5Ft2X0mYrjt4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 09 May 2019 23:38:23 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 09 May 2019 23:38:22 +0200
Received: from [45.6.252.99] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006241636.msg; Thu, 09 May 2019 23:38:22 +0200
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [45.6.252.99]
X-MDArrival-Date: Thu, 09 May 2019 23:38:22 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=103204aa1b=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.9.190412
Date: Thu, 09 May 2019 17:38:13 -0400
From: JORDI PALET MARTINEZ 
To: Mikael Abrahamsson , Ron Bonica 
CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" 
Message-ID: <7078E990-32BF-4057-831A-541C5AC2B852@consulintel.es>
Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
References:   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2019 21:38:30 -0000

Hi Mikael,

Responding below, in-line.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 9/5/19 3:54, "v6ops en nombre de Mikael Abrahamsson"  escribi=C3=B3:

    On Mon, 22 Apr 2019, Ron Bonica wrote:
   =20
    > Folks,
    >
    > This ends WG Last Call on draft-ietf-v6ops-nat64-deployment-04.
    >
    > Mikael,
    >
    > Would you provide the shepherd's write-up.
   =20
    As part of this write-up I realised RFC2119/RFC8174 language in there, =
is=20
    this really applicable for this kind of draft? Do we need more text on=
=20
    what this really means?

I recall I've included this once in a previous (also informational) documen=
t (now RFC8585) I was asked for it.
   =20
    Can an informational draft even use RFC2119/RFC8174 language in it with=
=20
    the boilerplate RFC8174 header? RFC7084 is informational but has a=20
    different RFC2119/8174 reference section that spells out what it means=
=20
    when it's using this language.
   =20
    There are things like:
   =20
    "Taking in consideration that discussion and other issues, we can
        summarize the possible decision points as:
   =20
        a.  The WKP MUST NOT be used to represent non-global IPv4 addresses=
.
            If this is required because the network to be translated use no=
n-
            global addresses, then an NSP is required."

I'm happy to remove the upper case,  but the reason for those, in this spec=
ific section, is that it is a summary of already existing text in RFC6052, =
that already have the upper case, so I think it make sense to keep them.
   =20
    So first there is some kind of considerations/summary list and then we =
get=20
    RFC2119 language?
   =20
    Also, the lists in the document are either as 1,2,3 or a,b,c or bullet=
=20
    lists with "o" before. Is there a difference between these different=20
    methods of "numbering" lists?

It is just a matter of increase readability. In some sections, there are "c=
onsecutive" sequences of "lists" and I think those are easier to read and t=
o avoid confusion if I alternate letters and numbers in different lists.
   =20
    --=20
    Mikael Abrahamsson    email: swmike@swm.pp.se
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Sun May 12 15:37:24 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE81201DC for ; Sun, 12 May 2019 15:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oPm2BBUTQOpk for ; Sun, 12 May 2019 15:37:20 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 C93ED1201E2 for ; Sun, 12 May 2019 15:37:20 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id f97so341475plb.5 for ; Sun, 12 May 2019 15:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kotCjzjYQlmP7XO7qEkMQL+5pg4T4SBj3bisS5AShbo=; b=c0boHVOVUt2OnrJIi9wyCbKqfOcqBcr/hiohDT3kjVbeYAXPoAg1Yn/3fD7V2/Qtsz 9U2SHczazxCD/d4YXxFpxirrf2YeP730dF02ujJa7wZk+4GoLy/vTYuJFqlLU9pEYzeg DG5wNTnS8j1LZh5vE0HR7q9XEzFRWzrl+bQh7iX4JqJrMNqePIiep+IwooFB3hp2LdHm dlIbY3SxamrO670zaGODD8z+IQzH2wXiWF3GQCsIX8h6trrZH7D3iOmiYJDE2Ibc9IKf gqNjpFTLOoUhZbB2nsZxW3VccklAIIaacmIQRNQTkeHFJaqsVXHT51pjXY8ElwqjzOAP ifow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kotCjzjYQlmP7XO7qEkMQL+5pg4T4SBj3bisS5AShbo=; b=Yb7u4fR/vmFAfzlepxtdkoAv4EZrPcHk+tuZfSV88IsQJ2PPO6VHMeO/4sKKU5fgQY ijfAAI2ab5t0OXl/+7w7OqnuDsffBiQWiZLSDv01qaW+44gNfW2qb7RwdTNjf3Uswv56 MXTv2BZmexsPIPD8MZlW+URgl6MgcAFWDLVtsNEIrQ5kSA4Ay/nrX1kh60voIIqDvQi1 Hmj9ItYGN+sXOsEg+85yF03v1K5HJBCh0aMHYI5o5EoErFA12dPwAVJsytdXSv0tS420 0zURgCscMhPKx3VCGQ7sGEPQ/ihgLaY9QrnwXiO4raw3P9tkNCRxT3zNhhzytVAJ+XCz 8R6A==
X-Gm-Message-State: APjAAAVfRWdtOoH7fyiJdDC11XUJmegj9qtYpjgwwtHR5j4wS82icbT3 CMV8JgL/Eoh1RnpBdmuZl2n6JkzC
X-Google-Smtp-Source: APXvYqyE4UQ3s3KOA4UPNKmXK3UpA0t404laYqMfTl6anJAdu3i5gWtfOPrj5wJRbL2TedbFHOh6Eg==
X-Received: by 2002:a17:902:7e04:: with SMTP id b4mr27190690plm.211.1557700639954;  Sun, 12 May 2019 15:37:19 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id u75sm27936225pfa.138.2019.05.12.15.37.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 15:37:18 -0700 (PDT)
To: Ron Bonica , "v6ops@ietf.org" 
References: 
From: Brian E Carpenter 
Message-ID: 
Date: Mon, 13 May 2019 10:37:15 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [v6ops] draft-gont-6man-slaac-renum
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 May 2019 22:37:23 -0000

Broadly, I support this draft.

I am puzzled however about whether it should be Standards Track or BCP. The core is section 5, which seems like a group of operational recommendations more than specific updates to standards track documents. So I'd be inclined to make it a BCP. Even then, this language is wrong:

> 5.  Possible workarounds
> 
>    The following subsections discuss possible workarounds for the
>    aforementioned problem.

No, these are not possible workarounds. They are formal recommendations.

Section 5.1.1.1. "Router Configuration Variables" changes a timer in 6.2.1. "Router Configuration Variables" of RFC 4861. That section starts out:

>>> A router MUST allow for the following conceptual variables to be
>>> configured by system management.

So there is no need to update 4861 or a conforming implementation of 4861; if the current draft is a BCP it can simply RECOMMEND new timer values.

My bottom line is that this draft would probably go quicker as a v6ops BCP than as a 6man Proposed Standard. But one way or the other, IMHO it should advance ASAP.

Regards
    Brianr

On 07-May-19 02:36, Ron Bonica wrote:
> Folks,
> 
> Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.
> 
> This week, please review and comment on draft-gont-6man-slaac-renum.
> 
>                                                              Fred and Ron
> 
> Non-Juniper
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Mon May 13 06:53:26 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B203C120090 for ; Mon, 13 May 2019 06:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 FmRnvMu--BL9 for ; Mon, 13 May 2019 06:53:23 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.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 D7B9E12006F for ; Mon, 13 May 2019 06:53:22 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4DDncvI011816 for ; Mon, 13 May 2019 06:53:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=yObiQPabsStcMdyL9//0y760xmhHBWETqosAbgIN9h8=; b=bQEMJtvCYkFoUshwBaLRXq6QEoxdhTkVJf50xgmQzUKaR5vmzNcoRdlZ3yrKSq+kodwk uaC/rA9vIRdwMmMFmdrrILC3dcoVtn0R26FnyFal3HjObKO7dJ3VbMuvozXC6jL7rSKd wS+slzQsn7H3nT6mVtw4LXG2qKtIGX2G9F8i7vfr5DAAhP4cA58NKq2ogbr5yB9MettP U6uDr9qTJP/OODlD9LpPFyM/z9uggqQoC/S3naF1nQ3wPlRbHSCas/yKGQFyBKv5skeO hxnn6xLcBz+vBilsXt8lSUQxGNOn2m+WTgh2BaKBjkVFFq5Wqbw1KSPqTVSso0Ra51Y1 5Q== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2057.outbound.protection.outlook.com [104.47.38.57]) by mx0b-00273201.pphosted.com with ESMTP id 2sf4cwrf4g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 13 May 2019 06:53:20 -0700
Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4072.namprd05.prod.outlook.com (52.135.199.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.15; Mon, 13 May 2019 13:53:18 +0000
Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29%7]) with mapi id 15.20.1900.010; Mon, 13 May 2019 13:53:18 +0000
From: Ron Bonica 
To: "v6ops@ietf.org" 
Thread-Topic: draft-ietf-v6ops-nat64-srv 
Thread-Index: AdUJkzCwJVYZ7A9/TA62OccTNtLtgQ==
Content-Class: 
Date: Mon, 13 May 2019 13:53:18 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-05-13T13:53:16.9784346Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 87fb8c5a-19c1-4d36-84dc-08d6d7aa5abf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4072; 
x-ms-traffictypediagnostic: BYAPR05MB4072:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:3826;
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(396003)(376002)(39860400002)(199004)(189003)(2351001)(558084003)(5640700003)(33656002)(9686003)(6306002)(55016002)(71190400001)(71200400001)(256004)(7736002)(53936002)(74316002)(8936002)(102836004)(6506007)(2906002)(26005)(8676002)(81156014)(81166006)(186003)(25786009)(6916009)(68736007)(66476007)(66556008)(64756008)(66446008)(66946007)(73956011)(76116006)(476003)(486006)(14454004)(478600001)(52536014)(4743002)(66066001)(6436002)(99286004)(3846002)(790700001)(6116002)(7696005)(2501003)(316002)(86362001)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4072; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: aOh1owpYy5IcD8vx+rdaFQhhXXYGwn3VngygWZ755kRAk2yR5byROIh6u2o+TOJHlqchv7A3MMDs7uoMMh3tznG5+d/oedJpazzHDosfZoF9SsCISdcC+nt3BKb/S/B4nHM/jRUI6vJP+LDyzsUSoKQSv+wOiRUzIeRR/MP9bO8myuXpRLplKzAiqlO0X9wpeB3GtoGKLaFb88cdzFaOrPlY21Il8sAxaLFxle7938429/zwChTQvHuRdYQDHXRHziAsj556wpuLtQuWX480M5XcOfw/KEU2Da2alacIWyUhKcbIOWnqXpnIKLT6bIiJKef1qdrDbz6X/bqDrf4sqFpKS4p6Wn01WHVd/8uZumnKY8vhsJleVI+N/N378T0MZ6glCgh8ht1ruiFPa6N34WFOCY01yuIu1ETUSaxchIc=
Content-Type: multipart/alternative; boundary="_000_BYAPR05MB4245A78BEC3D7E3622A38395AE0F0BYAPR05MB4245namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 87fb8c5a-19c1-4d36-84dc-08d6d7aa5abf
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 13:53:18.4657 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4072
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-13_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=421 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905130097
Archived-At: 
Subject: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 13:53:25 -0000

--_000_BYAPR05MB4245A78BEC3D7E3622A38395AE0F0BYAPR05MB4245namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,



Each week between now and IETF 105, we will review and discuss one draft wi=
th an eye towards progressing it.



This week, please review and comment on draft-ietf-v6ops-nat64-sr .



                                                             Fred and Ron



Juniper Internal

--_000_BYAPR05MB4245A78BEC3D7E3622A38395AE0F0BYAPR05MB4245namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Folks,


 


Each week between now and IETF 105, we will revie=
w and discuss one draft with an eye towards progressing it.


 


This week, please review and comment on draft-iet=
f-v6ops-nat64-sr .


 


        &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;  Fred and Ron


 




Juniper Interna=
l






--_000_BYAPR05MB4245A78BEC3D7E3622A38395AE0F0BYAPR05MB4245namp_--


From nobody Mon May 13 09:03:33 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D292A1200CD for ; Mon, 13 May 2019 09:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 xE5BHJWMVGOx for ; Mon, 13 May 2019 09:03:30 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 870141200D8 for ; Mon, 13 May 2019 09:03:30 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id n14so5320081otk.2 for ; Mon, 13 May 2019 09:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:to:in-reply-to:message-id;  bh=52Q33/xmlairZk8q2qRAUDII27V2/SUjUrBcDRWtFik=; b=dIH0ug1qE70MyN1cl4vPGUQ07JfkR69cvsoBHDX4PNgUib3DQN0R/zWq/g8BkqpCvK 2xaPu6TZ0O0oOUuvjkJT5VzyOJr+U2GLy9U2dKfgtIhldaLbetvx14i4R/dBqisNOW54 YEaUeJ88hZ6y7C+Ea7+7Q+l+QYHsAVJcJ4sKxzfcWz+DmUc7cBCjrrmsomvT35ZXeIw4 1CFMC4L5gS4r4q4SM+COfE+Yc3xzDMRX66PPAnSiTC4hoso1KxNk48eNfLBGBOcOd3hN 5h06WX9KwjI30RezyEpSaqEH4HS53kCUoz/N306vjrckfrctWgFyd7GCm+tFtOktu2fe jWMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=52Q33/xmlairZk8q2qRAUDII27V2/SUjUrBcDRWtFik=; b=D1GQOyK3CbBUIYCxHU/DUeZ7BNXMG6NnqhzJFy/9d0ijS92q2H/iGwQhtrG8u0GXWt M7Mtgr3pDGu0I1pCmPTwmjui5sCGhYlzn81R8mGTD2jXyrz3Vj9rUPMRJJ9psO4/f+Gd ZZb8L0Oqjt3dq+JayvKhonMRM5jP25q7Al9+59WeOP9i8kmgWpIBMeCNio62aYJ3p3MA dtg7q8xipiXgseclolyBhA2EXUTQ31HpwKpr8R8DhtNvp34YuhK+FBn/sRdFcjtYDGQb HtWYKU+iputUcfs4llWBK8KJYXVnrOVpU8ntSvhmeDmDaSsjfoUdVx3IIuPbkRBOEpxW FA7w==
X-Gm-Message-State: APjAAAXW6Oqj+PCwCAXWgGLpm7zrwb7L5OUIhq6nBcvY2sdPFWq7fiMG eiGv6EDX7EZ5AqvCwTZI3uqTIEz4
X-Google-Smtp-Source: APXvYqz6gOJjDaPPS1w/7h5Ys6YvQZbEVjsBDkjq1qXF+ink2eD545BiuSgzRZ7DBvrTGrLROB8C5Q==
X-Received: by 2002:a05:6830:14c3:: with SMTP id t3mr17058516otq.235.1557763409665;  Mon, 13 May 2019 09:03:29 -0700 (PDT)
Received: from [192.168.1.5] (ip70-185-147-118.sb.sd.cox.net. [70.185.147.118]) by smtp.gmail.com with ESMTPSA id a15sm4400619otl.20.2019.05.13.09.03.28 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 09:03:28 -0700 (PDT)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_C77089FD-E91F-4EFF-983E-BB755376662F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 13 May 2019 09:03:27 -0700
References: 
To: "v6ops@ietf.org" 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 16:03:33 -0000

--Apple-Mail=_C77089FD-E91F-4EFF-983E-BB755376662F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On May 13, 2019, at 6:53 AM, Ron Bonica =
 wrote:
>=20
> Folks,
>=20
> Each week between now and IETF 105, we will review and discuss one =
draft with an eye towards progressing it.
>=20
> This week, please review and comment on draft-ietf-v6ops-nat64-sr .
>=20
>                                                              Fred and =
Ron
>=20

That would be: =
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv
https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv
  "NAT64/DNS64 detection via SRV Records", Martin Hunek, 2019-03-11,

:-)

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

=
--------------------------------------------------------------------------=
------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu


--Apple-Mail=_C77089FD-E91F-4EFF-983E-BB755376662F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlzZlU8ACgkQEhdRnd2G
P+ClGg//YC+NkFBVD1KWE23QVQjswIbNChXIlDD70t/qRjlgbUTBWPPAu8lllwZ0
dCOmjhL9P99XYGP2LEj21REJb2pw5Ubd8u31g/mT1tqcKvjOfDyb5VuxLbwCl3lg
oQbdSEQJNRHRNJrm/0I97/OwpObcnxOPehlWXTs8kteHZlJ+CVc+NAhOn/GTzS7i
8kKzvQkDZl1eWUOe6yMFPAfqMCSKg1QxaDJcHbtj0wi2wJgfsR05kg1vo29oVJNI
E7Ss6D+u97UUZ043Ty0YQIF3TymP+Uhns20sCx7RMo8KggYiSVIC+e1Egm3k54U+
nx7JDZqCpcte+g3msusNHaoe6InZq62Ct5Ms/t6XS60ioK1ti18JzkgJAjPZbwan
j4bZvzzQladuflyMgXlBfX5jy3g+/2GM4zD4mb+7dQLOXDbk1OP63u835ZnMMeG0
yaiVfuZpugll3rajUNZ9LMgOC3fI660mC1R437GQpPVH7R7iEHKPoZtTmS6Gqj1c
0hoe7yX/NPMDU94pyEB4aggjH6CSyPVL7xqJZfvZ5Wd7FdXG+ZQtFwDVjhbufhkg
CWFThQ0cVaaWALIQ9lvIbPk+leVB0CcnaYlDsbTRSrH8YO8jEwtpkV+7U7Ox1FtM
xrW8pA8851ogNHLarZcd5G9akSm27J+lzyvdtPbEB52U/BMyBzs=
=3QrI
-----END PGP SIGNATURE-----

--Apple-Mail=_C77089FD-E91F-4EFF-983E-BB755376662F--


From nobody Mon May 13 10:04:14 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA981201A0 for ; Mon, 13 May 2019 10:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlA4i3uveF9R for ; Mon, 13 May 2019 10:04:10 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E861912019B for ; Mon, 13 May 2019 10:04:09 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B380FB3; Mon, 13 May 2019 19:04:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557767047; bh=CYOQeM7HFq7t/YiOOYNhGxk597VXW6SlWRHquoUJidQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RdqAMG9/Dzr6V1y2x3eUMqnJ/ymZpK9fJIxuokRToyoUgXSbeqRzqYrj3hmiUmwH0 WwjfQ2upryTRocZPk1qPii/hh7dy0wdXpn4CGXg0TuKqgjgEVF7hDX6Kg8p8/TDNob iBgLXbaoeIzB+8xGVkH96fahAng8jOJhf9WHkCnA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B148FB2; Mon, 13 May 2019 19:04:07 +0200 (CEST)
Date: Mon, 13 May 2019 19:04:07 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ron Bonica 
cc: "v6ops@ietf.org" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 17:04:12 -0000

On Mon, 13 May 2019, Ron Bonica wrote:

> This week, please review and comment on draft-ietf-v6ops-nat64-sr .

I'm generally sympathetic to the problem space this draft tries to solve.

I'm struggling a bit with the different states that the device can end up 
in over time, and also if these lookups should only be done at connect 
time, or do they continue frequently in case the operator changes the 
information? Is there a lifetime to them? If not, why?

Think of a device that is connected for months, how are changes performed? 
What triggers a refresh? The word "time" or "life" (as in lifecycle) 
doesn't exist in the draft.

Perhaps the built in TTL in DNS can be used and lookups are done per 
normal DNS procedures and if the information changes then the settings are 
updated accordingly?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon May 13 15:14:49 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0DA12009E for ; Mon, 13 May 2019 15:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level: 
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] 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 iV9QaVyCwVJb for ; Mon, 13 May 2019 15:14:46 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 5F87D12000E for ; Mon, 13 May 2019 15:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from hunator-ntb.local (unknown [IPv6:2001:718:1c01:173:e70b:2ede:d5b4:1f70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 4D045180651E5 for ; Tue, 14 May 2019 00:14:43 +0200 (CEST)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Tue, 14 May 2019 00:14:36 +0200
Message-ID: <129843806.b7yKE7hP11@hunator-ntb.local>
In-Reply-To: 
References:  
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2388614.rnq1y3LAIg"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 22:14:49 -0000

--nextPart2388614.rnq1y3LAIg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi thank you for a review.

Dne pond=C4=9Bl=C3=AD 13. kv=C4=9Btna 2019 19:04:07 CEST, Mikael Abrahamsso=
n napsal(a):
> On Mon, 13 May 2019, Ron Bonica wrote:
> > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
>=20
> I'm generally sympathetic to the problem space this draft tries to solve.
>=20
> I'm struggling a bit with the different states that the device can end up
> in over time, and also if these lookups should only be done at connect
> time, or do they continue frequently in case the operator changes the
> information? Is there a lifetime to them? If not, why?

Sure, the SRV record does have the TTL value after which would had to be=20
renewed. This way it would keep in line with updated settings. It is not=20
explicitly written there, I guess it should be.

Question is if the "local domain" should be renewed as well. I think not du=
e=20
to security precaution (domain could be received for example from unsecured=
 RA=20
so it might be good to wait for expiration), but I would probably let this=
=20
open as the draft doesn't specify domain detection mechanisms.

> Think of a device that is connected for months, how are changes performed?
> What triggers a refresh? The word "time" or "life" (as in lifecycle)
> doesn't exist in the draft.

As above, I would mention it in new version, something like: SRV record in =
use=20
must be valid and kept updated according to its TTL value.
>=20
> Perhaps the built in TTL in DNS can be used and lookups are done per
> normal DNS procedures and if the information changes then the settings are
> updated accordingly?

Yes, that is the idea.

Thanks again for review, I would appreciate any other thoughts.

Regards,
Martin

--nextPart2388614.rnq1y3LAIg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlzZ7EwACgkQtRBl6lEd
5VwHZAf+KF/aU6B1cjQQyByA9jtv1AX1uQQ0opY8OUgkDA46QbeJYPQMkgSc8lbE
6LcRgPaxLHYQVsp/sF2kRVsKPGDCppJ3ENjplmKC4iaUwW0Ylg+tHHSuVN0SQ2XM
us5jEFhsr5JJ0DLFf+TAmOrQQlFWW8ngVtMZvNx9WTpADLx6ipAKK2NCul+pH+J3
JpvFTsN0mXqW7TQhooD7yvojSlHyXlU/yrlGiyBoE9Gda9vjtus9lC9lIiQa+HXB
8M+VDo6v8uUa7tbwJIhv/r5XfSN9BcmvqbNEw6hmdHQt9BHeiFjXpdN5ElRCFnS2
xjm40ejlrvoxLZHbOo364FC9JweALw==
=tNLV
-----END PGP SIGNATURE-----

--nextPart2388614.rnq1y3LAIg--




From nobody Mon May 13 21:49:50 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3B12009C for ; Mon, 13 May 2019 21:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3E7qsxpMsJR for ; Mon, 13 May 2019 21:49:46 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0732C12008A for ; Mon, 13 May 2019 21:49:45 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2B4B8B3; Tue, 14 May 2019 06:49:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1557809382; bh=WWtuphGrhN2sOeiKF4ozziK/9ycUw/4PHLsV5VLhtio=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=s8IpBWHYFYrOxIY4IRJk1NAVeZFl3nSHWQCooJ0IaAlt2FrLwCyyNeQzPtV0Ns+gf 2wZp3+nDhhzenD2wxeLTdVRRRnUJRNnaT137wCpZeeCQYyRwFrlsFSHPsD5zGFrpEF T/BmQgdircq1SlW+u2EnvxcA43Rfs70dGd6dTAOU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 272F7B0; Tue, 14 May 2019 06:49:42 +0200 (CEST)
Date: Tue, 14 May 2019 06:49:42 +0200 (CEST)
From: Mikael Abrahamsson 
To: =?ISO-8859-2?Q?Martin_Hun=ECk?= 
cc: v6ops@ietf.org
In-Reply-To: <129843806.b7yKE7hP11@hunator-ntb.local>
Message-ID: 
References:   <129843806.b7yKE7hP11@hunator-ntb.local>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-695402484-1557809382=:1824"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 04:49:48 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-695402484-1557809382=:1824
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 14 May 2019, Martin Huněk wrote:

> Sure, the SRV record does have the TTL value after which would had to be
> renewed. This way it would keep in line with updated settings. It is not
> explicitly written there, I guess it should be.

I made similar remarks for a different draft, which resulted in the 
following diff to that draft:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-driad-amt-discovery-01.txt

The problem space with AMT tunnels and NAT64/DNS64 usage is of course not 
identical, but there might be something in there that you can take 
inspiration from.

That draft also uses DNS for its discovery mechanism.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-695402484-1557809382=:1824--


From nobody Tue May 14 02:59:47 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7131200F8 for ; Tue, 14 May 2019 02:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Cgr4-Y29HZbJ for ; Tue, 14 May 2019 02:59:43 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D48B120091 for ; Tue, 14 May 2019 02:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1557827980; x=1558432780; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=ku2Eq0mG OyenNEPD6KD3uCHGwTPjWQs1TcvUGsUW03U=; b=H2fa1CYlWnTSoxHJzWwTCv9z YCi5GDY11AuDPogvUUNChJUodQhGNcX1PpvJQFPZ0Hh0G9tG83j6txOGZP+TzSoT y7ExOQq38x+neRO4Cv5gzNvn73ldcVpfR+wQ0z1J0lKuRlSnWBktVYumrJcCCpBn obQ0cnAR41plHjsXJlo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 14 May 2019 11:59:40 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 14 May 2019 11:59:39 +0200
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006245389.msg for ; Tue, 14 May 2019 11:59:39 +0200
X-MDRemoteIP: 2001:470:1f09:495:d82f:857d:4bc2:8955
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Tue, 14 May 2019 11:59:39 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1037410fe8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.9.190412
Date: Tue, 14 May 2019 11:59:34 +0200
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-srv
References:   <129843806.b7yKE7hP11@hunator-ntb.local>
In-Reply-To: <129843806.b7yKE7hP11@hunator-ntb.local>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 09:59:46 -0000

Hi Martin,

Re-reading this document now, I found a few clarification/nits that I think=
 should be addressed.

1) The document is reusing 192.0.0.170/171, but in the terminology section =
it refers for that to the RFC6052, while those addresses where actually def=
ined by RFC7050.

2) Same for the definition of WKA.

3) Intro: This document specifies ... the way of ... / a mechanism for.  As=
 this is not the only way (the/a). You use the same expression in several p=
arts of the document.

4) I think you need to also consider, in addition to DNS over HTTPS, DNS ov=
er TLS, over DTLS and DOQ.

5) local area network or station. Not sure what it means "station" here.

6) The one for NAT64 prefix which validation end node MUST implement / end-=
nodes? Actually I think you should use end-nodes across all the document, b=
ut others may disagree here.

7) Server provided / Servers provided

8) In early stage / In the initial stage ?

9) Method of obtaining such information is / The method to obtain ...

10) but it might contain ... / but some possible choices are ...

11) MUST ask / MUST query

12) do have a same values of / do have equal values of ?

13) is not capable of record synthesis / is not capable to perform AAAA rec=
ord synthesis

14) Method proposed / The method proposed

Further to that, it looks to me that the port definition should be better d=
efined in section 3, either as 0 or prefix length (I will not say mask, bec=
ause in IPv6 it doesn't exist).

I think it may be interesting to have a section stating why this method is =
better than others, pros/cons, etc. May be update RFC7051?

Last but not least, I will suggest a grammar/orthography pass. I'm not nati=
ve English, so probably not the best to do it, but I spotted (some of them =
repeated in several parts of the document):

a) asignment / assignment
b) diferent / different
c) decadicaly / ?
d) graylist / gray-list ? same for other similar words
e) A such pool / Such pool ?
f) For example when ISP / For example, when an ISP

Regards,
Jordi
=20
=20

=EF=BB=BFEl 14/5/19 0:15, "v6ops en nombre de Martin Hun=C4=9Bk"  escribi=C3=B3:

    Hi thank you for a review.
   =20
    Dne pond=C4=9Bl=C3=AD 13. kv=C4=9Btna 2019 19:04:07 CEST, Mikael Abraha=
msson napsal(a):
    > On Mon, 13 May 2019, Ron Bonica wrote:
    > > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
    >=20
    > I'm generally sympathetic to the problem space this draft tries to so=
lve.
    >=20
    > I'm struggling a bit with the different states that the device can en=
d up
    > in over time, and also if these lookups should only be done at connec=
t
    > time, or do they continue frequently in case the operator changes the
    > information? Is there a lifetime to them? If not, why?
   =20
    Sure, the SRV record does have the TTL value after which would had to b=
e=20
    renewed. This way it would keep in line with updated settings. It is no=
t=20
    explicitly written there, I guess it should be.
   =20
    Question is if the "local domain" should be renewed as well. I think no=
t due=20
    to security precaution (domain could be received for example from unsec=
ured RA=20
    so it might be good to wait for expiration), but I would probably let t=
his=20
    open as the draft doesn't specify domain detection mechanisms.
   =20
    > Think of a device that is connected for months, how are changes perfo=
rmed?
    > What triggers a refresh? The word "time" or "life" (as in lifecycle)
    > doesn't exist in the draft.
   =20
    As above, I would mention it in new version, something like: SRV record=
 in use=20
    must be valid and kept updated according to its TTL value.
    >=20
    > Perhaps the built in TTL in DNS can be used and lookups are done per
    > normal DNS procedures and if the information changes then the setting=
s are
    > updated accordingly?
   =20
    Yes, that is the idea.
   =20
    Thanks again for review, I would appreciate any other thoughts.
   =20
    Regards,
    Martin
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Tue May 14 04:25:05 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6F12029B for ; Tue, 14 May 2019 04:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level: 
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001] 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 fLCYNgZu9AY8 for ; Tue, 14 May 2019 04:24:57 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D165120294 for ; Tue, 14 May 2019 04:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (eduroam-guest.pslib.cz [195.113.159.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id C64E71867DC00 for ; Tue, 14 May 2019 13:24:52 +0200 (CEST)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Tue, 14 May 2019 13:24:45 +0200
Message-ID: <1612259.PqNLWoFupM@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: 
References:  <129843806.b7yKE7hP11@hunator-ntb.local> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4631607.IJ1L3zjZW3"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 11:25:05 -0000

--nextPart4631607.IJ1L3zjZW3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi Jordi,

thank you for a review, I will try to address those issues and I will try t=
o=20
get someone to look at grammar (I'm bit struggling with it).

A reply inline (when there in none, than I agree with that assessment).

Thanks,
Martin

Dne =C3=BAter=C3=BD 14. kv=C4=9Btna 2019 11:59:34 CEST, JORDI PALET MARTINE=
Z napsal(a):
> Hi Martin,
>=20
> Re-reading this document now, I found a few clarification/nits that I thi=
nk
> should be addressed.
>=20
> 1) The document is reusing 192.0.0.170/171, but in the terminology section
> it refers for that to the RFC6052, while those addresses where actually
> defined by RFC7050.
>=20
> 2) Same for the definition of WKA.
>=20
> 3) Intro: This document specifies ... the way of ... / a mechanism for.  =
As
> this is not the only way (the/a). You use the same expression in several
> parts of the document.
>=20
> 4) I think you need to also consider, in addition to DNS over HTTPS, DNS
> over TLS, over DTLS and DOQ.

DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64 detectio=
n=20
as it allows to use "global" DNS to discover it. Any transport protocol sho=
uld=20
do the trick as long as the records are signed and their signature is valid.

> 5) local area network or station. Not sure what it means "station" here.

device

> 6) The one for NAT64 prefix which validation end node MUST implement /
> end-nodes? Actually I think you should use end-nodes across all the
> document, but others may disagree here.
>=20
> 7) Server provided / Servers provided
>=20
> 8) In early stage / In the initial stage ?
>=20
> 9) Method of obtaining such information is / The method to obtain ...
>=20
> 10) but it might contain ... / but some possible choices are ...
>=20
> 11) MUST ask / MUST query
>=20
> 12) do have a same values of / do have equal values of ?
>=20
> 13) is not capable of record synthesis / is not capable to perform AAAA
> record synthesis
>=20
> 14) Method proposed / The method proposed
>=20
> Further to that, it looks to me that the port definition should be better
> defined in section 3, either as 0 or prefix length (I will not say mask,
> because in IPv6 it doesn't exist).
>=20
> I think it may be interesting to have a section stating why this method is
> better than others, pros/cons, etc. May be update RFC7051?

I wanted to point that out in mailing list rather then in document itself a=
s=20
it might get easily outdated and incomplete. But if you think it should be=
=20
there, than I guess I should add it into document.

> Last but not least, I will suggest a grammar/orthography pass. I'm not
> native English, so probably not the best to do it, but I spotted (some of
> them repeated in several parts of the document):
>=20
> a) asignment / assignment
> b) diferent / different
> c) decadicaly / ?
> d) graylist / gray-list ? same for other similar words
> e) A such pool / Such pool ?
> f) For example when ISP / For example, when an ISP

Will do. And c) should be decimally.

--nextPart4631607.IJ1L3zjZW3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlzapX0ACgkQtRBl6lEd
5Vx5cQgAhGsBMw4sdw71Rfeq0h8tFlG7ySnF90uYjOkUnZsQFv4ru/o+SeB16EvX
mt46jwKmkcRA0HDIZapBXjkCWSpfiNnmOHgGJCf3pZg7EcBD90BOo3eh4sKWwFCD
B36ej+S6ldGzNFduolRkTekTVZwkZErm2b+CkbywlHed2Sz0iNmFBneZcFEod1+P
5jom5mgrT3GU/JJv2l7llOokaq/9DF5qykudeWNZqTlSKBp5MmSE4gPu7zmlNW20
x7eoTEJtXKi0BM+Z93CEsGbpB0x5Tl6NSCNDxGeVHrpOYEi6320pNOW2OEikTXHF
mirrnu5Sw71PQSyoWSM38/04ahzaFA==
=rKJx
-----END PGP SIGNATURE-----

--nextPart4631607.IJ1L3zjZW3--




From nobody Tue May 14 05:11:08 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1E12011D for ; Tue, 14 May 2019 05:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 hw0wdNjnBBwL for ; Tue, 14 May 2019 05:11:04 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830A81200CC for ; Tue, 14 May 2019 05:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1557835860; x=1558440660; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=+G9dtbAR GUONExz+PJ4stq8Q3AFlWo28fElkT4Sf4+s=; b=FYsQXGW9HLBUHLfNZudpUgEd x7HmGSOOFjPdJcXX2tce9qEZK3Uoj5y6q4rjV5ZRqu850BW2TuyZ8sYZ6mJ6zdVf g8lo4xURX1Vyu0+zbmL9/8H3Mmm1htkUyed7OIhuzHs9KerWMzrmsCYP1+GsZdQv r14Kp87nDdCEWO4zGMw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 14 May 2019 14:11:00 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 14 May 2019 14:11:00 +0200
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006245485.msg for ; Tue, 14 May 2019 14:10:59 +0200
X-MDRemoteIP: 2001:470:1f09:495:6818:8398:edfa:2570
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Tue, 14 May 2019 14:10:59 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1037410fe8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.9.190412
Date: Tue, 14 May 2019 14:10:57 +0200
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <75A4A2B3-8A52-408E-B4EC-448C7C185994@consulintel.es>
Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-srv
References:  <129843806.b7yKE7hP11@hunator-ntb.local>  <1612259.PqNLWoFupM@asclepius>
In-Reply-To: <1612259.PqNLWoFupM@asclepius>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 12:11:06 -0000

Hi Martin,

If you use Word or similar, copy and paste your draft txt as a blank new do=
cument, select all the text, then choose English language. It is not proof =
safe 100%, but it may help!

See below in-line.

Regards,
Jordi
=20
=20

=EF=BB=BFEl 14/5/19 13:25, "v6ops en nombre de Martin Hun=C4=9Bk"  escribi=C3=B3:

    Hi Jordi,
   =20
    thank you for a review, I will try to address those issues and I will t=
ry to=20
    get someone to look at grammar (I'm bit struggling with it).
   =20
    A reply inline (when there in none, than I agree with that assessment).
   =20
    Thanks,
    Martin
   =20
    Dne =C3=BAter=C3=BD 14. kv=C4=9Btna 2019 11:59:34 CEST, JORDI PALET MAR=
TINEZ napsal(a):
    > Hi Martin,
    >=20
    > Re-reading this document now, I found a few clarification/nits that I=
 think
    > should be addressed.
    >=20
    > 1) The document is reusing 192.0.0.170/171, but in the terminology se=
ction
    > it refers for that to the RFC6052, while those addresses where actual=
ly
    > defined by RFC7050.
    >=20
    > 2) Same for the definition of WKA.
    >=20
    > 3) Intro: This document specifies ... the way of ... / a mechanism fo=
r.  As
    > this is not the only way (the/a). You use the same expression in seve=
ral
    > parts of the document.
    >=20
    > 4) I think you need to also consider, in addition to DNS over HTTPS, =
DNS
    > over TLS, over DTLS and DOQ.
   =20
    DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64 dete=
ction=20
    as it allows to use "global" DNS to discover it. Any transport protocol=
 should=20
    do the trick as long as the records are signed and their signature is v=
alid.

I don't think so, applications use that bypassing the OS.
   =20
    > 5) local area network or station. Not sure what it means "station" he=
re.
   =20
    device

I will then suggest to use device across the text. Even better "node" or "h=
ost".
   =20
    > 6) The one for NAT64 prefix which validation end node MUST implement =
/
    > end-nodes? Actually I think you should use end-nodes across all the
    > document, but others may disagree here.
    >=20
    > 7) Server provided / Servers provided
    >=20
    > 8) In early stage / In the initial stage ?
    >=20
    > 9) Method of obtaining such information is / The method to obtain ...
    >=20
    > 10) but it might contain ... / but some possible choices are ...
    >=20
    > 11) MUST ask / MUST query
    >=20
    > 12) do have a same values of / do have equal values of ?
    >=20
    > 13) is not capable of record synthesis / is not capable to perform AA=
AA
    > record synthesis
    >=20
    > 14) Method proposed / The method proposed
    >=20
    > Further to that, it looks to me that the port definition should be be=
tter
    > defined in section 3, either as 0 or prefix length (I will not say ma=
sk,
    > because in IPv6 it doesn't exist).
    >=20
    > I think it may be interesting to have a section stating why this meth=
od is
    > better than others, pros/cons, etc. May be update RFC7051?
   =20
    I wanted to point that out in mailing list rather then in document itse=
lf as=20
    it might get easily outdated and incomplete. But if you think it should=
 be=20
    there, than I guess I should add it into document.

I think the document should be self-contained. People that will read it in =
the future, will not read the mailing list, so references should be to the =
right document.
   =20
    > Last but not least, I will suggest a grammar/orthography pass. I'm no=
t
    > native English, so probably not the best to do it, but I spotted (som=
e of
    > them repeated in several parts of the document):
    >=20
    > a) asignment / assignment
    > b) diferent / different
    > c) decadicaly / ?
    > d) graylist / gray-list ? same for other similar words
    > e) A such pool / Such pool ?
    > f) For example when ISP / For example, when an ISP
   =20
    Will do. And c) should be decimally.
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Tue May 14 13:00:05 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A628A120225 for ; Tue, 14 May 2019 13:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3FDuyJonpNIn for ; Tue, 14 May 2019 13:00:01 -0700 (PDT)
Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 8F30C1201FA for ; Tue, 14 May 2019 13:00:01 -0700 (PDT)
Received: by mail-oi1-x244.google.com with SMTP id v2so57002oie.6 for ; Tue, 14 May 2019 13:00:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UA+Ulp1FAsk2zosp4JnSjVxNhv8gsnzbRNSvLzudvGY=; b=fJIu0mrk4VPm0pUjdJ7oEcPSYVa+jJY7x1WZ/0yJVBqIIeOCCc48Y0eTL9Hmc+Mhvu PP1mYaTw1ehbe/nYYK7+nVlA5I2aWMr+aNj5C+BJV/topzJwr3hLS+myzmkMMpAm5QoP tIwXgd6qYecVUFgMOwEekzRgNcr2uxw7ykzAJy8NrGHHJhHlhMfZXYSxKcEpbMnuKbFf 4g/6lvOD5E6ZQ46Cxq4lqogXiCQVDBzShvhlv/hkPBeCxpA9YqDiZDk7At5gfP2K7qYm IUgPOdTDTp+nyaHNDCwKTYXBvrEz39KYH4yYM8Z+mevJya1Xfaa6wjXgNhnqjStGXG6o lYXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UA+Ulp1FAsk2zosp4JnSjVxNhv8gsnzbRNSvLzudvGY=; b=Yqwh8yTbg07pT7KJo8V+udy6FPIfc+ZIJRBnm0x8rdiayGeK83DGJfQJphLTivBzEf Hfgh2KBaiBl+LvdJhH/j71Aceu/zY6zCf6FBpqUXRL7Vtg6LtU0twaxEBYGW8FaH2uHw DLk1I1kn1OADAhIwVAcPgtx0gEIeSZmgMfGpRSOA3nVCE5Ptja9R8xyoTiewUzOBGjGK W9p7gh6//abUJvPMt2l2I197Q0jbYmPWWeDavff4fYHloOMGH4JKy02+zR3t6XA/jwc7 HQZT7AAeGaxawxf/sOjWlFXTZZGgBiCpaZPeSDeh76zOpC33aD+ICTQi0FwTS28tHCVG smqQ==
X-Gm-Message-State: APjAAAXw4SJzVXgna4TAqSGwtYELfAi+Ig5gJqWupBORKC4Cbuq6iMrI C2UUHCBUgFu4FS1aTSGW4n0=
X-Google-Smtp-Source: APXvYqz3uOMFBJeundSmNkqmiuVlL8Nj01Ioq3bQANpu+ugn7BZi2YFkM54XdcqXLxfXlOJzaV7+Tw==
X-Received: by 2002:a05:6808:8e:: with SMTP id s14mr3731449oic.54.1557864000730;  Tue, 14 May 2019 13:00:00 -0700 (PDT)
Received: from ?IPv6:2600:8802:5903:df16::1003? ([2600:8802:5903:df16::1003]) by smtp.gmail.com with ESMTPSA id m14sm6103759oih.6.2019.05.14.12.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 12:59:59 -0700 (PDT)
From: Fred Baker 
Message-Id: <2591269F-380C-416F-A736-2835241E7C14@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C230716D-945A-4AF0-A628-0BBA95A87CB2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 14 May 2019 12:59:58 -0700
In-Reply-To: 
Cc: v6ops@ietf.org
To: JORDI PALET MARTINEZ 
References:   <129843806.b7yKE7hP11@hunator-ntb.local> 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 20:00:05 -0000

--Apple-Mail=_C230716D-945A-4AF0-A628-0BBA95A87CB2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



On May 14, 2019, at 2:59 AM, JORDI PALET MARTINEZ =
 wrote:
>=20
> 3) Intro: This document specifies ... the way of ... / a mechanism =
for.  As this is not the only way (the/a). You use the same expression =
in several parts of the document.

So you are asking him to change "the" to "a"?

> 5) local area network or station. Not sure what it means "station" =
here.

I presume you're referring to the definition of an "end node".

Things that are attached to local area networks are referred to by =
various names. People from a telephony background often call them =
"terminals", for example, and people thinking of mobile telephones or =
things that look/act like them might call them "handsets". People with =
an ISO background might call them "end stations", and people from an =
Internet background might call them "hosts". "Station", which is half of =
"end station", is one of a number of words used in the same vein.

I do find the definition odd; when it is a "resolver" serving a =
"station", I would presume that it is the resolver software in a host, =
the bit of software that gethostbyname() asks for an IP address. That =
said, the *resolver* software is not the "end node"; the chunk of =
software that terminates sessions, which includes at least IP and the =
means by which it communicates with its client (often TCP or UDP, or =
maybe another instance of IP) and its services (a tunnel SNDCF, or a =
driver in most cases), and might possibly include such a resolver, is =
the end node.

> 6) The one for NAT64 prefix which validation end node MUST implement / =
end-nodes? Actually I think you should use end-nodes across all the =
document, but others may disagree here.

I'm not entirely sure what text change you're requesting.


I ran the thing through my spell-checker; it came up with the following =
diff. I wasn't sure what construction was intended by "9632". On =
"graylist", I have seen it as "greylist", "grey-list" and "grey list".

On the mention of an "IPv6 prefix mask" with attached decadic "IPv4 =
prefix mask", you're correct that we don't use prefix masks in IPv6; I =
would go a step further and say we would find the construct distinctly =
unusual. It is probably derived from the "alternative form" mentioned in =
the third bullet of section 2.2 from RFC 4291, but has no counterpart in =
section 2.3, which describes address prefixes. Since IPv4 and IPv6 both =
use CIDR notation, I would suggest simply using CIDR notation: if I have =
a prefix 2001:dba::/96 mashed up with 192.0.5.0/26, I might describe it =
using the IPv6 prefix 2001:dba::c000:500/122.

*** draft-ietf-v6ops-nat64-srv-00.txt	2019-03-11 01:56:27.000000000 =
-0700
--- draft-ietf-v6ops-nat64-srv-00-1.txt	2019-05-14 12:40:30.000000000 =
-0700
***************
*** 11,17 ****
     This document specifies the way of discovering the NAT64 pools in
     use as well as DNS servers providing DNS64 service to the local
     clients. The discovery is done via SRV records, which also allows
!    asignment of priorities to the NAT64 pools as well as DNS64 =
servers.
     It also allows clients to have diferent DNS providers than NAT64
     provider, while providing a secure way via DNSSEC validation of
     provided SRV records. This way, it provides DNS64 service even in
--- 11,17 ----
     This document specifies the way of discovering the NAT64 pools in
     use as well as DNS servers providing DNS64 service to the local
     clients. The discovery is done via SRV records, which also allows
!    assignment of priorities to the NAT64 pools as well as DNS64 =
servers.
     It also allows clients to have diferent DNS providers than NAT64
     provider, while providing a secure way via DNSSEC validation of
     provided SRV records. This way, it provides DNS64 service even in
***************
*** 120,133 ****
     Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
     this field SHOULD be either set to zero, or SHOULD be used to
     indicate length of network prefix mask in both IPv6 and IPv4
!    protocol, used NAT64. In such case the port 16b integer MUST be
     constructed by directly appending IPv4 pool prefix mask after the

  Martin Hunek          Expires September 11, 2019               [Page =
3]


  INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, =
2019

!    IPv6 prefix mask decadicaly. Usually this would mean 9632 stating
     that IPv6 prefix with mask /96 is translated into single IPv4
     address (/32).

--- 120,133 ----
     Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
     this field SHOULD be either set to zero, or SHOULD be used to
     indicate length of network prefix mask in both IPv6 and IPv4
!    protocol, used NAT64. In such case the port 16 bit integer MUST be
     constructed by directly appending IPv4 pool prefix mask after the

  Martin Hunek          Expires September 11, 2019               [Page =
3]


  INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, =
2019

!    IPv6 prefix mask decadically. Usually this would mean ?9632? =
stating
     that IPv6 prefix with mask /96 is translated into single IPv4
     address (/32).




--Apple-Mail=_C230716D-945A-4AF0-A628-0BBA95A87CB2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlzbHj4ACgkQEhdRnd2G
P+CrMRAAvaSJ4FILAsqxptLKTYhhCVMEGzXz40QI+V53yBhrKdo++dK3jmdrredI
E9xXRP2Un3Fz7dvFuc0BLX5t+WdRnffSiRDQVcTFlZvdSnTb35EVGasynBiqZHyA
5Qgf4L2yvnyYSdX+XJwNHCGoVW7VI4vQ0gLIdczhNMjdh3bRuyd/qqb7nTl9jhuL
sE1djGGhQkJRZ1pmoBvO03reBl6WW9jobiOtwx2nKXBGSKgyz8O2nIuaw5l5XASl
oH9J8QTsiBYNv/P8xbW0kzhedB8tFeHdXVj9lFK2dcqVZngMze9NfsGMWMKZdank
XVlqNgZQobbs17vxKpvBEKC0vEONuqMLrl9X6ZtdFUOt7a0V05f8vhEfjyF2L7Vv
8p2cgx+0l6WgvWlIFVal8o+zdr6+VtCXBlVHcWVEcgGF2Tu8g3QSHHanwAPd2fxI
yZzfEQqFyj01yLECuz7lm9O40nHT/eob7D9eTV//jgJ+KQgk7KGOroKVN5CqRVh8
6JJMBLSQ4G6ptaw4WFJ4znTs725TwD95VEdNCzBhEmBU9C9OMG/rnCrKr4OBqXzw
LSocnhk/vefZV6a8olGbjkIoX2pucuaXi7BOKvQR/J59+YsQw7dhOhk8NGSNpmKp
WG8642/lrk6b72vDxp5BZIRjDuaWD23SR/YbT5LEmaK0Aur0qzQ=
=BUNy
-----END PGP SIGNATURE-----

--Apple-Mail=_C230716D-945A-4AF0-A628-0BBA95A87CB2--


From nobody Tue May 14 15:24:07 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551311201AF for ; Tue, 14 May 2019 15:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 7KHgsC1IVALt for ; Tue, 14 May 2019 15:24:01 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8E8120089 for ; Tue, 14 May 2019 15:24:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1557872639; x=1558477439; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=8PiJeyjo La2Npe31Rpi0SkcyiMVmLop8yVSAl1aI75c=; b=mqMQFDpy7nERbe7s2PfstLwh 02+LT1qEeM8qteAwPUo/AjfLIm46kJqvIC6RaemMxv2USyNQZCspBep4WU7muv49 aw4tb9EGbw9tFl6kdk/NAyPnxBMLjqLSfdPKV1d0gmROKElVjNZNNtulRAhGcBo/ USP77LlVQAXUbBMHV2E=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 15 May 2019 00:23:59 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 15 May 2019 00:23:58 +0200
Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006245965.msg for ; Wed, 15 May 2019 00:23:58 +0200
X-MDRemoteIP: 2001:470:1f09:495:3582:29a7:bf66:79a2
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Wed, 15 May 2019 00:23:58 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1037410fe8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.a.190512
Date: Wed, 15 May 2019 00:23:54 +0200
From: JORDI PALET MARTINEZ 
To: Fred Baker , 
Message-ID: <9BCE6717-87BC-4D9A-AC7A-3BB4D2DD70C1@consulintel.es>
Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-srv
References:   <129843806.b7yKE7hP11@hunator-ntb.local>  <2591269F-380C-416F-A736-2835241E7C14@gmail.com>
In-Reply-To: <2591269F-380C-416F-A736-2835241E7C14@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 22:24:05 -0000

Hi Fred, all,


=EF=BB=BFEl 14/5/19 22:00, "v6ops en nombre de Fred Baker"  escribi=C3=B3:

   =20
   =20
    On May 14, 2019, at 2:59 AM, JORDI PALET MARTINEZ  wrote:
    >=20
    > 3) Intro: This document specifies ... the way of ... / a mechanism fo=
r.  As this is not the only way (the/a). You use the same expression in sev=
eral parts of the document.
   =20
    So you are asking him to change "the" to "a"?

I was trying to point out several changes in a single line, that are repeat=
ed (some of them) across the text. Because this is not the only way for the=
 discovery I think it should be "a" instead of "the" and also replace way w=
ith "mechanism":

Actual:
This document specifies the way of discovering the NAT64 pools in

Suggested:
This document specifies a mechanism for discovering the NAT64 pools in
   =20
    > 5) local area network or station. Not sure what it means "station" he=
re.
   =20
    I presume you're referring to the definition of an "end node".

Yeah,  I may be wrong, but in IETF I think we use node or host or device, b=
ut not so much station.

    Things that are attached to local area networks are referred to by vari=
ous names. People from a telephony background often call them "terminals", =
for example, and people thinking of mobile telephones or things that look/a=
ct like them might call them "handsets". People with an ISO background migh=
t call them "end stations", and people from an Internet background might ca=
ll them "hosts". "Station", which is half of "end station", is one of a num=
ber of words used in the same vein.
   =20
    I do find the definition odd; when it is a "resolver" serving a "statio=
n", I would presume that it is the resolver software in a host, the bit of =
software that gethostbyname() asks for an IP address. That said, the *resol=
ver* software is not the "end node"; the chunk of software that terminates =
sessions, which includes at least IP and the means by which it communicates=
 with its client (often TCP or UDP, or maybe another instance of IP) and it=
s services (a tunnel SNDCF, or a driver in most cases), and might possibly =
include such a resolver, is the end node.
   =20
Available instead of "serving" ? anyway, yes, the definition is a bit stran=
ge.

    > 6) The one for NAT64 prefix which validation end node MUST implement =
/ end-nodes? Actually I think you should use end-nodes across all the docum=
ent, but others may disagree here.
   =20
    I'm not entirely sure what text change you're requesting.

"end-nodes" (plural) instead of end node (singular)
   =20
   =20
    I ran the thing through my spell-checker; it came up with the following=
 diff. I wasn't sure what construction was intended by "9632". On "graylist=
", I have seen it as "greylist", "grey-list" and "grey list".

I understood 9632 as 96 bits / 32 bits, using decimal notation.
   =20
    On the mention of an "IPv6 prefix mask" with attached decadic "IPv4 pre=
fix mask", you're correct that we don't use prefix masks in IPv6; I would g=
o a step further and say we would find the construct distinctly unusual. It=
 is probably derived from the "alternative form" mentioned in the third bul=
let of section 2.2 from RFC 4291, but has no counterpart in section 2.3, wh=
ich describes address prefixes. Since IPv4 and IPv6 both use CIDR notation,=
 I would suggest simply using CIDR notation: if I have a prefix 2001:dba::/=
96 mashed up with 192.0.5.0/26, I might describe it using the IPv6 prefix 2=
001:dba::c000:500/122.
   =20
    *** draft-ietf-v6ops-nat64-srv-00.txt	2019-03-11 01:56:27.000000000 -07=
00
    --- draft-ietf-v6ops-nat64-srv-00-1.txt	2019-05-14 12:40:30.000000000 -=
0700
    ***************
    *** 11,17 ****
         This document specifies the way of discovering the NAT64 pools in
         use as well as DNS servers providing DNS64 service to the local
         clients. The discovery is done via SRV records, which also allows
    !    asignment of priorities to the NAT64 pools as well as DNS64 server=
s.
         It also allows clients to have diferent DNS providers than NAT64
         provider, while providing a secure way via DNSSEC validation of
         provided SRV records. This way, it provides DNS64 service even in
    --- 11,17 ----
         This document specifies the way of discovering the NAT64 pools in
         use as well as DNS servers providing DNS64 service to the local
         clients. The discovery is done via SRV records, which also allows
    !    assignment of priorities to the NAT64 pools as well as DNS64 serve=
rs.
         It also allows clients to have diferent DNS providers than NAT64
         provider, while providing a secure way via DNSSEC validation of
         provided SRV records. This way, it provides DNS64 service even in
    ***************
    *** 120,133 ****
         Port: IPv6 as L3 protocol doesn't use port numbers. Because of tha=
t
         this field SHOULD be either set to zero, or SHOULD be used to
         indicate length of network prefix mask in both IPv6 and IPv4
    !    protocol, used NAT64. In such case the port 16b integer MUST be
         constructed by directly appending IPv4 pool prefix mask after the
   =20
      Martin Hunek          Expires September 11, 2019               [Page =
3]
   =20
   =20
      INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 20=
19
   =20
    !    IPv6 prefix mask decadicaly. Usually this would mean 9632 stating
         that IPv6 prefix with mask /96 is translated into single IPv4
         address (/32).
   =20
    --- 120,133 ----
         Port: IPv6 as L3 protocol doesn't use port numbers. Because of tha=
t
         this field SHOULD be either set to zero, or SHOULD be used to
         indicate length of network prefix mask in both IPv6 and IPv4
    !    protocol, used NAT64. In such case the port 16 bit integer MUST be
         constructed by directly appending IPv4 pool prefix mask after the
   =20
      Martin Hunek          Expires September 11, 2019               [Page =
3]
   =20
   =20
      INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 20=
19
   =20
    !    IPv6 prefix mask decadically. Usually this would mean ?9632? stati=
ng
         that IPv6 prefix with mask /96 is translated into single IPv4
         address (/32).
   =20
   =20
   =20
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.




From nobody Tue May 14 15:40:17 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA19120227 for ; Tue, 14 May 2019 15:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, URIBL_BLOCKED=0.001] 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 s4lowk047iQf for ; Tue, 14 May 2019 15:40:12 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 2FBED1201D8 for ; Tue, 14 May 2019 15:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id C02E0180651EA for ; Wed, 15 May 2019 00:40:08 +0200 (CEST)
From: Martin =?utf-8?B?SHVuxJtr?= 
To: v6ops@ietf.org
Date: Wed, 15 May 2019 00:40:02 +0200
Message-ID: <1838337.UxxuEd2et2@asclepius>
Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci
In-Reply-To: <75A4A2B3-8A52-408E-B4EC-448C7C185994@consulintel.es>
References:  <1612259.PqNLWoFupM@asclepius> <75A4A2B3-8A52-408E-B4EC-448C7C185994@consulintel.es>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2119368.hOZkoO4SBg"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 22:40:15 -0000

--nextPart2119368.hOZkoO4SBg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi Jordi,

reply in-line.

Dne =C3=BAter=C3=BD 14. kv=C4=9Btna 2019 14:10:57 CEST, JORDI PALET MARTINE=
Z napsal(a):
> Hi Martin,
>=20
> If you use Word or similar, copy and paste your draft txt as a blank new
> document, select all the text, then choose English language. It is not
> proof safe 100%, but it may help!
>=20
> See below in-line.
>=20
> Regards,
> Jordi
>=20
>=20
>=20
> =EF=BB=BFEl 14/5/19 13:25, "v6ops en nombre de Martin Hun=C4=9Bk"  en nombre de martin.hunek@tul.cz> escribi=C3=B3:
>=20
>     Hi Jordi,
>=20
>     thank you for a review, I will try to address those issues and I will
> try to get someone to look at grammar (I'm bit struggling with it).
>=20
>     A reply inline (when there in none, than I agree with that assessment=
).
>=20
>     Thanks,
>     Martin
>=20
>     Dne =C3=BAter=C3=BD 14. kv=C4=9Btna 2019 11:59:34 CEST, JORDI PALET M=
ARTINEZ napsal(a):
>     > Hi Martin,
>     >=20
>     > Re-reading this document now, I found a few clarification/nits that=
 I
>     > think
>     > should be addressed.
>     >=20
>     > 1) The document is reusing 192.0.0.170/171, but in the terminology
>     > section
>     > it refers for that to the RFC6052, while those addresses where
>     > actually
>     > defined by RFC7050.
>     >=20
>     > 2) Same for the definition of WKA.
>     >=20
>     > 3) Intro: This document specifies ... the way of ... / a mechanism
>     > for.  As
>     > this is not the only way (the/a). You use the same expression in
>     > several
>     > parts of the document.
>     >=20
>     > 4) I think you need to also consider, in addition to DNS over HTTPS,
>     > DNS
>     > over TLS, over DTLS and DOQ.
>=20
>     DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64
> detection as it allows to use "global" DNS to discover it. Any transport
> protocol should do the trick as long as the records are signed and their
> signature is valid.
>=20
> I don't think so, applications use that bypassing the OS.

Sure, but then they act as stub resolver and as such should act according t=
o=20
this document. They are then an end nodes. I'm considering end node to be a=
=20
resolver (DNS over whatever).

>     > 5) local area network or station. Not sure what it means "station"
>     > here.
>=20
>     device
>=20
> I will then suggest to use device across the text. Even better "node" or
> "host".

Think is that end node doesn't have to be a same as host/device. I would=20
consider a web browser using DoH to be a separate end node to the DNS anywa=
y,=20
as we are talking DNS64 anyway.

>     > 6) The one for NAT64 prefix which validation end node MUST implemen=
t /
>     > end-nodes? Actually I think you should use end-nodes across all the
>     > document, but others may disagree here.
>     >=20
>     > 7) Server provided / Servers provided
>     >=20
>     > 8) In early stage / In the initial stage ?
>     >=20
>     > 9) Method of obtaining such information is / The method to obtain .=
=2E.
>     >=20
>     > 10) but it might contain ... / but some possible choices are ...
>     >=20
>     > 11) MUST ask / MUST query
>     >=20
>     > 12) do have a same values of / do have equal values of ?
>     >=20
>     > 13) is not capable of record synthesis / is not capable to perform
>     > AAAA
>     > record synthesis
>     >=20
>     > 14) Method proposed / The method proposed
>     >=20
>     > Further to that, it looks to me that the port definition should be
>     > better
>     > defined in section 3, either as 0 or prefix length (I will not say
>     > mask,
>     > because in IPv6 it doesn't exist).
>     >=20
>     > I think it may be interesting to have a section stating why this
>     > method is
>     > better than others, pros/cons, etc. May be update RFC7051?
>=20
>     I wanted to point that out in mailing list rather then in document
> itself as it might get easily outdated and incomplete. But if you think it
> should be there, than I guess I should add it into document.
>=20
> I think the document should be self-contained. People that will read it in
> the future, will not read the mailing list, so references should be to the
> right document.

=46air enough.

>     > Last but not least, I will suggest a grammar/orthography pass. I'm =
not
>     > native English, so probably not the best to do it, but I spotted (s=
ome
>     > of
>     > them repeated in several parts of the document):
>     >=20
>     > a) asignment / assignment
>     > b) diferent / different
>     > c) decadicaly / ?
>     > d) graylist / gray-list ? same for other similar words
>     > e) A such pool / Such pool ?
>     > f) For example when ISP / For example, when an ISP
>=20
>     Will do. And c) should be decimally.
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
>=20
>=20
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>=20
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--nextPart2119368.hOZkoO4SBg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlzbQ8IACgkQtRBl6lEd
5VxqPgf9GkTee0DoYmdh4HNs0y9KX0YdojgCWNwBQQ5pi0KzfgEeKptqBXnReDAm
0XkOPD99MgVTe4xvd3OBcWgoq9U4qNDBAQQ3kUz/LRk3zSNnUOOkJzu4YjZyn1py
/sBrZfsv+WeTHqQP7VLkTmoeog+EW+CgI8u0DtGU1D8GOZesLClOqwu7gLh+PN9j
p4UJ/NNkHQM5Nv6USqg0LbCGyUbhg+8qwg74co3qLZPvyduVv5BUuKynIXUUarvO
R7EVRLNT2NitgetnC1Oga5JwClbW4d1qn3HQjZosiU7ARFGz1PZIhZWU7vUbWqqm
wQIjVCoWEB+VbXzlPgHJHqFLIyFs1Q==
=Jvw9
-----END PGP SIGNATURE-----

--nextPart2119368.hOZkoO4SBg--




From nobody Tue May 14 18:09:04 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9198120232 for ; Tue, 14 May 2019 18:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level: 
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.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 zPbrYc9ftahf for ; Tue, 14 May 2019 18:08:59 -0700 (PDT)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 9DA04120227 for ; Tue, 14 May 2019 18:08:59 -0700 (PDT)
Received: by mail-it1-x12b.google.com with SMTP id i63so1886344ita.3 for ; Tue, 14 May 2019 18:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=31lO+QjkYHOv8OGG8DkjuFyK535PqCzv28y/z0AFd4Y=; b=GqH/FOXHRrKi5+S1wV0JRrvudDXBBY/MUk9QIAttgZZ/dpLS91KiXRW8EGb3dOFITV YAIlVInagwyk463J6PGiW2C1RvlRRpRRV03dlf/JReskejkyfVPgkW2iSCu9tfXEe7u2 MJzHy3GvY3ih/5uMlkNn+pnSLSYzfoi52Cidw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=31lO+QjkYHOv8OGG8DkjuFyK535PqCzv28y/z0AFd4Y=; b=mo6y4yOKP2OZObem1TH+AocSyEiQJRifilyCYg+AUQvJAgfQRArd9J7gK+ovHq2y27 NW+hOHByT8EuovqmtOgy0CRx+IQclW8gYI99sgS/qTYe/KGka9de3w5wOwI2dod7BCzw twGoUJQOOYTKmdm5Pug7zP6ZiRk+wxcy0q+6L17IukERq6VRuSUI2q8QMmvO2N6W8d/Y gWy1+JQf+rmPgxPQvemSHrIbl3icDn0AAid+OFkvw2zEucrj7EBsh5ZGf6X4Z1l9Gg8d CfAm64V94MjNUsfYJx11FGqzh5G3TL9rxZnsO1ljx7DQa64aDpolvIYqiqX51W7LzFXn cseQ==
X-Gm-Message-State: APjAAAU2y9Q18ipyJ5akj2o1Jo0pxF8Jkjdt1iQqsqZ3IZYujUUos7j2 GCTSmERDRS3cGXBjhuM9PCkQsnOVB0CpENE2pVkGl4EmfIs=
X-Google-Smtp-Source: APXvYqzVLerdmTvHlPT2XFb5EJmjJH3koA6jLfZCUOH4WsKKQuZzpjavY/m4iVw8EoTkf/BNH0B7aTVmpAj79Sqx7x8=
X-Received: by 2002:a05:660c:7cd:: with SMTP id e13mr1057932itl.40.1557882538491;  Tue, 14 May 2019 18:08:58 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
Reply-To: ek@loon.com
From: Erik Kline 
Date: Tue, 14 May 2019 18:08:41 -0700
Message-ID: 
To: Mikael Abrahamsson 
Cc: Ron Bonica , "v6ops@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004f82ab0588e2cb43"
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 01:09:02 -0000

--0000000000004f82ab0588e2cb43
Content-Type: text/plain; charset="UTF-8"

*From: *Mikael Abrahamsson 
*Date: *Mon, 13 May 2019 at 10:04
*To: *Ron Bonica
*Cc: *v6ops@ietf.org

On Mon, 13 May 2019, Ron Bonica wrote:
>
> > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
>
> I'm generally sympathetic to the problem space this draft tries to solve.
>

Really?  I don't see it yet.  I don't foresee any client implementing this
level of complexity -- it doesn't actually buy them anything.

--0000000000004f82ab0588e2cb43
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

From: Mikael Abraham=
sson <swmike@swm.p=
p.se>
Date: Mon, 13 May 2019 at 10:04
=
To: Ron Bonica
Cc: v6ops@ietf.org

On Mon, 13 May 2019, Ron Bonica wrote:



> This week, please review and comment on draft-ietf-v6ops-nat64-sr .


I'm generally sympathetic to the problem space this draft tries to solv=
e.

Really?=C2=A0 I don't see it yet=
.=C2=A0 I don't foresee any client implementing this level of complexit=
y -- it doesn't actually buy them anything.


--0000000000004f82ab0588e2cb43--


From nobody Wed May 15 16:15:53 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9DC1200A2 for ; Wed, 15 May 2019 16:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 NoZwhVu4USBJ for ; Wed, 15 May 2019 16:15:49 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 C8B5C12004C for ; Wed, 15 May 2019 16:15:49 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x4FN8ipK011759 for ; Wed, 15 May 2019 19:15:48 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2sgtu0283k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 May 2019 19:15:48 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x4FNFl8B026231 for ; Wed, 15 May 2019 19:15:47 -0400
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x4FNFhNf026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 15 May 2019 19:15:43 -0400
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 1EC804005C3E for ; Wed, 15 May 2019 23:15:43 +0000 (GMT)
Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30487.vci.att.com (Service) with ESMTPS id 056584005C3B for ; Wed, 15 May 2019 23:15:43 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.11]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Wed, 15 May 2019 19:15:41 -0400
From: "STARK, BARBARA H" 
To: "'IPv6 Operations'" 
Thread-Topic: CTA-2048 Host and Router Profiles for IPv6
Thread-Index: AdULczEICevAl8cqQjCT/VmvsHx09A==
Date: Wed, 15 May 2019 23:15:41 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E18DE3B@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.230.52]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-15_16:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=471 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905150138
Archived-At: 
Subject: [v6ops] CTA-2048 Host and Router Profiles for IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 23:15:52 -0000

Some people at CTA asked me to ask v6ops if anybody thought it would be use=
ful to update their CTA-2048 Host and Router Profiles for IPv6 standard.
Here is a link to it (it's free to download).
https://members.cta.tech/ctaPublicationDetails/?id=3D74db1b64-3c1b-e811-90c=
e-0003ff52b0cd=20

If someone thinks it's useful, are you willing to help update it? Note that=
 it's pretty easy to participate in CTA as an individual and many companies=
 have corporate memberships.
Right now there's not a critical mass of people who are both interested and=
 knowledgeable. In the absence of volunteers to update it, it'll be withdra=
wn as a standard.
It seemed good to check around first with people in other orgs, before with=
drawing it.
Thx,
Barbara


From nobody Wed May 15 16:29:17 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3652C1200C4 for ; Wed, 15 May 2019 16:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7xcZdQ-cKjrw for ; Wed, 15 May 2019 16:29:13 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4AE3B12009C for ; Wed, 15 May 2019 16:29:13 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id h1so567989pgs.2 for ; Wed, 15 May 2019 16:29:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W6m0GgJQVVikkXoF7xYrJjYu2Un66kiZ9AFHxFNMJgg=; b=Lp45DgzcGGnZGsrKMxrvpCnAlV5KejMuxs7vlT2jc3cevp1aUhsTtsYvTfgCynG40s wFtgWOLiB2VRSmZJQfej30SdtHmQ7nnEi2cDuQBm5YqFB9upmEuVesEy1D9DX9wWKHgF 3YBrtB+SdjRQ2nJxOecNZRV+CTRYLekY5+VBWH7v3xktJFe109ngnTCA9P29IcTGp1kO AOhxTQctYLxuZLTZ5Ipckp3ZOjM2+Dw9GfggvA5Xotr5J1chieURAz4zY/cJ7IXwhXua Fi1Rux67/Gi42HQaxtb97g47U0MPed40BqS1E4kyEa3SO3IbGmhhdjg80Tt/gENV+KQQ 23VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W6m0GgJQVVikkXoF7xYrJjYu2Un66kiZ9AFHxFNMJgg=; b=FubQOPqGfSVR8PQo4nCsHXs444SggTKOeA5HjyKiw9j9otBALwmNC/XR1FB7YCL3Wb yNhMZXMR9aLqmZIIpejfdFL5U086LnCspTiHXBdmPyqFiuW0SelCcw4TiDOuvuv9rSk0 tblpDA88aq6LZU3R+PZnCvXfRqCQsPFfENTjNhZ9EngG1LiE15Y1EluoQrOICG0koQGl 6fbdM0kOZTeNo9zsNMBGjb31U+oP0lDqiPYUIFKPtuYKGuWSe5RcUyPrFx+rRe5xdbhk 0XlWr+6VmYvcxOJUqR2jBHTW60zdgA1zPyAhtv2Ul+wLYIe1jVWzOK+plwOScJX+I3MZ z7mA==
X-Gm-Message-State: APjAAAUiRutR4q2tghbKxxqXdjzCZr2Qa8RPm1AwXmSdvrlA12zGkmPP Dr1p15QuRnOX0ELB/rRJ1sbpW/lSXZQ=
X-Google-Smtp-Source: APXvYqy58lE4Bx7OLM7iH2sfOcWFxcFQz6JWNsV+wsZYaROVD43dP65sbAeKtKbKCYr1vB+1nMN/mg==
X-Received: by 2002:a62:386:: with SMTP id 128mr24215345pfd.10.1557962952234;  Wed, 15 May 2019 16:29:12 -0700 (PDT)
Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id y10sm4829804pfm.27.2019.05.15.16.29.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 16:29:11 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Dan Wing 
In-Reply-To: 
Date: Wed, 15 May 2019 16:29:09 -0700
Cc: Mikael Abrahamsson , Ron Bonica , "v6ops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com>
References:   
To: ek@loon.com
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 23:29:15 -0000

On May 14, 2019, at 6:08 PM, Erik Kline  wrote:
> From: Mikael Abrahamsson 
> Date: Mon, 13 May 2019 at 10:04
> To: Ron Bonica
> Cc: v6ops@ietf.org
>=20
> On Mon, 13 May 2019, Ron Bonica wrote:
>=20
> > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
>=20
> I'm generally sympathetic to the problem space this draft tries to =
solve.
>=20
> Really?  I don't see it yet..  I don't foresee any client implementing =
this level of complexity -- it doesn't actually buy them anything.

The part of the I-D that seems useful is the ability to use a =
centralized DNS server (e.g., 1.1.1.1, 8.8.8.8, some might say "DoH") =
which is not participating in the DNS64/NAT64 infrastructure (and thus =
doesn't do the normal DNS64 synthesis) and having the client synthesize =
AAAA.  But RFC7050 already anticipated that need for client synthesis of =
AAAA with its existing support for client-side DNSSEC.  Perhaps a a =
document that described how to elicit an RFC7050 response (that is, =
elicit a synthesized address) and have the client use that information =
when communicating to a centralized DNS server could be helpful.  A =
careful read of RFC7050 should be sufficient to implement that, at least =
that was our intent when we wrote RFC7050 that it would be clear enough =
how the client can do its own synthesis.

I agree with Erik that the NAT64 balancing seems a lot of effort for the =
client with little gain for the client. NAT64 as a technology will =
diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy =
NAT64 solutions is not "where the hockey puck is going", as they say.

-d


From nobody Wed May 15 20:04:32 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060851200DE for ; Wed, 15 May 2019 20:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 9imSFF2xZLCU for ; Wed, 15 May 2019 20:04:25 -0700 (PDT)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 33F9E12029E for ; Wed, 15 May 2019 20:04:25 -0700 (PDT)
Received: from [10.206.214.27] (71.65.214.202.bf.2iij.net [202.214.65.71]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x4G34EBI084006 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 16 May 2019 05:04:21 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host 71.65.214.202.bf.2iij.net [202.214.65.71] claimed to be [10.206.214.27]
To: v6ops@ietf.org
References:    <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com>
From: =?UTF-8?Q?G=c3=a1bor_Lencse?= 
Message-ID: <4ddf3ed2-fe9f-48a9-80ec-e0de7a4e9870@hit.bme.hu>
Date: Thu, 16 May 2019 12:04:09 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=202.214.65.71; helo=[10.206.214.27]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; 
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 03:04:32 -0000

On 5/16/2019 08:29, Dan Wing wrote:

[...]
> I agree with Erik that the NAT64 balancing seems a lot of effort for the client with little gain for the client. NAT64 as a technology will diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy NAT64 solutions is not "where the hockey puck is going", as they say.

I agree that NAT64 should finally diminish, but I don't think that its 
diminishing would be imminent. On the contrary, I expect that it will be 
used for at least a decade or even more.

My student has just finished her BSc final project thesis about 
examining the transition to IPv6 on the basis of available statistics. 
Her conclusion is that the IPv6 transition technologies will remain with 
us for a long time. Some technologies that aimed to help the early 
adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their 
place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.

Therefore, I think it is worth dealing with this draft, which could be a 
useful update to RFC 7050.

Best regards,

Gábor Lencse


From nobody Thu May 16 14:08:26 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FDD120301 for ; Thu, 16 May 2019 14:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ir_tx4R4wne5 for ; Thu, 16 May 2019 14:08:23 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D11F8120148 for ; Thu, 16 May 2019 14:08:23 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id y3so2241212plp.0 for ; Thu, 16 May 2019 14:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M0MQIj4sQIK5xCUngLu6iTQ5Lj6YHSkUDqV+gp7hXBc=; b=mdTfiUg1qPC4VHvoa30H8V+6nBhDnsBq/vmfW8Mx2AtWw9WOevvpXBYi80t8dEGXrl H24f/hxqtCNYq1r9mW3gbNZL2lD/+2O4V1mq6Nlm1ubAM7LnBu1cXBz7BOICTKXiCfKA UO0GvIdqGN/rmokyNrhSrepwQibFUabvu8rRi0LVi4WhpEvyGev1M1P2MY6PAy4tfP0u W7988BgWc4CXhPs9JsdJtGlLS1+A7KFu2W7lOKCvNfazHyWYF5JBBFersLda14eYQFFd T5g5b9MKV5OPT8imjncKq8VHer1XYTT0AHrM74IFQUxUQhj6udI/UiSQSVMcALfOuVSm flHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M0MQIj4sQIK5xCUngLu6iTQ5Lj6YHSkUDqV+gp7hXBc=; b=Wrj1LCNMrgnKzV7Mg4YBNVBkC016VB2y8gMTcx/D82RElfcLieQKe3rrqhUh51QW8k M3yaGPduF8Rm/DcgimS3KjvhC7MXrYYoy44ysxRTFfrsU0z3647hzx52A5tCLWZMrmrD PErvBtFxG8S1jvSW5iufoKISqYcxn5WrodAwjyCu5Os0RW1Jn32pf0Nyt7L/7hSGZ3O8 0dDhMDvKNULYmpfnEyn/f4CVOP6wc0V+5vf9Epp06VanZoGiRdbs/npsVlXHn+zccfDV WwB41nLgVhtw3+gf9WZNlmPCV+Du6cWR9ZQOFvKYo1cUlXJ1fCX2dD9faIj+EwZHcNqy wb+w==
X-Gm-Message-State: APjAAAUfAlQJmT1z9GgFvuNKDfGOZ9spoiGoyDdAm72PCL0//p4x6khf K3j9HA3BVHhFg+dB9BhkuJc=
X-Google-Smtp-Source: APXvYqxnY5HrNNxkbMUSDdWjVs8dWFVNlL3FEf7DQJH/o2a2hUEQXYvJ78vrST68adQ6kHCoMfx3/A==
X-Received: by 2002:a17:902:4503:: with SMTP id m3mr51934848pld.97.1558040903139;  Thu, 16 May 2019 14:08:23 -0700 (PDT)
Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id u123sm12920991pfu.67.2019.05.16.14.08.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:08:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Dan Wing 
In-Reply-To: <4ddf3ed2-fe9f-48a9-80ec-e0de7a4e9870@hit.bme.hu>
Date: Thu, 16 May 2019 14:08:21 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <9520F111-F282-4B9A-8D50-BDF37793F8B9@gmail.com> <4ddf3ed2-fe9f-48a9-80ec-e0de7a4e9870@hit.bme.hu>
To: =?utf-8?Q?G=C3=A1bor_Lencse?= 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 21:08:25 -0000

On May 15, 2019, at 8:04 PM, G=C3=A1bor Lencse  =
wrote:
> On 5/16/2019 08:29, Dan Wing wrote:
>=20
> [...]
>> I agree with Erik that the NAT64 balancing seems a lot of effort for =
the client with little gain for the client. NAT64 as a technology will =
diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy =
NAT64 solutions is not "where the hockey puck is going", as they say.
>=20
> I agree that NAT64 should finally diminish, but I don't think that its =
diminishing would be imminent. On the contrary, I expect that it will be =
used for at least a decade or even more.
>=20
> My student has just finished her BSc final project thesis about =
examining the transition to IPv6 on the basis of available statistics. =
Her conclusion is that the IPv6 transition technologies will remain with =
us for a long time. Some technologies that aimed to help the early =
adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their =
place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.
>=20
> Therefore, I think it is worth dealing with this draft, which could be =
a useful update to RFC 7050.

Any feedback on my other comments?  As an example, today, we don't have =
a way for client systems to chose outgoing IPv4 gateways (routers) or =
outgoing IPv4 NATs.  Well, we don't have a way that works.  The =
NAT64-SRV document assumes some sort of unstated relationship between =
IPv4 routing and DNS names, but I couldn't understand the assumed =
relatinoship (e.g., is all of example.com's IPv4 space always accessible =
behind a specific NAT64, and if it isn't, how is that expressed.  A =
concrete example is Apple's 17.0.0.0/8 allocation which has a couple of =
subnets publicly routable, and I struggle how a NAT64 operated within =
Apple's network with NAT64-SRV would be configured with SRV records and =
how the client does all the stuff it needs to do.  Naturally, not all =
clients will support NAT64-SRV so I guess the answer is NAT64-SRV-aware =
clients "work better", but all clients will work (somewhat worse, I =
presume with less-performant paths).

-d


From nobody Fri May 17 01:17:34 2019
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCA612034A for ; Fri, 17 May 2019 01:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX3N4K540iXO for ; Fri, 17 May 2019 01:17:31 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B894120348 for ; Fri, 17 May 2019 01:17:31 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8FF6AB5; Fri, 17 May 2019 10:17:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1558081047; bh=UDZ2ZdLS35C++ajZFKUdJKKDh2gqGBD6BNIRNI+TQJI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Nd0RhTtprG7XgljUpCeVWpq5Zfk/I7Fdxr/k1FUxF+IfI4NlawDnl2oMcJJZ5uhC8 6VCW8vcfS3Iw7fzoPbNI/MNItCXW6MDaopPnX6yfQoILoLPOQNCMTvThxfq35ACTiD 6HP0qT8+gTZgHUO/rrGE+8hduHvbqga9NcDnNKl0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DEB1B3; Fri, 17 May 2019 10:17:27 +0200 (CEST)
Date: Fri, 17 May 2019 10:17:27 +0200 (CEST)
From: Mikael Abrahamsson 
To: Erik Kline 
cc: Ron Bonica ,  "v6ops@ietf.org" 
In-Reply-To: 
Message-ID: 
References:   
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 08:17:33 -0000

On Tue, 14 May 2019, Erik Kline wrote:

> Really?  I don't see it yet.  I don't foresee any client implementing 
> this level of complexity -- it doesn't actually buy them anything.

I'd like the client to be aware of the fact that it is or isn't behind a 
DNS64 resolver and potentially understand that it has access to both 
types. If the device decides it has dual stack connectivity it can opt to 
not use the DNS64 resolver if it so chooses.

I ran into problems with this when I was involved in rolling out IPv6 in 
mobile, it was hard to decide whether to use DNS64 or not, for which 
clients etc.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se