From nobody Mon Jun 5 09:29:13 2017 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 81F4A129B52 for ; Mon, 5 Jun 2017 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 xqRkPEO05IdB for ; Mon, 5 Jun 2017 09:29:11 -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 179ED129B43 for ; Mon, 5 Jun 2017 09:29:11 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v55GPtCt011426 for ; Mon, 5 Jun 2017 12:29:10 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2aw7khp1m3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Jun 2017 12:29:10 -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 v55GT8X8014354 for ; Mon, 5 Jun 2017 12:29:09 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v55GT3xF014288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 5 Jun 2017 12:29:05 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor) for ; Mon, 5 Jun 2017 16:28:51 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.82]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Mon, 5 Jun 2017 12:28:51 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: comments on draft-ietf-v6ops-rfc7084-bis-02 Thread-Index: AdLeE2Cc8RMV17LEQdK5y4qf5zFJhg== Date: Mon, 5 Jun 2017 16:28:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-05_09:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706050310 Archived-At: Subject: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:29:12 -0000 I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my comments. General: While I support providing CE router vendors with information on IP= v6 transition technologies, I think that an RFC7084-bis is not the right wa= y to do this, and this particular draft tries to do more than just add thos= e transition technologies; some of these additional items I don't support. = I think this draft weakens RFC7084 by adding such a lengthy list of transit= ion technologies and adding other requirements and text that are not broadl= y useful. I would prefer a stand-alone document that described just the tra= nsition technologies. Specific comments: 3. Usage scenarios I don't find this new and very lengthy section to be more useful than the e= xisting simple statement of "This document defines basic IPv6 features for = a residential or small-office router". I question the need to expand the or= iginal simple sentence into this lengthy section (6 bullets and 8 paragraph= s). I don't understand what "exporting IPv6 services" means. I don't understand= why discussion of IPv4 NAT configuration is particularly relevant as part = of preamble discussion for the requirements in this draft. 5.1 General Requirements, G-5 I don't understand what additional functionality G-5 provides that was not = covered by G-4. G-5 seems redundant. 5.5. IPv4 Multicast Support I disagree with recommending this functionality in all CE Routers. It is ve= ry definitely not necessary in a basic CE router.=20 8. ANNEX A: Code Considerations I disagree with much of the editorializing and assumptions made in this sec= tion and would prefer to see this section removed. Every CE Router vendor (= and ISP) must decide for themselves whether using open source code is appro= priate for them. Licenses must be carefully examined, as some license can b= e very problematic for vendors and for ISPs that ship the vendor's products= . Claiming that existence of open source code means cost of developing code= is negligible ["negligent" is probably not the intended word] is unsubstan= tiated and therefore inappropriate. Claiming that "only integration and tes= ting cost may become a minor issue" is also inaccurate and inappropriate. T= he more code a CE router has, the more testing that has to be done, and thi= s cannot be assumed to be minor. It also creates usability and support issu= es, if the functionality is presented via the UI. Every additional feature = adds cost to these very low margin devices. Barbara From nobody Mon Jun 5 16:38:12 2017 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 CAB42129B48; Mon, 5 Jun 2017 16:38:10 -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.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149670589074.3841.10812713591494006570@ietfa.amsl.com> Date: Mon, 05 Jun 2017 16:38:10 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 23:38:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-01.txt Pages : 13 Date : 2017-06-05 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 5 17:11:05 2017 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 F1C58126B72 for ; Mon, 5 Jun 2017 17:11:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3V1cuEtX0io for ; Mon, 5 Jun 2017 17:11:02 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 6367212E053 for ; Mon, 5 Jun 2017 17:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496707862; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ARKZCExy+D9Q3/M5wYnykeXzi68l+hAx/irsWBYVU1g=; b=BXDht4xJPQLDu9JwPXzsNCwjW9gXX54rIb/g1xJnOAtUYb7OepjG1vzcF4VP7RHL 0ByULQsVR9gkqq8fsSWfU6uTCtHQVqvczpI6o6xbfmdNFcQCD9hNI0fBIT++wb+J 0HmJiA9FLEyc021Sd0BaUUw/c7JVXu8O23vAUkL3BKFsdNgVySnjkHYSXULmyp05 sghSngwZugLCR1Phr6hnjxIplC/OpvcUC14YJOAMSsbH5mLJliqI76U/19XUcysm Qc/2e3lpWGDhtuQKqGEY0YD/ahxmtzSUa9o45hzLUveFeGf7/mYuY9D+AlK2299J N/03Wjh8gmEKd6i2U2SJ5Q==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 6A.46.01595.513F5395; Mon, 5 Jun 2017 17:11:02 -0700 (PDT) X-AuditID: 11973e13-caa429a00000063b-a7-5935f3168003 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay7.apple.com (Apple SCV relay) with SMTP id 76.4A.18088.313F5395; Mon, 5 Jun 2017 17:10:59 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KHGqR2wbdEaLACKA81gzxw)" Received: from [17.153.86.105] (unknown [17.153.86.105]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OR3008MXN67YT90@jimbu.apple.com> for v6ops@ietf.org; Mon, 05 Jun 2017 17:10:59 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> To: IPv6 Ops WG Date: Mon, 05 Jun 2017 17:10:55 -0700 X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYqiv22TTS4OsmVovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8XuNUwFs4wqZl7ax9jAeEm7i5GTQ0LAROLiwRlMXYxcHEIC a5gktk9dxwKTWLl5LiuILSSwjFFiRSMXiM0rICjxY/I9sBpmgTCJD+3PoJonMUk0Tv3JBpIQ FpCW6LpwF6iZg4NNQEviwBojiLCVxNo7vawQc2wk7u2+AjXfWeL/prvMILaIgILEjv87mUBs FgFVifPLJjBC3CMrcWv2JWaQXRICc9gkPj7bwjaBUWAWkptmIbkJwtaS+P6oFSjOAWTLSxw8 LwsR1pR4du8TO4StLfHk3QXWBYxsqxiFchMzc3Qz80z1EgsKclL1kvNzNzGCgni6nfAOxtOr rA4xCnAwKvHw3ogxjRRiTSwrrsw9xCjNwaIkznvjoVGkkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBkYxnea8CueDE45xr9ngoKGjuVauuZfhROdR61tr7Eu74iP+eLxKZl3E9yHsiV+V/qOt DJPvVe19/mL2zzeMOw5aL3hvuXhtu+sMjeU87rdrNzvduDprx/KvHltc7lY+meYgwNyqu0JV 0GV9okv8FUN1JhHzBoHeOctXndnkaB7JW8LBxm+S+keJpTgj0VCLuag4EQCXejOhQwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUiON1OVVf4s2mkwYmLshanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxorda5gKZhlVzLy0j7GB8ZJ2FyMnh4SAicTKzXNZQWwhgWWM EisauUBsXgFBiR+T77GA2MwCYRIf2p8xdTFyAdVMYpJonPqTDSQhLCAt0XXhLlAzBwebgJbE gTVGEGEribV3elkh5thI3Nt9BWq+s8T/TXeZQWwRAQWJHf93MoHYLAKqEueXTWCEuEdW4tbs S8wTGHlnITljFpIzIGwtie+PWoHiHEC2vMTB87IQYU2JZ/c+sUPY2hJP3l1gXcDItopRoCg1 J7HSXC+xoCAnVS85P3cTIyjoGgpTdzA2Lrc6xCjAwajEw9sQZRopxJpYVlyZe4hRgoNZSYSX cS9QiDclsbIqtSg/vqg0J7X4EONERqCjJzJLiSbnA2MiryTe0MTEwMTY2MzY2NzEnJbCSuK8 ZvuNIoUE0hNLUrNTUwtSi2COYuLglGpg7JXeJimue9rM81//A88zC+2mn26oc3/RP1es+E5Q ZAyrmnFZ6//dmxK6Wpnvii7oO+Z2W3TzS9XSV4sWJj3f0nVI/RHr9wOdZzIDy95KlLkcuZNs +8Hzib/ArcNdaloCnhG/a02ufluaqN77xq4yXiG9KKH/4sb+LUy3KuZ6ZQpKrfhypPucEktx RqKhFnNRcSIAY8j6660CAAA= Archived-At: Subject: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 00:11:04 -0000 --Boundary_(ID_KHGqR2wbdEaLACKA81gzxw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi v6ops, We have updated draft-ietf-v6ops-rfc6555bis to version 01. https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 This version incorporates feedback we received on the previous version, and adds a new section on "Supporting IPv6-only Networks with NAT64 and DNS64" as these technologies require changes in the Happy Eyeballs stack on devices that do not support 464XLAT. Please let us know what you think! Thanks, David Schinazi > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations of the IETF. > > Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency > Authors : David Schinazi > Tommy Pauly > Filename : draft-ietf-v6ops-rfc6555bis-01.txt > Pages : 13 > Date : 2017-06-05 > > Abstract: > Many communication protocols operated over the modern Internet use > host names. These often resolve to multiple IP addresses, each of > which may have different performance and connectivity > characteristics. Since specific addresses or address families (IPv4 > or IPv6) may be blocked, broken, or sub-optimal on a network, clients > that attempt multiple connections in parallel have a higher chance of > establishing a connection sooner. This document specifies > requirements for algorithms that reduce this user-visible delay and > provides an example algorithm. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-01 --Boundary_(ID_KHGqR2wbdEaLACKA81gzxw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi v6ops,

We have updated draft-ietf-v6ops-rfc6555bis to version = 01.
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01<= /div>

This version = incorporates feedback we received on the previous version,
and adds a new section on "Supporting IPv6-only Networks with = NAT64 and DNS64"
as these technologies require = changes in the Happy Eyeballs stack
on devices that = do not support 464XLAT.

Please let us know what you think!

Thanks,
David = Schinazi


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

=        Title =           : Happy = Eyeballs Version 2: Better Connectivity Using Concurrency
=        Authors =         : David Schinazi
=             &n= bsp;           &nbs= p;Tommy Pauly
Filename =        : = draft-ietf-v6ops-rfc6555bis-01.txt
Pages =           : 13
= Date =            : = 2017-06-05

Abstract:
=   Many communication protocols operated over the modern = Internet use
  host names.  These often = resolve to multiple IP addresses, each of
=   which may have different performance and connectivity
  characteristics.  Since specific addresses = or address families (IPv4
  or IPv6) may be = blocked, broken, or sub-optimal on a network, clients
=   that attempt multiple connections in parallel have a higher = chance of
  establishing a connection sooner. =  This document specifies
  requirements = for algorithms that reduce this user-visible delay and
=   provides an example algorithm.


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

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555b= is-01

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis= -01
= --Boundary_(ID_KHGqR2wbdEaLACKA81gzxw)-- From nobody Mon Jun 5 22:06:21 2017 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 4A4571201F8 for ; Mon, 5 Jun 2017 22:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ZKZyGT_f_eQc for ; Mon, 5 Jun 2017 22:06:06 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 BEEFC1294A6 for ; Mon, 5 Jun 2017 22:06:06 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=42174 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dI6gu-0005g2-FF; Tue, 06 Jun 2017 05:06:04 +0000 Date: Tue, 6 Jun 2017 07:06:03 +0200 From: Tore Anderson To: "STARK, BARBARA H" Cc: "v6ops@ietf.org" Message-ID: <20170606070603.0557f0a8@echo.ms.redpill-linpro.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 05:06:20 -0000 * "STARK, BARBARA H" > I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my > comments. > > General: While I support providing CE router vendors with information > on IPv6 transition technologies, I think that an RFC7084-bis is not > the right way to do this, and this particular draft tries to do more > than just add those transition technologies; some of these additional > items I don't support. I think this draft weakens RFC7084 by adding > such a lengthy list of transition technologies and adding other > requirements and text that are not broadly useful. I would prefer a > stand-alone document that described just the transition technologies. I wholeheartedly agree. Tore From nobody Mon Jun 5 23:47:30 2017 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 AF652126B6E for ; Mon, 5 Jun 2017 23:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpfuwWORCjVv for ; Mon, 5 Jun 2017 23:47:27 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F11200CF for ; Mon, 5 Jun 2017 23:47:26 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 06 Jun 2017 06:47:26 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3BB80D788B; Mon, 5 Jun 2017 23:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=YeVnc2NDzkKzMfOjTPjkRCKhwIk=; b= IjkDykeZyWVtxe2Ka4L35Ue8lQNAv2uWOCnwD0zXPU/zFEFeDlp017HeeuPr/rgU /WCteyeN81Zmt+eXR1AVxEhP4cRKfwQJgDkEzafjtop3V9jU3S3lzF1OceRuMWKf 5C6V6Pm8c1afOFqUrcho6uE/iG1xoFpkj4Tmw2XdAuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=MaHNjsHCtpqEm1nDpwqwPme od1JYObSr7Z4y9T+g520B7o1U1RcfnY+M5FBdDWw2bRTjsKiqnKESvRWhyZ19+ao 9twly68Jk2b92ROz/C+kwEYkQwmcnIZ2v/F7lOnIKzIgc1Ox7Zt8pBY8FS8ezZtR YmDAYIez/4BS78uNCblY= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BBE4CD788A; Mon, 5 Jun 2017 23:47:25 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DEBF7CCDF8C1; Tue, 6 Jun 2017 08:47:41 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F5C70508-A9B3-40B9-A31E-DFE0B45F1307"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 6 Jun 2017 08:47:40 +0200 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "v6ops@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 06:47:29 -0000 --Apple-Mail=_F5C70508-A9B3-40B9-A31E-DFE0B45F1307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What Barbara said. A good start would be to put these requirements in its own document. Ole > On 5 Jun 2017, at 18:28, STARK, BARBARA H wrote: >=20 > I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my = comments. >=20 > General: While I support providing CE router vendors with information = on IPv6 transition technologies, I think that an RFC7084-bis is not the = right way to do this, and this particular draft tries to do more than = just add those transition technologies; some of these additional items I = don't support. I think this draft weakens RFC7084 by adding such a = lengthy list of transition technologies and adding other requirements = and text that are not broadly useful. I would prefer a stand-alone = document that described just the transition technologies. >=20 > Specific comments: > 3. Usage scenarios > I don't find this new and very lengthy section to be more useful than = the existing simple statement of "This document defines basic IPv6 = features for a residential or small-office router". I question the need = to expand the original simple sentence into this lengthy section (6 = bullets and 8 paragraphs). > I don't understand what "exporting IPv6 services" means. I don't = understand why discussion of IPv4 NAT configuration is particularly = relevant as part of preamble discussion for the requirements in this = draft. >=20 > 5.1 General Requirements, G-5 > I don't understand what additional functionality G-5 provides that was = not covered by G-4. G-5 seems redundant. >=20 > 5.5. IPv4 Multicast Support > I disagree with recommending this functionality in all CE Routers. It = is very definitely not necessary in a basic CE router. >=20 > 8. ANNEX A: Code Considerations > I disagree with much of the editorializing and assumptions made in = this section and would prefer to see this section removed. Every CE = Router vendor (and ISP) must decide for themselves whether using open = source code is appropriate for them. Licenses must be carefully = examined, as some license can be very problematic for vendors and for = ISPs that ship the vendor's products. Claiming that existence of open = source code means cost of developing code is negligible ["negligent" is = probably not the intended word] is unsubstantiated and therefore = inappropriate. Claiming that "only integration and testing cost may = become a minor issue" is also inaccurate and inappropriate. The more = code a CE router has, the more testing that has to be done, and this = cannot be assumed to be minor. It also creates usability and support = issues, if the functionality is presented via the UI. Every additional = feature adds cost to these very low margin devices. >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F5C70508-A9B3-40B9-A31E-DFE0B45F1307 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZNlANAAoJEL7aWKiYQt92ecMQAKj4b1qfnrnM2S0phWNK3LWO gA5Yh3QqdkNTNJOewJbRCQY2ht4UKZvhBdF5hjPjEGDy87rQKtFQzEIgWppJHz8L 2ylG3vv440omfXBg4YF9kSXOLTlOXasleRKHzXo7VmZ6fX/MgwQfRkGdD5YnVUJu BKkoq4kpGJ6uyGjRsd0HHvsJRinL8YAvdgqqWipmBeTnxSvin88MFMBVNLums+gv ZZBoQ+NKgT8PB0YWgZO3thdKqkNzYMYqhb4bLScPYNmP937g6mpc/464ST5oMMLI GTzepW5BxlRJIJsLx/RmMQZGK/73XM5qcMQxCAyT7PWaEymexyoLoa/T9zhPETFW igTE9OGWdJKlwoyAr3GBap/P6Vdacb+DbpgWQjPp46d3mKqmVfusxLeZj9kjOryI HAnfgqkZasKoz1iEFR99lm84yo89l02MSLOh0fQh0OX5lGxlna72wcC9OAgfGghT OMyd3Svh+ZSoS5VjlKaOicPyJcWkM1wV8lSq9RBWzEaEWZF/ZPumXQXUWiTq9gt7 EALUapVfS8fagxbV3ZeApBfHic3CE1omAdvRVp8Dny0hPsum/gqXatBz2zoEQV1D 0SJxXQW+V7LfFC6fepmtIAOGX5uHispRJsYfBbKstrZ9yU1WKPjNoFiMQU3bunT+ v0lsZ5zG/elafXCpZKxE =sliE -----END PGP SIGNATURE----- --Apple-Mail=_F5C70508-A9B3-40B9-A31E-DFE0B45F1307-- From nobody Tue Jun 6 00:22:05 2017 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 1935E129C1A for ; Tue, 6 Jun 2017 00:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 dXK-0fAtSUq5 for ; Tue, 6 Jun 2017 00:22:02 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 A42CC126B6E for ; Tue, 6 Jun 2017 00:22:02 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=44532 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dI8oS-0005tj-IT; Tue, 06 Jun 2017 07:22:00 +0000 Date: Tue, 6 Jun 2017 09:22:00 +0200 From: Tore Anderson To: "STARK, BARBARA H" Cc: "v6ops@ietf.org" Message-ID: <20170606092200.09d78a7c@echo.ms.redpill-linpro.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB80609@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 07:22:04 -0000 * "STARK, BARBARA H" > 5.1 General Requirements, G-5 > I don't understand what additional functionality G-5 provides that > was not covered by G-4. G-5 seems redundant. G-4 only requires the CE router to set the Router Lifetime to 0 in any RAs it originates. A significant amount of time might elapse between the loss of the WAN connectivity and the transmission of the next periodic unsolicited RA. During this time, the IPv6 CE router would attract and blackhole IPv6 traffic. The key word in G-5 is =C2=ABimmediately=C2=BB. This ensures the hosts are notified as soon as possible that the IPv6 CE router is no longer able to provide access to the IPv6 Internet, allowing them to fail over to other IPv6 routers and/or IPv4 in a much more graceful manner. Tore From nobody Tue Jun 6 12:34:03 2017 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 641D01294EF for ; Tue, 6 Jun 2017 12:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-JrlM9bDEKj for ; Tue, 6 Jun 2017 12:34:00 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EAF1252BA for ; Tue, 6 Jun 2017 12:33:59 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id d73so55665821wma.0 for ; Tue, 06 Jun 2017 12:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=P6RGlfqgNThLV/23FrYS1r39Nnf0hk8JXo5hhyM5foU=; b=fvjqEbqL1ZidkoPptuyzUihgAbiSkuYV8MaBzOgnzrwLSahmP83Lt92lEHLGe9mZ9j ioTLwVSXpwOg8yX0dJuhtH8J33XSw8EGOi/fKgU2kNWZW5oRq9cWL985WtjkoiWkCwlV Ezb6eRjum1qo64rLHfApts/rYQazuConqARzPe2xGqcpu4Gc6BrawJI12/7SRoBLEJFF J863//VVNHfgjSXY/nk4Q1/cz3eK+ZewPYQAvSbtf0SvmlkZY8FcG3N2b+K0Km3wKN+4 VzvQwknlL1FQGaNkJj8m8XqnTYGbQU0iRQGIWU36nzmMTCPOpWpyaVa0o63jwEuSoHKI J58w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=P6RGlfqgNThLV/23FrYS1r39Nnf0hk8JXo5hhyM5foU=; b=WjGkLKmCaH1M0jKDtWrjezEFQpWem97hDwWieh0YEKHyyw0qyGpqVbJEWUpSnHUepV xaScCz2kqiD2wTDf1Q+ogzowAhSB1dG68Q3eIZem3WNWX25vma3OCp/WwLnC9orB+7TA 0b81CIEuAccGh3Ifzgyj4tdzB3+Gjv+rmx20Uwmruc8RSrAaBwODpnBx4CQs5c7anXnS Ea+cHfTpw2bMHgG1X6ZWZgeDaiFiZQrmNakf1yoEYTm21xMAuA5IkIepBIH8PCtjC+/e A0UkSCynuJeb96CV/UOlPy6fChsvhUEBwtf6mFO52ZHkDtIHJjNGa6Y50IoNMKEzM9yV MJqw== X-Gm-Message-State: AODbwcCuIIeye3EiqglsK3F2EwLxYmZZs/K9zLRLbH0JgqxCE8euq4Yw CVvyN2g9+rRI65EbbAY= X-Received: by 10.28.8.3 with SMTP id 3mr8520412wmi.38.1496777638082; Tue, 06 Jun 2017 12:33:58 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::100e? ([2600:8802:5600:1da::100e]) by smtp.gmail.com with ESMTPSA id x37sm61547264wrb.42.2017.06.06.12.33.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 12:33:57 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <8C3E2849-DB6D-4087-9244-093DC605FA18@gmail.com> Date: Tue, 6 Jun 2017 12:33:54 -0700 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] State of play in the IPv6 market X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:34:01 -0000 https://www.internetsociety.org/doc/state-ipv6-deployment-2017 I need to tell you, as author of the report (it was copy-edited by Mat = Ford, and is on the ISOC website), that I was surprised by what I = learned doing the research. I was of the impression that things were = mostly moving along, but dealt a lot with Enterprise at Cisco (and = especially Cisco as an Enterprise), and would have pegged deployment a = lot lower than it actually was. I was very pleased to discover how well = the industry had moved along. The big issue right now is Enterprise.= From nobody Fri Jun 9 10:13:23 2017 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 D97B81293F4 for ; Fri, 9 Jun 2017 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 SnRk1i5SpkoE for ; Fri, 9 Jun 2017 10:13:19 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9EA1270A3 for ; Fri, 9 Jun 2017 10:13:19 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id f185so28485140pgc.0 for ; Fri, 09 Jun 2017 10:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=gizEPrD21Lsz5bPlD0QUYJz8Z3HEYlikMEdzMqEISgM=; b=kipY1Hprk6qeS/UAvToT78g1g/AbgFbBDbm59SNAMIeKjq5UznWHe3GqMRgPt82Wme DcMLLlNdLxK/JxEVxmLcsNP1ICyogL0SAK2Asm44bY56M3ixntWNasJSKGnnL26MJj9V EBSqXoLWAUsHS5wbL4BX7NkMt9264Pi+Crh7hkZVIH4ajqFjIk2i+WygPUO5YtneN1GD 3u2Fvb8xTQtmeeZzcDVfmRzFrIBsuXj/22R3rx9hjKwHfgPUbdk9PAnybWBMJfekh6Ne diW8TADzDT5DOM4+logMkoV7jtsY88VfXpuT7bW9P+4gMzO3U0HoaYZb34nall6mtLMJ ROTw== 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:message-id:date:cc:to; bh=gizEPrD21Lsz5bPlD0QUYJz8Z3HEYlikMEdzMqEISgM=; b=graMeiYm0ZBjA+siHC5pyikjP3xCVYhSrNkAUZxYJ23HFjyIaNl/YCFpM57SXZsqOe xOie8Os6Qdhb7nsPJrZ2AoAFfnp0ouo1WzLY6RYPZoHJLEoG6WwwD9XKUPzsQ1MGynA2 LnZ3Ud9cCdhHcQgVsi/xmk9McWQiGLZ0Vj5fyV/GCJV6pXabZ/034QVcnWqBZ+HxHUc7 HXAW42jx85oUblkwefVMZOdyH4lWeX1OtzBUoQEcKttA9xFshf7q7AtyBoNfvGceopQm 4bWaj090/i3rYGiO4FILQtoDLX16Ebfk7EP5LE1nP2iwsqteD3ZBQPUe+oxjumdwz/JZ HRUg== X-Gm-Message-State: AODbwcAzmneYSaC8bNqnSvUX/OrNabrpAWCceGVKT+SQxOKFsrcA/0Pz ZAZBklt6f1Bk1KO8AMw= X-Received: by 10.99.112.14 with SMTP id l14mr32536225pgc.199.1497028399245; Fri, 09 Jun 2017 10:13:19 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id q85sm5851551pfd.7.2017.06.09.10.13.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 10:13:18 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_FF18F025-6021-4342-96DB-324465AB7706" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9749697C-E3F4-4CA0-AD22-2077979625CA@gmail.com> Date: Fri, 9 Jun 2017 10:13:17 -0700 To: IPv6 Ops WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] IPv6 Operations Agenda - IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:13:22 -0000 --Apple-Mail=_FF18F025-6021-4342-96DB-324465AB7706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks: Our agenda for IETF 99 seems to be shaping up as follows. We have two = slots for a total of four hours, and in it we have two invited talks and = four working group drafts. We have had some discussion of 7984-bis on = the list, draft-ietf-v6ops-rfc6555bis was updated Tuesday, and I would = invite review/discussion of draft-ietf-v6ops-ipv6rtr-reqs and = draft-ietf-v6ops-ula-usage-considerations on the list. Ideally, that = results in an update to each of the documents and discussion at IETF 99. That leaves some agenda time - we probably have three hours worth of = discussion and four hours to do it in. I have been surprised before, but = that's my guess at the moment. I'd invite list discussion on = draft-petrescu-v6ops-ipv6-power-ipv4, which was filed just under the = deadline for IETF 98 and didn't get any discussion. If folks have other = drafts they would like to file, and if we have list discussion of them, = we could also give them agenda time. Commentary solicited. Fred Baker for the chairs >=20 > IPv6 Operations - IETF 99=20 >=20 > Turning IPv4 off in an Enterprise network > Marcus Keane, Microsoft > A Longitudinal View of Dual-stacked Websites =E2=80=94 Failures, = Latency and Happy Eyeballs > Vaibhav Bajpai, Technical University of Munich > Requirements for IPv6 Routers = > 2017-05-05 , > Happy Eyeballs Version 2: Better Connectivity Using Concurrency = > 2017-06-05, > Basic Requirements for IPv6 Customer Edge Routers = > 2017-05-29 , > Considerations For Using Unique Local Addresses = > 2017-03-13 , > Draft Status >=20 > The status of IPv6 Operations drafts, both working group drafts = (draft-ietf-IPv6 Operations-*) and individual submissions to the working = group (draft--IPv6 Operations-*), may be determined from = https://datatracker.ietf.org/wg/v6ops/ = .=20 --Apple-Mail=_FF18F025-6021-4342-96DB-324465AB7706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Folks:

Our agenda for IETF 99 seems to be shaping up as follows. We = have two slots for a total of four hours, and in it we have two invited = talks and four working group drafts. We have had some discussion of = 7984-bis on the list, draft-ietf-v6ops-rfc6555bis was updated = Tuesday, and I would invite review/discussion of draft-ietf-v6ops-ipv6rtr-reqs and draft-ietf-v6ops-ula-usage-considerations on the = list. Ideally, that results in an update to each of the documents and = discussion at IETF 99.

That leaves some agenda time - we probably have three hours = worth of discussion and four hours to do it in. I have been surprised = before, but that's my guess at the moment. I'd invite list discussion = on draft-petrescu-v6ops-ipv6-power-ipv4, which was filed just = under the deadline for IETF 98 and didn't get any discussion. If folks = have other drafts they would like to file, and if we have list = discussion of them, we could also give them agenda = time.

Commentary solicited.

Fred Baker for the = chairs


IPv6 Operations - IETF 99 

Turning IPv4 off in an Enterprise network
Marcus Keane, Microsoft
A = Longitudinal View of Dual-stacked Websites =E2=80=94 Failures, Latency = and Happy Eyeballs
Vaibhav Bajpai, Technical = University of Munich
Requirements for IPv6 Routers
2017-05-05 , <draft-ietf-v6ops-ipv6rtr-reqs>
Happy Eyeballs Version 2: Better Connectivity = Using Concurrency
2017-06-05, = <draft-ietf-v6ops-rfc6555bis>
Basic Requirements for IPv6 Customer Edge = Routers
2017-05-29 , = <draft-ietf-v6ops-rfc7084-bis>
Considerations For Using Unique Local = Addresses
2017-03-13 , = <draft-ietf-v6ops-ula-usage-considerations>

Draft Status

The status of IPv6 = Operations drafts, both working group drafts (draft-ietf-IPv6 = Operations-*) and individual submissions to the working group = (draft-<author>-IPv6 Operations-*), may be determined from https://datatracker.ietf.org/wg/v6ops/. 

= --Apple-Mail=_FF18F025-6021-4342-96DB-324465AB7706-- From nobody Sat Jun 10 03:33:43 2017 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 834741201FA; Sat, 10 Jun 2017 03:33:33 -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.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149709081349.2551.13636210837767273446@ietfa.amsl.com> Date: Sat, 10 Jun 2017 03:33:33 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 10:33:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-03.txt Pages : 31 Date : 2017-06-10 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 10 03:38:35 2017 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 CCEA7126C26 for ; Sat, 10 Jun 2017 03:38:33 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c27y0eJqGLiR for ; Sat, 10 Jun 2017 03:38:31 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74F81201FA for ; Sat, 10 Jun 2017 03:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497091108; x=1497695908; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=GbYbWNDLsnpvNFIYQev1cpLKR 2nrYatY4G1B0cj9EOU=; b=RyiiajFWAUgqQium3Du7aUBVBl27xD9+AW15eMGUB 5x+eZ5FIaF4y4oY95wDToYe3+kVfogFxQd8e5WCtcyCAzvyaMD+2jbeFdiu3ZN4i 5P2OiDCWojP9n98PdPtnK0ntyVwLfikEn2Psf6QA5zp+RQYJtwRuli+bF2HTv7TD 0M= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EP8uo3ebArsdxib8w5FcF3WWZG8I0CxoLIY/VNL5KXOKSmAcG9k/aauqgirO OHwH2l5Cpl4EkOfKiSzkk05TbI0GAvfRv11/lirn8z6oP3795oayKPeyo CqCTzCziNb0DOKMf5Z8rDMnjttrT93iopSTjlvOuYgF7IaMtpRlAYI=; X-MDAV-Processed: mail.consulintel.es, Sat, 10 Jun 2017 12:38:28 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 10 Jun 2017 12:38:28 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005448741.msg for ; Sat, 10 Jun 2017 12:38:27 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170610:md50005448741::xFWJiiOU05eOkwhu:00000Urz X-Return-Path: prvs=13342966e6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sat, 10 Jun 2017 12:38:23 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt References: <149606921435.3762.14727398533646344700@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E76580@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E76580@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 10:38:34 -0000 Hi Mohamed, I just uploaded a new version which the following changes 1. LW4O6-5 removed, was a mistake due to copy-paste from DS-LITE. 2. Removed citation to individual I-Ds for DHCPv6 options. Of course, you were right regarding LW406-5, good catch, it was the common = copy/paste issue =E2=80=A6 I also removed the reference to the individual I-D. Regarding obsoleting or updating, I think this requires some more discussio= n, also considering the other comments received in the list. Let=E2=80=99s = approach that in the next weeks. https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/?include_text= =3D1 Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: mi=C3=A9rcoles, 31 de mayo de 2017, 10:10 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt Hi Jordi,=20 =20 Thank you for updating the draft. Below the comments that I do think ar= e still open: =20 * Remove citations to individual I-Ds from the draft.=20 * I'm not sure to understand the motivation for LW4O6-5. Please note th= at this is not equivalent to DSLITE-4 for the simple reason that in DS-Lite= there are no IPv4 address assigned to the CPE from the network, while ther= e is one for lw4o6. I suggest to delete LW4O6-5. =20 * Unless I'm mistaken, I don't remember there was a conclusion about ob= soleting RFC7084 or not. =20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : lundi 29 mai 2017 16:54 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 > Hi all, >=20 > This is an updated version of this document, including the following > changes: >=20 > 11. ANNEX D: Changes from RFC7084-bis-01 >=20 > Section to be removed for WGLC. Significant updates are: >=20 > 1. G-5 added in order to comply with [RFC7608]. >=20 > 2. LW4O6-5 removed. >=20 > 3. MAPE-3 removed. >=20 > 4. MAPT-3 removed. >=20 > 5. Included non-normative reference to [RFC7849] to clarify that = the > details of the connectivity to 3GPP/LTE networks is out of the > scope. >=20 > 6. Split of transition in two sub-sections for the sake of clarit= y. >=20 > 2, 3 and 4 above (added in the previous version) were referring to th= e > explicit mention of NAT behavior. As each mechanism has the relevant = text > in its respective RFC, I leave that to those documents, to avoid any > misunderstanding or conflict. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de > Responder a: > Fecha: lunes, 29 de mayo de 2017, 11:46 > Para: > CC: > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Draft= s > directories. > This draft is a work item of the IPv6 Operations of the IETF. >=20 > Title : Basic Requirements for IPv6 Customer Ed= ge > Routers > Author : Jordi Palet Martinez > Filename : draft-ietf-v6ops-rfc7084-bis-02.txt > Pages : 30 > Date : 2017-05-29 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge= (CE) > router. Specifically, the current version of this document fo= cuses > on the basic provisioning of an IPv6 CE router and the provisi= oning > of IPv6 hosts attached to it. The document also covers severa= l > transition technologies, as required in a world where IPv4 > addresses > are no longer available, so hosts in the customer LANs with IP= v4- > only > or IPv6-only applications or devices, requiring to communicate= with > IPv4-only services at the Internet, are able to do so. The > document > obsoletes RFC 7084. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-02 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bi= s-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc7084-bis-= 02 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.o= rg. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sat Jun 10 13:49:22 2017 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 2C4D6128CF0 for ; Sat, 10 Jun 2017 13:49:21 -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 VsQ2Glhivytb for ; Sat, 10 Jun 2017 13:49:19 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5D81279E5 for ; Sat, 10 Jun 2017 13:49:19 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id a70so35144822pge.3 for ; Sat, 10 Jun 2017 13:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oAeH8JNx64ZQMGim+oFnW4Fh7OmZWJJFG7Hrp1yGXeg=; b=L81pAQntaaVifPL+nF5LJg5hyabJkOZfC58exX6A7d3ByiYCjw0ouCkEj4jPjiZ42I SIgPZZLKgFjEswhYIyv1lwkun0bohXOTmpU248YdSVbq934m0UbpZ9HvogNURhGjp9HG tNL5OAY8TdHcxU7+DrMP/BTDswAriFgK8LtitlAlf0LMJC5wIcGLETavJ4BEowaGvHn/ J61EMVWFXvqXKNSVgbs21idkTF8452uZn69VUGhmLx18/lsugiYYRLbDThiR17EZuQRH POiKVfDtk6hlXLeP1s2nMRpBr12cTzzQrU9KHvQ8EsbjLUSlElLoW1sIlfaPEmpNuwUh O6fQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oAeH8JNx64ZQMGim+oFnW4Fh7OmZWJJFG7Hrp1yGXeg=; b=l0iafJVXkla9JXOL6pVnjFs2ad1cOxdttGBvAFO72lMr84VrqSfUzR1/s3CnQCoS+H dOORHjjNxmQcSzTPSppRC5v1cJEqnmr15X15btKMsy3tMYrfqnY2dX962QLAOTzoUBZP Pitq1KnN+cLEcVQzWStrTyVXM/8NSHc68uWvBuozX1pmrYyoT4oJmlkP5Yb8x0sGfXS3 W4mj8DEVMzQiNPdMCoUWQC6QCMOgZjVSts1adFTnly0PrqKozt5CVOu/52ZNotJH7we8 nWgVjplrRPT0xcmt8c1GB1V6UyC5mPGkT0fJcKL/Gehq09f5F6SJRx+oRRAGRR+J28L3 8k8g== X-Gm-Message-State: AODbwcABxoA5O9GabkZdus3Gqp08zsS2cIp/bVpC/W1q478ZxSIYE5X2 KZFSumWbIeYruGqVQs0= X-Received: by 10.98.19.145 with SMTP id 17mr39112309pft.208.1497127758892; Sat, 10 Jun 2017 13:49:18 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f8sm11003813pfc.14.2017.06.10.13.49.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 13:49:18 -0700 (PDT) To: IPv6 Operations References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> Date: Sun, 11 Jun 2017 08:49:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149709081349.2551.13636210837767273446@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:49:21 -0000 Hi, Looking at this and thinking about some recent discussions, I realised that I have a basic comment about the scope of this draft, which leads to suggestions about its title, Abstrac, and Introdcution. The text in 4.2 "IPv6 End-User Network Architecture" asserts that "The end-user network architecture for IPv6 should provide equivalent or better capabilities and functionality than the current IPv4 architecture." I don't think anybody would disagree with that gial, but the very next sentence says "The end-user network is a stub network." That is no better capability or functionality than IP4. Apart from NAT, it's the same. So, naturally, HNCP and homenet is out of scope. If that is the target for this draft, fine, but then its title, Abstract and Introduction need rephrasing. Something like: Title: Requirements for Low-end IPv6 Customer Edge Routers Abstract: This document specifies requirements for a low-end IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router that does not support subsidiary routers, and the provisioning of IPv6 hosts attached directly to it. ... 1. Introduction This document defines basic IPv6 features for a low-end residential or small-office router, referred to as an "IPv6 CE router", in order to establish an industry baseline for features to be implemented on such a minimal router with directly attached IPv6 hosts. CE routers intended to support subsidiary IPv6 routers in a more complex residential or office network need additional features such as those described in [homenet]. Regards Brian On 10/06/2017 22:33, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations of the IETF. > > Title : Basic Requirements for IPv6 Customer Edge Routers > Author : Jordi Palet Martinez > Filename : draft-ietf-v6ops-rfc7084-bis-03.txt > Pages : 31 > Date : 2017-06-10 > > Abstract: > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses > on the basic provisioning of an IPv6 CE router and the provisioning > of IPv6 hosts attached to it. The document also covers several > transition technologies, as required in a world where IPv4 addresses > are no longer available, so hosts in the customer LANs with IPv4-only > or IPv6-only applications or devices, requiring to communicate with > IPv4-only services at the Internet, are able to do so. The document > obsoletes RFC 7084. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-03 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sat Jun 10 13:55:34 2017 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 BCC741200E5 for ; Sat, 10 Jun 2017 13:55:33 -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 fIewvHG-WLTm for ; Sat, 10 Jun 2017 13:55:32 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A96C126D85 for ; Sat, 10 Jun 2017 13:55:30 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v18so35170353pgb.1 for ; Sat, 10 Jun 2017 13:55:30 -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=DpweBAqx8XbXg0pUEY5NckMW40h2IlJqD/Lhr9KAxps=; b=D1xxepozIhRF82dz/aWu5k9KQOvn3wWnjSNPfROHnf9EiM7YPOIDLIHYxjY6VYs0x0 4STN/KNdq/kFuSeqIxuR/Cq8ubdFFC3G5se2Kb/dNgvDCS0QMkPpTjCVJ51cQYIhQZZ/ n9CqgaUm3MlDdusCvdvsG6bWQBmkw+E0ks3Q+cP2t+ZrCWlAHErhpRdqT40khFNUHeGl GeexekMwmUrhGCZ2TchHQVfa2Rracqf7+MXU0AZd00aU27+AWq5/oFtIvwPW5v8p1jwm ZtBHDNne/SiNFs5Np7aTjc/3dN0P2kHTrFW1m9iL2vsdUZTSnzyoYFuOtkoZxa1oYL7K SIDw== 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=DpweBAqx8XbXg0pUEY5NckMW40h2IlJqD/Lhr9KAxps=; b=ikoAh0fh1KYGCZD7H5k442XKrks8/ggQ/EQFVFVoD0NobKwUD17uKk399oYFy9U2n5 Ckjlt6fzyoErooSs50qmZSzdVFd8M4+g/eME9mqqib3uZAPzXp3kpKSRfebPxrRvi01B am2lqRMI449d/pWUhE8clUjzwZ1agjuLkzvMz2dFEP9NZAOPKaOHERJLoc7nY+lpnei5 yDfKVaBfVxX/KI9hWq4cWJwORRnsysn10hiDBCjmELM/O8zWUi43BeLRgq6z8GskGve1 g4raw8xPZOAi2AhAKCWkZIcbRTr7ctcSq9ZT2PX4LlJQAi6FWsRv1eKwMxoDKSgif31m uuFQ== X-Gm-Message-State: AODbwcCDp2LDa+30ukKF7XtQk4HSs2Zyj5tOHJ8UG2IMXiErbtNvoxZW iNGmWn/vdkUGOg== X-Received: by 10.84.143.70 with SMTP id 64mr17334921ply.36.1497128130335; Sat, 10 Jun 2017 13:55:30 -0700 (PDT) Received: from [192.168.1.12] (ip184-189-217-181.sb.sd.cox.net. [184.189.217.181]) by smtp.gmail.com with ESMTPSA id d185sm8733109pgc.39.2017.06.10.13.55.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 13:55:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> Date: Sat, 10 Jun 2017 13:55:28 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:55:34 -0000 On Jun 10, 2017, at 1:49 PM, Brian E Carpenter = wrote: > "The end-user network is a stub network." >=20 > That is no better capability or functionality than IP4. Apart from > NAT, it's the same. >=20 > So, naturally, HNCP and homenet is out of scope. no hats I'm not sure how you get from "stub network" to "no HNCP". The = residential network is a stub, which is to say it offers no transit = services. Enterprise and university networks are also stubs; they offer = no transit services. However, they can have a great deal of internal = complexity. Why does making the home offer no transit services preclude HNCP and = homenet?= From nobody Sat Jun 10 18:54:29 2017 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 17E5F1294BC for ; Sat, 10 Jun 2017 18:54:28 -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 c8nynPSE1TRp for ; Sat, 10 Jun 2017 18:54:26 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FA41294B7 for ; Sat, 10 Jun 2017 18:54:26 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 15so12586724pfc.1 for ; Sat, 10 Jun 2017 18:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cbOzeObqMV2tMLHY0wnfCVw9STOXkQhcDwDT9lUT/28=; b=rOK0WirWW+KzF6Jfm+jaLJf93CCsKwyotU3cFPXLmpLPLbLV+Ipp/oHtGI0O8A1FhG 8gyGAZ6Y3EycMtC8lGQoQ8B4niyZ+zWQ7k/YosebsgOFIN9+rQ6VQm8ZWGujrVYoULMj tMmoooBiebugheEbg9ylbfqPTMckdMrXqoiuQV9PW4IvRSHB/qOnrgzwyy/+lx31w+k2 ZaC2zK4upyAQv14dKRvUrLCts0nns0YbCQYAh8NniJEHvonILQkRcNysvdgfi95FiQeL v3o635ev0GQN4uuxj9rfWbhJ/1UPSsZC+UMsCUasPCcwFosaTNrf2aURZm5wLwDEIiee aFtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cbOzeObqMV2tMLHY0wnfCVw9STOXkQhcDwDT9lUT/28=; b=LOg2x/J+2zrvql0Z8LndlVsxHSpLiC7jEe/c/UtotvtlkDHdeg0EDSMg87+vkEToz+ n7UWlwbFm1ED4rFw6nRFltx3oD1oQNiN7Cl+6MRDIMxpJjD8LN4m38MMNGVk8VK8/dje vs0ISWRk/EgpJnbK1wn8BzKXIUfVRB9GV37rhXfI8fidGWUGyYsDg4YoJePn4YdbU57L gqyKg/Vrthn7cBWW9nxvMC9d+v380tQo7mrNnUCZbC5MT0ZdQMGw9VzlaGa8nl4ZNe4X YRwYr4Ex1b3xmWSKuMiKCrADoSSpnC0fg8ROfvRHeatSv17g3riYes8CmMu9EUguADBL fntQ== X-Gm-Message-State: AODbwcCg/PTJ/4Rope4/Fny9iGfY6PDRCJzWvS4itLVlqVtDQ/HKDQ9b aqFVEoeGFa15df0i X-Received: by 10.101.88.130 with SMTP id d2mr7871292pgu.58.1497146065887; Sat, 10 Jun 2017 18:54:25 -0700 (PDT) Received: from ?IPv6:2406:e001:541b:1:28cc:dc4c:9703:6781? ([2406:e001:541b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e124sm10915057pfc.64.2017.06.10.18.54.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 18:54:25 -0700 (PDT) To: Fred Baker Cc: IPv6 Operations References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> Date: Sun, 11 Jun 2017 13:54:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.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] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 01:54:28 -0000 On 11/06/2017 08:55, Fred Baker wrote: > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: >> "The end-user network is a stub network." >> >> That is no better capability or functionality than IP4. Apart from >> NAT, it's the same. >> >> So, naturally, HNCP and homenet is out of scope. > > no hats > > I'm not sure how you get from "stub network" to "no HNCP". The residential network is a stub, which is to say it offers no transit services. Enterprise and university networks are also stubs; they offer no transit services. However, they can have a great deal of internal complexity. > > Why does making the home offer no transit services preclude HNCP and homenet? It doesn't so my phrasing was a bit wrong. The point is that what the draft describes is services to hosts, not services to hosts and additional routers. IMHO, that should be made explicit in the title and abstract and the very beginning of the introduction, even sooner than: "Automatic provisioning of more complex topology than a single router with multiple LAN interfaces is out of scope for this document." It's a truth in advertising issue, and it needs to leave the door open for a future spec that does require support for more complex topologies. Brian From nobody Sun Jun 11 01:28:08 2017 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 5475A124B0A for ; Sun, 11 Jun 2017 01:28: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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-vrv8__2qz8 for ; Sun, 11 Jun 2017 01:28:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C7B120721 for ; Sun, 11 Jun 2017 01:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497169681; x=1497774481; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=XBw/ZMZ9mgJVUaLmjx3ijgMa1 zH9hriG6KleNDAnBPg=; b=AvvT26hxbd7WLK93x/pWjpOlDxKqbgUYdjSQyr4H3 LRDeH3EF1oWDeoAfScFBEEaT/hQqta7+AdkSU24XMKRUdkWdZ93lOwpCKxT4zNXN DEzayCT/hL/G/Fx/4I8Njs6/55obnwdxj1wUfQcNcr4yjRcBtL4Kk2ov0S1WC1v9 zU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Kkwc/E8D7nG9nwvfDrJesK6rJ0TPu3VdB1k9uM5ES/i8SN+tIL9UKXLn41aH Vuwyr2qH7I7SeyyfoaVaCCt60GrEm/JVOeHDGat65vSvaVpl6KdCrMtwU qTSYkUQtvg8Zx4ZrS9QYEYjaUusIm0IBaf+5ZOXGlIiIOH/IZFmYds=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 10:28:01 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 10:27:59 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449004.msg for ; Sun, 11 Jun 2017 10:27:59 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449004::fDkTjbW0674egkxG:00002V7t X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 10:27:57 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> In-Reply-To: <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 08:28:06 -0000 Hi Brian, I don=E2=80=99t think the original intent of the document (even when it was= RFC6204 and even before that), was to exclude the support of more complex = topologies, but just to make sure that those mechanisms aren=E2=80=99t desc= ribed in the document itself. And yes, if that=E2=80=99s the case, I agree that there is some text in the= abstract and intro that may preclude the support for HNCP, so this needs t= o be changed. I=E2=80=99m trying to confirm that I understand your point correctly, eithe= r 1) We have a very basic IPv6-only CE that ONLY allows hosts to connect to i= t but no other routers behind it. 2) We have non-so-basic IPv6 CE which allows host and automatically provisi= oned routers behind it. I=E2=80=99m not making here considerations about transition mechanisms, onl= y if the basic CE, the one that most of the ISPs provide for =E2=80=9Cfree= =E2=80=9D to the customers, should support automatic provisioning (with HNC= P) or not? Now, do we agree that scenario 1) is unrealistic in the near term? If we st= ill want to define this case, shall it be something like =E2=80=9CMinimum R= equirements for IPv6-only Edge Routers=E2=80=9D, and even not considering I= Pv4 support at all there =E2=80=A6 as this may be the case for very simple = networks that only need to connect a few sensors and nothing else, etc. Thi= s is the case for new networks that are being deployed since the start with= IPv6-only in mind, and not considering IPv4 support at all. And then we can have a more realistic scenario for a =E2=80=9Ccustomer orie= nted=E2=80=9D CE, which may have the need to HNCP (other routers may need t= o be provisioned behind the main one), and has still some apps/devices with= IPv4 support (so transition mechanisms need to be supported for those host= s to work in an IPv6-only access link). This may be what we have as our act= ual =E2=80=9CBasic Requirements for IPv6 Customer Edge Routers=E2=80=9D. What do you think? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: domingo, 11 de junio de 2017, 3:54 Para: Fred Baker CC: IPv6 Operations Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt On 11/06/2017 08:55, Fred Baker wrote: >=20 > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: >> "The end-user network is a stub network." >> >> That is no better capability or functionality than IP4. Apart from >> NAT, it's the same. >> >> So, naturally, HNCP and homenet is out of scope. >=20 > no hats >=20 > I'm not sure how you get from "stub network" to "no HNCP". The reside= ntial network is a stub, which is to say it offers no transit services. Ent= erprise and university networks are also stubs; they offer no transit servi= ces. However, they can have a great deal of internal complexity. >=20 > Why does making the home offer no transit services preclude HNCP and = homenet? =20 It doesn't so my phrasing was a bit wrong. The point is that what the draft describes is services to hosts, not services to hosts and additio= nal routers. IMHO, that should be made explicit in the title and abstract a= nd the very beginning of the introduction, even sooner than: =20 "Automatic provisioning of more complex topology than a single router with multiple LAN interfaces is out of scope for this document." =20 It's a truth in advertising issue, and it needs to leave the door open for a future spec that does require support for more complex topologies. =20 Brian =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 01:39:58 2017 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 429D11294D4 for ; Sun, 11 Jun 2017 01:39:56 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3gRIZrpMQ2H for ; Sun, 11 Jun 2017 01:39:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E661294CD for ; Sun, 11 Jun 2017 01:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497170392; x=1497775192; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=OGI2KgdEUiqbnwmcWCV7WWw49XFju1JM7UWsv3VFdkw=; b=STfiQzcadHgas VAVrYyG9Bydh7/eCheXsWEP7N6jmwx9YIupiw8z9vjm+Oa4LkYB8WTcoFHCN7z06 fPGFifW+JgoAkj4sJJOWYXBGvK2K50moQpSeaM/Tonx3T5TZa/sx9lhQLjYwrITU eEruN09oAMLF4bQE0Y3YA5IuSYjSbc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gl2bvg6ZW6ZyhTQLtJr3K/1EcPXklN50h7fecKE1XeK32R3JGu3c8ybCUJLh bH2BcFeiIe8KEJd9K4VXj5jG0Jg7QLdtNWPlzNAEnPFn0nRcJlEy4bir6 TCQani5c9OdIyYJVVppU4e7i0BdPlCn8ibU5gDuVM9/nN+b2KRNqi4=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 10:39:51 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 10:39:50 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449009.msg for ; Sun, 11 Jun 2017 10:39:49 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449009::KyDdfbjEMcf/A0op:00000/P1 X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 10:39:46 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> Thread-Topic: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 08:39:56 -0000 Hi Barbara, Regarding 5.1, Tore already explained it. Moreover, I=E2=80=99ve not change= d that from what you have at your document RFC7084, so may be one of your c= o-authors added that text at some point and you didn=E2=80=99t realize it. I think is pity that you come after 6 versions of this document, with a gen= eric banning of it, while you had the opportunity to say so at any point or= even in the Chicago meeting, and then we could have discussed then alterna= tive ways to move on. It=E2=80=99s life, I take it and keep moving. After a few private email exchanges and also Brian email, I think I got a d= ifferent picture (even if I=E2=80=99m not totally convinced myself), of wha= t we need. Basically, we need to go back to RFC6204 (which didn=E2=80=99t i= ncluded transition at all) and even more NOT include IPv4 support at all. I= SPs that need to deploy very very very simple IPv6-only networks for IPv6-o= nly devices and apps and may be not supporting anything else than hosts (no= t clear about this at this point, see my latest email to Brian). And then a= nother document for a more =E2=80=9Crealistic=E2=80=9D CE which allows casc= ading routers and hosts that may need IPv4 transition support. Do you think you will agree on that? Stay tuned, I=E2=80=99m trying my best to have a draft of both documents to= day. Then we can call for a poll to the WG about that =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Responder a: Fecha: lunes, 5 de junio de 2017, 18:28 Para: "v6ops@ietf.org" Asunto: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my comments= . =20 General: While I support providing CE router vendors with information o= n IPv6 transition technologies, I think that an RFC7084-bis is not the righ= t way to do this, and this particular draft tries to do more than just add = those transition technologies; some of these additional items I don't suppo= rt. I think this draft weakens RFC7084 by adding such a lengthy list of tra= nsition technologies and adding other requirements and text that are not br= oadly useful. I would prefer a stand-alone document that described just the= transition technologies. =20 Specific comments: 3. Usage scenarios I don't find this new and very lengthy section to be more useful than t= he existing simple statement of "This document defines basic IPv6 features = for a residential or small-office router". I question the need to expand th= e original simple sentence into this lengthy section (6 bullets and 8 parag= raphs). I don't understand what "exporting IPv6 services" means. I don't unders= tand why discussion of IPv4 NAT configuration is particularly relevant as p= art of preamble discussion for the requirements in this draft. =20 5.1 General Requirements, G-5 I don't understand what additional functionality G-5 provides that was = not covered by G-4. G-5 seems redundant. =20 5.5. IPv4 Multicast Support I disagree with recommending this functionality in all CE Routers. It i= s very definitely not necessary in a basic CE router.=20 =20 8. ANNEX A: Code Considerations I disagree with much of the editorializing and assumptions made in this= section and would prefer to see this section removed. Every CE Router vend= or (and ISP) must decide for themselves whether using open source code is a= ppropriate for them. Licenses must be carefully examined, as some license c= an be very problematic for vendors and for ISPs that ship the vendor's prod= ucts. Claiming that existence of open source code means cost of developing = code is negligible ["negligent" is probably not the intended word] is unsub= stantiated and therefore inappropriate. Claiming that "only integration and= testing cost may become a minor issue" is also inaccurate and inappropriat= e. The more code a CE router has, the more testing that has to be done, and= this cannot be assumed to be minor. It also creates usability and support = issues, if the functionality is presented via the UI. Every additional feat= ure adds cost to these very low margin devices. =20 Barbara =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 10:43:35 2017 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 8BC0B129687 for ; Sun, 11 Jun 2017 10:43:33 -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, 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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKoWf0Q8U8vH for ; Sun, 11 Jun 2017 10:43:31 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82E12957B for ; Sun, 11 Jun 2017 10:43:31 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2017 17:43:30 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E3AB1D788B; Sun, 11 Jun 2017 10:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=sCmbtp+iJz5d69sbjemszJs+KTo=; b= kghXsSUwAdEIThx2AzYDf38gmrvQ7nIfAkL0N8ZnYa0MEoY8Jhd1d2K4x55g4+rS Naeu4PtQFR2fp4MuOtxlt1BjbCpnHgiovp/xuAPNGemASdXnX5XuWsB9iLuGr6Sb 5fBH2Nwhfo2CS5xVFk+7RL3a5m/L8NqfSRTjMA3CaO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=JxACEAmVLvQy4kZJedAtWJ5 5EGwBK1/hPkaitYgEPDfEGtRDNmWIIKtS5mwicLGy6XiTKGBWdCleO762Cw3rbe6 EQX0f9z24rN+pbxpEF8mkNhU7AK4nYCZ4cfiklMSW0885Rb5H14pxqbtthpBv++m z24deJXQ9EYx79zadQiQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7E9D0D788A; Sun, 11 Jun 2017 10:43:29 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E49CDD18C80F; Sun, 11 Jun 2017 19:43:26 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7FA6B6EB-8B62-494C-AB52-CE64C4CF2E26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 11 Jun 2017 19:43:25 +0200 In-Reply-To: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> Cc: "v6ops@ietf.org" To: jordi.palet@consulintel.es References: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 17:43:33 -0000 --Apple-Mail=_7FA6B6EB-8B62-494C-AB52-CE64C4CF2E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jun 2017, at 10:39, JORDI PALET MARTINEZ = wrote: >=20 > Hi Barbara, >=20 > Regarding 5.1, Tore already explained it. Moreover, I=E2=80=99ve not = changed that from what you have at your document RFC7084, so may be one = of your co-authors added that text at some point and you didn=E2=80=99t = realize it. >=20 > I think is pity that you come after 6 versions of this document, with = a generic banning of it, while you had the opportunity to say so at any = point or even in the Chicago meeting, and then we could have discussed = then alternative ways to move on. It=E2=80=99s life, I take it and keep = moving. If you look back in the archives you will see that several of us have = been saying that since this draft came out. > After a few private email exchanges and also Brian email, I think I = got a different picture (even if I=E2=80=99m not totally convinced = myself), of what we need. Basically, we need to go back to RFC6204 = (which didn=E2=80=99t included transition at all) and even more NOT = include IPv4 support at all. ISPs that need to deploy very very very = simple IPv6-only networks for IPv6-only devices and apps and may be not = supporting anything else than hosts (not clear about this at this point, = see my latest email to Brian). And then another document for a more = =E2=80=9Crealistic=E2=80=9D CE which allows cascading routers and hosts = that may need IPv4 transition support. I'd be happy to add HNCP and routing support to 6204bis. Then move what you have added in 7084bis into a separate document "Basic = IPv4 CE requirements for every IPv4 sunsetting mechanism ever invented" = ;-) Cheers, Ole >=20 > Do you think you will agree on that? >=20 > Stay tuned, I=E2=80=99m trying my best to have a draft of both = documents today. Then we can call for a poll to the WG about that =E2=80=A6= >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de "STARK, BARBARA H" = > Responder a: > Fecha: lunes, 5 de junio de 2017, 18:28 > Para: "v6ops@ietf.org" > Asunto: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 >=20 > I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my = comments. >=20 > General: While I support providing CE router vendors with = information on IPv6 transition technologies, I think that an RFC7084-bis = is not the right way to do this, and this particular draft tries to do = more than just add those transition technologies; some of these = additional items I don't support. I think this draft weakens RFC7084 by = adding such a lengthy list of transition technologies and adding other = requirements and text that are not broadly useful. I would prefer a = stand-alone document that described just the transition technologies. >=20 > Specific comments: > 3. Usage scenarios > I don't find this new and very lengthy section to be more useful = than the existing simple statement of "This document defines basic IPv6 = features for a residential or small-office router". I question the need = to expand the original simple sentence into this lengthy section (6 = bullets and 8 paragraphs). > I don't understand what "exporting IPv6 services" means. I don't = understand why discussion of IPv4 NAT configuration is particularly = relevant as part of preamble discussion for the requirements in this = draft. >=20 > 5.1 General Requirements, G-5 > I don't understand what additional functionality G-5 provides that = was not covered by G-4. G-5 seems redundant. >=20 > 5.5. IPv4 Multicast Support > I disagree with recommending this functionality in all CE Routers. = It is very definitely not necessary in a basic CE router. >=20 > 8. ANNEX A: Code Considerations > I disagree with much of the editorializing and assumptions made in = this section and would prefer to see this section removed. Every CE = Router vendor (and ISP) must decide for themselves whether using open = source code is appropriate for them. Licenses must be carefully = examined, as some license can be very problematic for vendors and for = ISPs that ship the vendor's products. Claiming that existence of open = source code means cost of developing code is negligible ["negligent" is = probably not the intended word] is unsubstantiated and therefore = inappropriate. Claiming that "only integration and testing cost may = become a minor issue" is also inaccurate and inappropriate. The more = code a CE router has, the more testing that has to be done, and this = cannot be assumed to be minor. It also creates usability and support = issues, if the functionality is presented via the UI. Every additional = feature adds cost to these very low margin devices. >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_7FA6B6EB-8B62-494C-AB52-CE64C4CF2E26 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZPYE+AAoJEL7aWKiYQt92C0sP/RFV0ga9WrQRJl2RianKyYOZ WiVt1spDhSB1C1kkHSl9gW8MI/xxzQ+2SRt6TMgZaX9eZcxol3KkNjtSOLFjSe0h XSvpYXTkPwTEGAyk18osfEb2JLqXm4eOvGn9nTDR56o/wN76wipdLDJ1vtCBwtIc S9zoPY2gFNJqD9/5KSKyZ56P9T/PljBEkCsZpF/5pSHWYAhbXxj/atitRdt851W6 94AzYCwVqDFYMLgGup905UU6FxAPSPSNaxWTT6j2QQ/vcIZyfRdXPgJxJN6KI+nM 8YJeAjL9hLagT+AtYXUoVfIkl8o4sS0Xq4+gsXWKhJsJpgMf6Hdd/G4i1Mvo+YKz j4nz7XTJSHo6AcFcw4kP+IUxHnUk7yMZPnzrNx/KddC3VljgkGQgU1Hwsw1RybEX cnkDvV1lFxVqBBVtkjVYp7vIeo6io/Wj7HZZGKyLOok85V0Op0tTkrW552EtbuvS VzO6oilcpjrsWIwo4V6SoT3GrVz1XxnZ4uLgccG/UuOO63AVHdAvSl6EEDRI29sL TtBybplsKr6Bp7tbbdbfzXESGfeKL6ZsCouGeiklQrqOpNrBxKKQRSa0iQXo5aRV b01yso+KrObyH2SgzSt8W9t4EsqHM0jjzU8Q64n0IQlJRl8ZEUC4g8NBIHr6C8/i u4UQPpve0Tn1sA6JN6Hp =lR+q -----END PGP SIGNATURE----- --Apple-Mail=_7FA6B6EB-8B62-494C-AB52-CE64C4CF2E26-- From nobody Sun Jun 11 11:58:48 2017 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 CA7BD1292AE for ; Sun, 11 Jun 2017 11:58: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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7dHmV4mLpQc for ; Sun, 11 Jun 2017 11:58:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8E6128B90 for ; Sun, 11 Jun 2017 11:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497207522; x=1497812322; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=oI1xi0/IAFuoFXSfrY/URBhGE wc16Co7PV+UfbTzjR8=; b=erB/FCRZRpHq8fFZm5KXZjIXErFlU7b41PmsrVJw2 qRXvOzSwjBS9q+VtLAqNMhoxmD6btF+VD/nrw4NrzGKBrybxU0hdI/Nko9xCjmuj jyGvAAgGIHyeapEqDTyDs2Du+q4OKymDT3DbIzUvVK2Egpxg+N23JzvT9/SFgVjF FA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=mY281KymyKowaup656C2+le6wBGmTbjIaoBKsJVaLQSKjZqyoeo3YECbleJD oVfkbxmbnvAv85ZFieU5Pf8iZ4pT/KgX8fkb2BZ8DO408Th7RPmz6rUCu OCmtmZwRwZlHLaIo1NBUqDhmh9y4Pnp24i8shJ8TuHATyfXwJfttW4=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 20:58:42 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 20:58:41 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449155.msg for ; Sun, 11 Jun 2017 20:58:40 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449155::az/v4+XZkxpUHLZM:00001bwJ X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 20:58:38 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <64F0FCEE-5BD4-4067-A70E-78DF1FA26C97@consulintel.es> Thread-Topic: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 References: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:58:47 -0000 Hi Ole, When we started this discussion, I agree that was some folks that showed th= eir contrary opinions to proceed that way. However, those contrary opinions ceased before the Chicago meeting, and in = the meeting itself, it was clear that there was an outstanding support, and= in fact that was the reason it was adopted as a WG item. Never mind, see my next email on this. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: domingo, 11 de junio de 2017, 19:43 Para: CC: "v6ops@ietf.org" Asunto: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 =20 > On 11 Jun 2017, at 10:39, JORDI PALET MARTINEZ wrote: >=20 > Hi Barbara, >=20 > Regarding 5.1, Tore already explained it. Moreover, I=E2=80=99ve not = changed that from what you have at your document RFC7084, so may be one of = your co-authors added that text at some point and you didn=E2=80=99t realiz= e it. >=20 > I think is pity that you come after 6 versions of this document, with= a generic banning of it, while you had the opportunity to say so at any po= int or even in the Chicago meeting, and then we could have discussed then a= lternative ways to move on. It=E2=80=99s life, I take it and keep moving. =20 If you look back in the archives you will see that several of us have b= een saying that since this draft came out. =20 > After a few private email exchanges and also Brian email, I think I g= ot a different picture (even if I=E2=80=99m not totally convinced myself), = of what we need. Basically, we need to go back to RFC6204 (which didn=E2=80= =99t included transition at all) and even more NOT include IPv4 support at = all. ISPs that need to deploy very very very simple IPv6-only networks for = IPv6-only devices and apps and may be not supporting anything else than hos= ts (not clear about this at this point, see my latest email to Brian). And = then another document for a more =E2=80=9Crealistic=E2=80=9D CE which allow= s cascading routers and hosts that may need IPv4 transition support. =20 I'd be happy to add HNCP and routing support to 6204bis. =20 Then move what you have added in 7084bis into a separate document "Basi= c IPv4 CE requirements for every IPv4 sunsetting mechanism ever invented" ;= -) =20 Cheers, Ole =20 >=20 > Do you think you will agree on that? >=20 > Stay tuned, I=E2=80=99m trying my best to have a draft of both docume= nts today. Then we can call for a poll to the WG about that =E2=80=A6 >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de "STARK, BARBARA H" > Responder a: > Fecha: lunes, 5 de junio de 2017, 18:28 > Para: "v6ops@ietf.org" > Asunto: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 >=20 > I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my com= ments. >=20 > General: While I support providing CE router vendors with informat= ion on IPv6 transition technologies, I think that an RFC7084-bis is not the= right way to do this, and this particular draft tries to do more than just= add those transition technologies; some of these additional items I don't = support. I think this draft weakens RFC7084 by adding such a lengthy list o= f transition technologies and adding other requirements and text that are n= ot broadly useful. I would prefer a stand-alone document that described jus= t the transition technologies. >=20 > Specific comments: > 3. Usage scenarios > I don't find this new and very lengthy section to be more useful t= han the existing simple statement of "This document defines basic IPv6 feat= ures for a residential or small-office router". I question the need to expa= nd the original simple sentence into this lengthy section (6 bullets and 8 = paragraphs). > I don't understand what "exporting IPv6 services" means. I don't u= nderstand why discussion of IPv4 NAT configuration is particularly relevant= as part of preamble discussion for the requirements in this draft. >=20 > 5.1 General Requirements, G-5 > I don't understand what additional functionality G-5 provides that= was not covered by G-4. G-5 seems redundant. >=20 > 5.5. IPv4 Multicast Support > I disagree with recommending this functionality in all CE Routers.= It is very definitely not necessary in a basic CE router. >=20 > 8. ANNEX A: Code Considerations > I disagree with much of the editorializing and assumptions made in= this section and would prefer to see this section removed. Every CE Router= vendor (and ISP) must decide for themselves whether using open source code= is appropriate for them. Licenses must be carefully examined, as some lice= nse can be very problematic for vendors and for ISPs that ship the vendor's= products. Claiming that existence of open source code means cost of develo= ping code is negligible ["negligent" is probably not the intended word] is = unsubstantiated and therefore inappropriate. Claiming that "only integratio= n and testing cost may become a minor issue" is also inaccurate and inappro= priate. The more code a CE router has, the more testing that has to be done= , and this cannot be assumed to be minor. It also creates usability and sup= port issues, if the functionality is presented via the UI. Every additional= feature adds cost to these very low margin devices. >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 12:16:51 2017 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 48AA51292AE for ; Sun, 11 Jun 2017 12:16:50 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKYnM-nFbXeU for ; Sun, 11 Jun 2017 12:16:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF99126DC2 for ; Sun, 11 Jun 2017 12:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497208606; x=1497813406; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=4pycUHaV/8C9myc79AwqGCPLV l1LrDv5c5lwjCLZtu4=; b=fSV6nqycO4Zm2YLs9i6aW9WhtFVYdlmzIRhcQJc66 rjUv+ekQtrCVhH10FiWeT6tgTx0tUpVAe3PCoF1kZ7lVcstxM5musEESGGxywyK+ 39I2AvuPl+s/9DkK85cbP9zVL/qz82Xhc4x4v7rrK364r0UWK2LWRc51/r0N2+D8 T8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=W5roRyM5JYzs9isyFsDzftj4K7LKfQjE3GciBS+EO20jw1U1EgLu5TTj0H0I SyhWllXXfMlAnm1jsZ/Od5cOlUoPwyMd7pGZi+6J3CWG7qGWvaJUN3CAi Fjg13fprbnmBEUJS9ijIpOAPZ5yb79FwyaZmMK/3jA+GUugBwp50P4=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 21:16:46 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 21:16:46 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449160.msg for ; Sun, 11 Jun 2017 21:16:45 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449160::iszXbI7L31WXM1Sz:00000AUW X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 21:16:42 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <3C140AFE-6630-4767-99F7-06E1350160EB@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt References: <149720722498.13052.13287308290618949018.idtracker@ietfa.amsl.com> In-Reply-To: <149720722498.13052.13287308290618949018.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 19:16:50 -0000 Hi all, I just published an alternative to draft-ietf-v6ops-rfc7084-bis-03.txt. The idea of this document is to have a =E2=80=9Cminimum IPv6-only=E2=80=9D = simple CE router, no IPv4 support, no transition mechanisms, no HNCP. This is not only going back to RFC6204, but in fact making it a much simple= r device, which is suitable also for scenarios where for sure there will be= for example =E2=80=9CIPv6-only=E2=80=9D sensors/devices, etc. I=E2=80=99m also working in another document that will be including, as an = extension to this document, the support for HNCP, dual-stack and transition= stuff. I hope to finish it tonight. I=E2=80=99m not yet taking a position, this should be in the hands of the W= G, I guess a poll may be needed, if we want to go this or that path. One specific question about this document. RFC 7084 included W-6: W-6: The WAN interface of the CE router SHOULD support a Port Control Protocol (PCP) client as specified in [RFC6887] for use by applications on the CE router. The PCP client SHOULD follow the procedure specified in Section 8.1 of [RFC6887] to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE router is out of scope. I know PCP can be used also for controlling IPv6 ports, but I feel that in = an IPv6-only CE, doesn=E2=80=99t have too much sense, and if we want a real= ly minimum IPv6-CE, then I think it doesn=E2=80=99t make sense (maybe if th= e ISP want to use NAT64 to provide access to IPv4-only resources in an IPv6= -only network but having a control on ports =E2=80=A6 I don=E2=80=99t see i= t =E2=80=A6). Opinions? Of course, another possibility is to have one more document which is =E2=80= =9CMinimum requirements for IPv6 CE Router with dual-stack support=E2=80=9D= (but NO-transition mechanism at all, which means RFC7084-bis-03, but remov= ing section 3-usage scenarios, 5-4 transition, 5.5 IPv4 multicast). However= in my opinion this is unrealistic in terms of products being developed in = 1-2 years, because if you have dual-stack, but no-transition support in the= router, you will not have IPv4 addresses to actually deploy it =E2=80=A6 D= espite that, I will be working on it if the WG decides is the way to go. Finally, a scenario where we want to have IPv6-only, no transition, but HNC= P support, is one more option, again happy to work on that if the WG believ= es is the way. However, again, is that realistic? I think in that case of a= more complex home network, you want the router with the transition support= . Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: domingo, 11 de junio de 2017, 20:53 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt =20 A new version of I-D, draft-palet-v6ops-rfc7084-bis2-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-rfc7084-bis2 Revision: 00 Title: Minimum Requirements for IPv6-only Customer Edge Routers Document date: 2017-06-10 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= rfc7084-bis2-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7= 084-bis2/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-b= is2-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -rfc7084-bis2-00 =20 =20 Abstract: This document specifies minimum requirements for an IPv6-only Customer Edge (CE) router. Specifically, the current version of thi= s document focuses on the basic provisioning of an IPv6-only CE router and the provisioning of IPv6 hosts attached to it. Neither the provisioning of IPv4 nor downstream routers are in the scope of this document. The document obsoletes RFC 7084. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 12:34:27 2017 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 632B91200F3 for ; Sun, 11 Jun 2017 12:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl3qHHcDgy68 for ; Sun, 11 Jun 2017 12:34:24 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4DA126C83 for ; Sun, 11 Jun 2017 12:34:24 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2017 19:34:23 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 94DA0D788D; Sun, 11 Jun 2017 12:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=vgdxkILq2s00BKGjTfUpxmcn57I=; b= Vgf9byoHMbAHNAz1fLyzBlaZVelqDEhretYAerHT9YdZFQmCo9ZmRFpNg/RM3ETy Z/K5oKr45nfjM54aunf29OfnNVh30GlRiBogZ/A+h++8fuyQKEBRDn/+EISfuH6i VxFlqx8K297K/em8Ro2Zd3r9GrVlR+7GbLchg9rj97Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=rRqM+t9mOdvLbcTkJFfjplh tKm4MwuNyhxvED/N6FIM0IWvUwlDz4FWZ0dBuInSHiGAWB2O4e+QkTzdNow9hKUA yx4Hk8NEh3pX1t6Xoxvzz2uLSE/iBTTPeMZKPPbVOxcNDgc8bbnMkbCOju+WJm2Q Unh89X8W46owQmP8SeWo= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 61AB0D788B; Sun, 11 Jun 2017 12:34:23 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1E5D9D1A7E7D; Sun, 11 Jun 2017 21:34:21 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_680EF184-902B-4F7E-9FD4-4A6C4A725ED1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 11 Jun 2017 21:34:20 +0200 In-Reply-To: <3C140AFE-6630-4767-99F7-06E1350160EB@consulintel.es> Cc: v6ops@ietf.org To: jordi.palet@consulintel.es References: <149720722498.13052.13287308290618949018.idtracker@ietfa.amsl.com> <3C140AFE-6630-4767-99F7-06E1350160EB@consulintel.es> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 19:34:26 -0000 --Apple-Mail=_680EF184-902B-4F7E-9FD4-4A6C4A725ED1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jordi, > This is not only going back to RFC6204, but in fact making it a much = simpler device, which is suitable also for scenarios where for sure = there will be for example =E2=80=9CIPv6-only=E2=80=9D sensors/devices, = etc. RFC6204 / RFC7084 does not specify the full functions of a complete = device. They have never been intended to be a full specification of a = CE. They _only_ specify the particular functions regarding IPv6. Ole --Apple-Mail=_680EF184-902B-4F7E-9FD4-4A6C4A725ED1 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZPZs8AAoJEL7aWKiYQt92yrYQALYX8Pn4qt0j6JkwWOO/ssmL WB8zUajXgniGl0rMdFqQpK0tTqK4Cl8j8EI4rrOq9Ia6tUQZyRvxsUy0Vv2Le6QQ kwIeDvMU27yumcAqiJESzTl8aurKEt35yWgTofRhS1N+RPl0L6aT5RFQcMdyQPKt 1QhqzKoed8R1wZVlR3zAdaJZNe5fTOoCSDNqyFPeac14ZbKGjK0jz8rDdWZl997L AnetJyFO53pVB3QTrRVAiAVoNswBoyzCVX5crC5Rw+HLoh8qjcfSEpDiCzBZ1dup gMcGcBVuBf5UYHFvdclOcthBXsVddHqThVmlmA48bTMfo+Bl9fDxBA2aVncYqFNJ BeFuDDW7N0h/7EKx2cKEKXyexGjYT1sAg2ZtZeID5s0HWczf+1gPIjljmSuLAOli 3U9hrL+2dnnPuRpYp1rV6kwos58aeCMGULUyQWT2DplWSQxiMXgnISpNlO02G1p/ NKlCFhGlOdi2E4FK8yeHbv0mcsH7vfxHpeKZlIfP/q7USfZZaNTiCUlb/8T3MT/N M91qrz4V3BedsgKnYTgFHgy+NJjka4REk08jOsCmjxHeKmfef0ETpXJgP6BZziGt 3ajRzemGJSvP3sqrMykzHwR8SuEuSg6xGc/5PFnrTtKlP4z4RMtqhYBIpTlPA+I8 Ci83Nr/s7XTeFsxwaIZ0 =vLlh -----END PGP SIGNATURE----- --Apple-Mail=_680EF184-902B-4F7E-9FD4-4A6C4A725ED1-- From nobody Sun Jun 11 12:39:58 2017 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 0169212702E for ; Sun, 11 Jun 2017 12:39:56 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOjzRRoDLylC for ; Sun, 11 Jun 2017 12:39:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109C61293E4 for ; Sun, 11 Jun 2017 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497209992; x=1497814792; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=7Gsi3cCP8ELmsOADi7KQojX9I vTHLBCOzUuf4NCjTkw=; b=mMI3xquztuLJwWGBGbMjDf50fQNppYY+8RMm3i19k On0vjdt8aYQASFvH8JQvMSxZcuIk5LT6F9ihdBxlDKUroxuNgtLnnQJt6t50Yt2o eBhbqAG/wcv1XR8g/DJckaHgBo+dAP8Yy4vvw6G+kCpzQtS3TX9UmQEsUBtzmMMD To= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kzyzWYNkwfqspcPDhb44LG3bhWaQntIbGeXQPiQUYSg/sSwSo/eJrZCM321W 3q8vSEagej5AQ2FTCEs0C8TDFryRzdGa2Ti7PJBeBasUmWHKnXcnhybja mP1aQoVx4jTWtTU0oSfUvcl3t5bky2wa7PMaWxGfW6E7rXUTObZaW4=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 21:39:52 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 21:39:51 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449169.msg for ; Sun, 11 Jun 2017 21:39:50 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449169::7kZKuPtPmPonK4YP:000009BG X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 21:39:46 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <9141ABD2-B9F2-439E-8B2F-DA9677F7AD04@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt References: <149720722498.13052.13287308290618949018.idtracker@ietfa.amsl.com> <3C140AFE-6630-4767-99F7-06E1350160EB@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis2-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 19:39:56 -0000 I know that. The question is, you agree with this path? Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: domingo, 11 de junio de 2017, 21:34 Para: CC: Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-= bis2-00.txt Jordi, =20 > This is not only going back to RFC6204, but in fact making it a much = simpler device, which is suitable also for scenarios where for sure there w= ill be for example =E2=80=9CIPv6-only=E2=80=9D sensors/devices, etc. =20 RFC6204 / RFC7084 does not specify the full functions of a complete dev= ice. They have never been intended to be a full specification of a CE. They= _only_ specify the particular functions regarding IPv6. =20 Ole =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 13:27:10 2017 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 297E0127698 for ; Sun, 11 Jun 2017 13:27:09 -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, 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 jfDrVxfu1_Jd for ; Sun, 11 Jun 2017 13:27:06 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7F51250B8 for ; Sun, 11 Jun 2017 13:27:06 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id f185so39101230pgc.0 for ; Sun, 11 Jun 2017 13:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OS5Db/Q7dIvPTMXFC/sGW3gh6yez12opvLjnxdfbUKc=; b=kWtpEc52OYs9PPf4q/YAVG2flJvKRTe6r3JjHIby3yk/AllThSi0U1zRhDUB7dx1BJ Rn9YIkfcGJlpmAMD3H8CLpKPybBVls4/xaPtZnAqy0F/FwYcoth9haRyKLABgazMOsc1 nKAXgT1Zy4rmUp3UC5fp2ePlRjkbNy/JRBOfsWUfVMesGjL8fXC5A/uEjqmTvfmUO/Ip O4g8kT/QIAF/49Wr9cvQhOeLRawVeV+D8/v/iz6cKowrRrPb1xZk9lRauvLbp0NRbMBX j8bTeJR94KymsEjFRJhszxDsobhxf/ZZtl8F+u79GcoSfJwmOES8piUNLKpRGsUO0Bpz jIog== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OS5Db/Q7dIvPTMXFC/sGW3gh6yez12opvLjnxdfbUKc=; b=kTbFxjNL8TcuRlwe0d4hZen/Q/JFNaJXBa7i9FWo4iHFQ1iU8NtL5qJTigijyARSFe 9lW2+c2HYQGOlXj5BORQzXzo64U2kSDWiPCnx9nUJOGwA1uXUdwOG0Ql5xa/PTzKAbry pBXp5C8Tl/xPE6Ikp8ihXmTwmcFSdTlNjB08H7P3Qn3qustf1+8p2+In766F3+l9wcbj FMfzrDdGr3ywvQNNIfgLmKNDdV57AAWV7+K+QmlKadDKbKB+eE+wPIBR/CgG/P+4E9cf z55v6vDFIPEf5MmSw+hL5t+1WyXc/S28AIbR6ATyA56+0zkr8vXkbpV1vlknZn87giEK Q5JA== X-Gm-Message-State: AODbwcA/Z575LXXDxouocPnLrVzaQtaHum5oSBiFYrxHDqv6ANSXd220 3g+uPBC8z2WP3S1c X-Received: by 10.84.232.197 with SMTP id x5mr52535533plm.248.1497212825618; Sun, 11 Jun 2017 13:27:05 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id 81sm13196384pge.46.2017.06.11.13.27.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 13:27:05 -0700 (PDT) To: v6ops@ietf.org References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 12 Jun 2017 08:27:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 20:27:09 -0000 On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > Hi Brian, >=20 > I don=E2=80=99t think the original intent of the document (even when it= was RFC6204 and even before that), was to exclude the support of more co= mplex topologies, but just to make sure that those mechanisms aren=E2=80=99= t described in the document itself. Fair enough.=20 =20 > And yes, if that=E2=80=99s the case, I agree that there is some text in= the abstract and intro that may preclude the support for HNCP, so this n= eeds to be changed. Right. I think it's important to set the reader's expectations accurately= in the first hundred words or so. Also this in 4.2. "IPv6 End-User Network Architecture": "The IPv6 CE router may be manually configured in an arbitrary topology with a dynamic routing protocol." should perhaps be extended to make it clear that HNCP is an option. =20 > I=E2=80=99m trying to confirm that I understand your point correctly, e= ither > 1) We have a very basic IPv6-only CE that ONLY allows hosts to connect = to it but no other routers behind it. > 2) We have non-so-basic IPv6 CE which allows host and automatically pro= visioned routers behind it. >=20 > I=E2=80=99m not making here considerations about transition mechanisms,= only if the basic CE, the one that most of the ISPs provide for =E2=80=9C= free=E2=80=9D to the customers, should support automatic provisioning (wi= th HNCP) or not? Personally, I don't want to encourage 1) because that is, basically, IPv4= with bigger addresses. The future should be 2). But I don't think this dr= aft is aiming to be a procurement spec for homenet, is it? It's more of a bas= eline for 2). And that's fine, as long as nobody reads it and thinks it's the end of the story. > Now, do we agree that scenario 1) is unrealistic in the near term? If w= e still want to define this case, shall it be something like =E2=80=9CMin= imum Requirements for IPv6-only Edge Routers=E2=80=9D, and even not consi= dering IPv4 support at all there =E2=80=A6 as this may be the case for ve= ry simple networks that only need to connect a few sensors and nothing el= se, etc. This is the case for new networks that are being deployed since = the start with IPv6-only in mind, and not considering IPv4 support at all= =2E Right, but will those really exist? I have no idea, personally. =20 > And then we can have a more realistic scenario for a =E2=80=9Ccustomer = oriented=E2=80=9D CE, which may have the need to HNCP (other routers may = need to be provisioned behind the main one), and has still some apps/devi= ces with IPv4 support (so transition mechanisms need to be supported for = those hosts to work in an IPv6-only access link). This may be what we hav= e as our actual =E2=80=9CBasic Requirements for IPv6 Customer Edge Router= s=E2=80=9D. That would be the "procurement spec for homenet". Are we ready to write t= hat today?? Regards, Brian =20 > What do you think? >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: domingo, 11 de junio de 2017, 3:54 > Para: Fred Baker > CC: IPv6 Operations > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > On 11/06/2017 08:55, Fred Baker wrote: > >=20 > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > >> "The end-user network is a stub network." > >> > >> That is no better capability or functionality than IP4. Apart fr= om > >> NAT, it's the same. > >> > >> So, naturally, HNCP and homenet is out of scope. > >=20 > > no hats > >=20 > > I'm not sure how you get from "stub network" to "no HNCP". The re= sidential network is a stub, which is to say it offers no transit service= s. Enterprise and university networks are also stubs; they offer no trans= it services. However, they can have a great deal of internal complexity. > >=20 > > Why does making the home offer no transit services preclude HNCP = and homenet? > =20 > It doesn't so my phrasing was a bit wrong. The point is that what t= he > draft describes is services to hosts, not services to hosts and add= itional > routers. IMHO, that should be made explicit in the title and abstra= ct and > the very beginning of the introduction, even sooner than: > =20 > "Automatic provisioning of more > complex topology than a single router with multiple LAN interfaces = is > out of scope for this document." > =20 > It's a truth in advertising issue, and it needs to leave the door > open for a future spec that does require support for more complex > topologies. > =20 > Brian > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that= any disclosure, copying, distribution or use of the contents of this inf= ormation, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Jun 11 13:38:09 2017 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 C0659127369 for ; Sun, 11 Jun 2017 13:38: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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4DKA_Z0mVnC for ; Sun, 11 Jun 2017 13:38:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CF31250B8 for ; Sun, 11 Jun 2017 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497213482; x=1497818282; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=gq1JF7EsMMGAEVS3or4J9ukox okXAP3gIeB/9pgXoXQ=; b=r4wG9+aLk4NprRCHSPz0QUZ7nrovFHO/jr7Ys5Web pGZDiaFk0e9fbQbGvBbxOhod5f5vu0bgSTO/K70JjO2jdCs2FKb+Xu4sjs5KfERH Hqi2nPlcusrsiMpwsJXwtWTAV1hly3dZ0/iMVLzt6RxgB7XLKeIjuawxmtAM86xa nc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=aTFbD1oP1LAVgsMPgs2XDkzBELuF7RdnJTRnO5Dpo/RgL16BfW7lBngmFJg+ 9ysMd43hDuAq0cAZ44/vv0Y4KsiVpc0mGSvaLQ51Xbn5/JMtac+A8igty i4RfoO/2FKOitgQmks7Vf4pnYzv6cHvVFhHGO53wDiEpUulGrBEtl8=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 22:38:02 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 22:38:01 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449178.msg for ; Sun, 11 Jun 2017 22:38:00 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449178::wu6JZNgdc6v/M5Ci:000001Gk X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 22:37:59 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 20:38:07 -0000 To make it short: My main motivation when I started working on this was not being a procureme= nt spec for homenet, but making sure that the actually deploying IPv6-only = links with support of IPv4 =E2=80=9Cas a service=E2=80=9D is possible, whic= h is not the case in the market. After that, I got inputs about the need for homenet, and then got convinced= that we should support it. I think that=E2=80=99s feasible just referencin= g to the HNCP document (as I did), but as you said, you found the intro, an= d other parts that contradict that. I=E2=80=99m still for a single document (draft-ietf-v6ops-rfc7084-bis-03), = so that will be the right place to correct the text with your suggestions. Regarding very cheap and simple IPv6-only routers, I think we will have the= n. There will be scenarios (probably very small homes or apartments) or rem= ote sensor networks, typically with a single link, where they will be neede= d, and I guess there HNCP is not needed at all. This is the document that I= submitted an hour ago. I=E2=80=99m not saying all those documents should go forward. We should tak= e a decision of what is the way to go =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: domingo, 11 de junio de 2017, 22:27 Para: Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > Hi Brian, >=20 > I don=E2=80=99t think the original intent of the document (even when = it was RFC6204 and even before that), was to exclude the support of more co= mplex topologies, but just to make sure that those mechanisms aren=E2=80=99= t described in the document itself. =20 Fair enough.=20 =20 > And yes, if that=E2=80=99s the case, I agree that there is some text = in the abstract and intro that may preclude the support for HNCP, so this n= eeds to be changed. =20 Right. I think it's important to set the reader's expectations accurate= ly in the first hundred words or so. =20 Also this in 4.2. "IPv6 End-User Network Architecture": "The IPv6 CE router may be manually configured in an arbitrary topology with a dynamic routing protocol." should perhaps be extended to make it clear that HNCP is an option. =20 > I=E2=80=99m trying to confirm that I understand your point correctly,= either > 1) We have a very basic IPv6-only CE that ONLY allows hosts to connec= t to it but no other routers behind it. > 2) We have non-so-basic IPv6 CE which allows host and automatically p= rovisioned routers behind it. >=20 > I=E2=80=99m not making here considerations about transition mechanism= s, only if the basic CE, the one that most of the ISPs provide for =E2=80= =9Cfree=E2=80=9D to the customers, should support automatic provisioning (w= ith HNCP) or not? =20 Personally, I don't want to encourage 1) because that is, basically, IP= v4 with bigger addresses. The future should be 2). But I don't think this = draft is aiming to be a procurement spec for homenet, is it? It's more of a b= aseline for 2). And that's fine, as long as nobody reads it and thinks it's the end of the story. =20 > Now, do we agree that scenario 1) is unrealistic in the near term? If= we still want to define this case, shall it be something like =E2=80=9CMin= imum Requirements for IPv6-only Edge Routers=E2=80=9D, and even not conside= ring IPv4 support at all there =E2=80=A6 as this may be the case for very s= imple networks that only need to connect a few sensors and nothing else, et= c. This is the case for new networks that are being deployed since the star= t with IPv6-only in mind, and not considering IPv4 support at all. =20 Right, but will those really exist? I have no idea, personally. =20 > And then we can have a more realistic scenario for a =E2=80=9Ccustome= r oriented=E2=80=9D CE, which may have the need to HNCP (other routers may = need to be provisioned behind the main one), and has still some apps/device= s with IPv4 support (so transition mechanisms need to be supported for thos= e hosts to work in an IPv6-only access link). This may be what we have as o= ur actual =E2=80=9CBasic Requirements for IPv6 Customer Edge Routers=E2=80= =9D. =20 That would be the "procurement spec for homenet". Are we ready to write= that today?? =20 Regards, Brian =20 > What do you think? >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: domingo, 11 de junio de 2017, 3:54 > Para: Fred Baker > CC: IPv6 Operations > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > On 11/06/2017 08:55, Fred Baker wrote: > >=20 > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > >> "The end-user network is a stub network." > >> > >> That is no better capability or functionality than IP4. Apart = from > >> NAT, it's the same. > >> > >> So, naturally, HNCP and homenet is out of scope. > >=20 > > no hats > >=20 > > I'm not sure how you get from "stub network" to "no HNCP". The = residential network is a stub, which is to say it offers no transit service= s. Enterprise and university networks are also stubs; they offer no transit= services. However, they can have a great deal of internal complexity. > >=20 > > Why does making the home offer no transit services preclude HNC= P and homenet? > =20 > It doesn't so my phrasing was a bit wrong. The point is that what= the > draft describes is services to hosts, not services to hosts and a= dditional > routers. IMHO, that should be made explicit in the title and abst= ract and > the very beginning of the introduction, even sooner than: > =20 > "Automatic provisioning of more > complex topology than a single router with multiple LAN interface= s is > out of scope for this document." > =20 > It's a truth in advertising issue, and it needs to leave the door > open for a future spec that does require support for more complex > topologies. > =20 > Brian > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 14:26:00 2017 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 ED140127F0E for ; Sun, 11 Jun 2017 14:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiWXS0JwI4-7 for ; Sun, 11 Jun 2017 14:25:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752A01200CF for ; Sun, 11 Jun 2017 14:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497216353; x=1497821153; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=6KNq1r8F3+2QF8X5GBuVw9p9B 6vxyOnvdpgPnKvUzzI=; b=pJwGEtQ6zKw4r/vYBZP5R5U6Guj8mwUh4aoqB/Ooo HsQ2LLcUfUjr+a0WSCsq6TMXEsjFu8JAao75J5CrFeSXSg7XbBOp5KAV2JstZENc uFTLw58enM1crWDFwygCHwe6AIAAuSiQ8Vyf4K/sArFTX3G8h55Fp+ZH4jonWvyH i4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kaK+LoNFCEvFjYYBpQWpO8nmP0NUnJPqL+YIzTbhwAYJl4LzppnlPqVGO6iA E4PRWTUXOiphER/l3/UUZqS6zUKEm+5OHOpdybIM97PU+dLfchVgPzd/4 FcdTaUk8HmOrGyEPWsTxkDN+pQeTESJR3thO/h0/A45a2LOtPhCfpE=; X-MDAV-Processed: mail.consulintel.es, Sun, 11 Jun 2017 23:25:53 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 11 Jun 2017 23:25:52 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449187.msg for ; Sun, 11 Jun 2017 23:25:50 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170611:md50005449187::gB1GmRNhb+PibLNB:000030qX X-Return-Path: prvs=1335b2396f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 11 Jun 2017 23:25:46 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <88747290-5541-4504-BE95-AD579659680D@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 21:25:59 -0000 Considering your inputs, I=E2=80=99ve summited a =E2=80=9Cmore conservative= =E2=80=9D version of RFC7084-bis with HNCP support and removing the transit= ion support, which will come in a new document. https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/ Opinions? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: domingo, 11 de junio de 2017, 22:27 Para: Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > Hi Brian, >=20 > I don=E2=80=99t think the original intent of the document (even when = it was RFC6204 and even before that), was to exclude the support of more co= mplex topologies, but just to make sure that those mechanisms aren=E2=80=99= t described in the document itself. =20 Fair enough.=20 =20 > And yes, if that=E2=80=99s the case, I agree that there is some text = in the abstract and intro that may preclude the support for HNCP, so this n= eeds to be changed. =20 Right. I think it's important to set the reader's expectations accurate= ly in the first hundred words or so. =20 Also this in 4.2. "IPv6 End-User Network Architecture": "The IPv6 CE router may be manually configured in an arbitrary topology with a dynamic routing protocol." should perhaps be extended to make it clear that HNCP is an option. =20 > I=E2=80=99m trying to confirm that I understand your point correctly,= either > 1) We have a very basic IPv6-only CE that ONLY allows hosts to connec= t to it but no other routers behind it. > 2) We have non-so-basic IPv6 CE which allows host and automatically p= rovisioned routers behind it. >=20 > I=E2=80=99m not making here considerations about transition mechanism= s, only if the basic CE, the one that most of the ISPs provide for =E2=80= =9Cfree=E2=80=9D to the customers, should support automatic provisioning (w= ith HNCP) or not? =20 Personally, I don't want to encourage 1) because that is, basically, IP= v4 with bigger addresses. The future should be 2). But I don't think this = draft is aiming to be a procurement spec for homenet, is it? It's more of a b= aseline for 2). And that's fine, as long as nobody reads it and thinks it's the end of the story. =20 > Now, do we agree that scenario 1) is unrealistic in the near term? If= we still want to define this case, shall it be something like =E2=80=9CMin= imum Requirements for IPv6-only Edge Routers=E2=80=9D, and even not conside= ring IPv4 support at all there =E2=80=A6 as this may be the case for very s= imple networks that only need to connect a few sensors and nothing else, et= c. This is the case for new networks that are being deployed since the star= t with IPv6-only in mind, and not considering IPv4 support at all. =20 Right, but will those really exist? I have no idea, personally. =20 > And then we can have a more realistic scenario for a =E2=80=9Ccustome= r oriented=E2=80=9D CE, which may have the need to HNCP (other routers may = need to be provisioned behind the main one), and has still some apps/device= s with IPv4 support (so transition mechanisms need to be supported for thos= e hosts to work in an IPv6-only access link). This may be what we have as o= ur actual =E2=80=9CBasic Requirements for IPv6 Customer Edge Routers=E2=80= =9D. =20 That would be the "procurement spec for homenet". Are we ready to write= that today?? =20 Regards, Brian =20 > What do you think? >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: domingo, 11 de junio de 2017, 3:54 > Para: Fred Baker > CC: IPv6 Operations > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > On 11/06/2017 08:55, Fred Baker wrote: > >=20 > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > >> "The end-user network is a stub network." > >> > >> That is no better capability or functionality than IP4. Apart = from > >> NAT, it's the same. > >> > >> So, naturally, HNCP and homenet is out of scope. > >=20 > > no hats > >=20 > > I'm not sure how you get from "stub network" to "no HNCP". The = residential network is a stub, which is to say it offers no transit service= s. Enterprise and university networks are also stubs; they offer no transit= services. However, they can have a great deal of internal complexity. > >=20 > > Why does making the home offer no transit services preclude HNC= P and homenet? > =20 > It doesn't so my phrasing was a bit wrong. The point is that what= the > draft describes is services to hosts, not services to hosts and a= dditional > routers. IMHO, that should be made explicit in the title and abst= ract and > the very beginning of the introduction, even sooner than: > =20 > "Automatic provisioning of more > complex topology than a single router with multiple LAN interface= s is > out of scope for this document." > =20 > It's a truth in advertising issue, and it needs to leave the door > open for a future spec that does require support for more complex > topologies. > =20 > Brian > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 11 18:56:40 2017 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 9AA771294B5 for ; Sun, 11 Jun 2017 18:56:39 -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 5m_vKPlwOhQk for ; Sun, 11 Jun 2017 18:56:36 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34F512949E for ; Sun, 11 Jun 2017 18:56:36 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 83so46083882pfr.0 for ; Sun, 11 Jun 2017 18:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XiEFVgqKzITqPfijztGXPWPL8mhC+vleHOADXIsQOPg=; b=Oz5HromW4LNoURK19QPgcITJrymYQaRbjqGINlib01xOYVoY3qG0QEge69yHzcBGTv N5GFoiRR6GZZir2+IzCeyw5hjiXNjJwhfERF4kviq0FTnfx21jDrRYMeCa+5bksAbQXj Gpkj3diBY/Bf3S+PH6LQeCjNWOPN4KaHFl88ifDpEC9Q/z1r7HstfX1CwMiYCRpzD1Q0 7VBiozhaMDp5S4AsANFNfD9YpjI3Ydr3earRYgsweR2hp7va1UOymQtnUvvNY2Mu04xb h/oqbh4Rxt+sX6lC3oe22jpL52Bg1GC/8jpcqUFHO7qaxFdii6IDtRvwUxfvXDVymelj dCeg== 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:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XiEFVgqKzITqPfijztGXPWPL8mhC+vleHOADXIsQOPg=; b=LRR841CAoY4C5WwaJZVmwTHOJcj5Y8S254uBERuO1OvxwflCrCAgbS97NfKl4EHrRe XN354yR057w+4H0gVvDso+vJ3eOkjSpNC1EQAN7yXzY3RbI8Lo7OHR3VJldCIVLBFd0w sUum6/nzF6DXhBWGJDsNmXxP0ef5HXGndF2NWWplAO6bvBEUSOFFOER69bx36EdId69L mEOBzYHHY+s63+aAJAymqt0BNfoMmNf9XB8QpKSBnfMKZ9FLfwTfZp0ruGAyW8t2aHqB 0aCSCXyhfTd4oc0jQNnMdfStS6e30IrENRyGN+44NMwDsUhFEGyeUX99PPSMWCIyQfl5 Kfnw== X-Gm-Message-State: AODbwcDY36ejBgq+qDOSY9Pio+YgHXpPqS92YcT7BBeWPvr549CwU0f+ UwZ4U1FEfoPoei0q X-Received: by 10.84.218.136 with SMTP id r8mr53680995pli.265.1497232595901; Sun, 11 Jun 2017 18:56:35 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id w3sm14205010pfw.19.2017.06.11.18.56.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 18:56:34 -0700 (PDT) To: jordi.palet@consulintel.es References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> <88747290-5541-4504-BE95-AD579659680D@consulintel.es> From: Brian E Carpenter Organization: University of Auckland Cc: v6ops@ietf.org Message-ID: <5149a791-3891-5c3f-14c3-b07e365bb18f@gmail.com> Date: Mon, 12 Jun 2017 13:56:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <88747290-5541-4504-BE95-AD579659680D@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 01:56:39 -0000 Hi Jordi, I think you are saying that there are several theoretically independent components here: #1. A vanilla CE router that simply support an IPv6 provider, and IPv6 ho= sts on directly attached /64 subnets. #2. IPv4 coexistence (with multiple possible solutions on the provider si= de) #3. IPv6 subnetting and routing on the customer side (by default, support= ed by HNCP and BABEL). You are proposing three drafts, for cases #1 #1+#2 #1+#3 You don't have a draft for #1+#2+#3 Have I understood correctly? If yes, we should perhaps discuss whether that's the best document struct= ure. Regards Brian Regards Brian Carpenter On 12/06/2017 09:25, JORDI PALET MARTINEZ wrote: > Considering your inputs, I=E2=80=99ve summited a =E2=80=9Cmore conserva= tive=E2=80=9D version of RFC7084-bis with HNCP support and removing the t= ransition support, which will come in a new document. >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/ >=20 > Opinions? >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: domingo, 11 de junio de 2017, 22:27 > Para: > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > > Hi Brian, > >=20 > > I don=E2=80=99t think the original intent of the document (even w= hen it was RFC6204 and even before that), was to exclude the support of m= ore complex topologies, but just to make sure that those mechanisms aren=E2= =80=99t described in the document itself. > =20 > Fair enough.=20 > =20 > > And yes, if that=E2=80=99s the case, I agree that there is some t= ext in the abstract and intro that may preclude the support for HNCP, so = this needs to be changed. > =20 > Right. I think it's important to set the reader's expectations accu= rately in > the first hundred words or so. > =20 > Also this in 4.2. "IPv6 End-User Network Architecture": > "The IPv6 CE router may be manually configured in an arbitrary > topology with a dynamic routing protocol." > should perhaps be extended to make it clear that HNCP is an option.= > =20 > > I=E2=80=99m trying to confirm that I understand your point correc= tly, either > > 1) We have a very basic IPv6-only CE that ONLY allows hosts to co= nnect to it but no other routers behind it. > > 2) We have non-so-basic IPv6 CE which allows host and automatical= ly provisioned routers behind it. > >=20 > > I=E2=80=99m not making here considerations about transition mecha= nisms, only if the basic CE, the one that most of the ISPs provide for =E2= =80=9Cfree=E2=80=9D to the customers, should support automatic provisioni= ng (with HNCP) or not? > =20 > Personally, I don't want to encourage 1) because that is, basically= , IPv4 > with bigger addresses. The future should be 2). But I don't think t= his draft > is aiming to be a procurement spec for homenet, is it? It's more of= a baseline > for 2). And that's fine, as long as nobody reads it and thinks it's= the > end of the story. > =20 > > Now, do we agree that scenario 1) is unrealistic in the near term= ? If we still want to define this case, shall it be something like =E2=80= =9CMinimum Requirements for IPv6-only Edge Routers=E2=80=9D, and even not= considering IPv4 support at all there =E2=80=A6 as this may be the case = for very simple networks that only need to connect a few sensors and noth= ing else, etc. This is the case for new networks that are being deployed = since the start with IPv6-only in mind, and not considering IPv4 support = at all. > =20 > Right, but will those really exist? I have no idea, personally. > =20 > > And then we can have a more realistic scenario for a =E2=80=9Ccus= tomer oriented=E2=80=9D CE, which may have the need to HNCP (other router= s may need to be provisioned behind the main one), and has still some app= s/devices with IPv4 support (so transition mechanisms need to be supporte= d for those hosts to work in an IPv6-only access link). This may be what = we have as our actual =E2=80=9CBasic Requirements for IPv6 Customer Edge = Routers=E2=80=9D. > =20 > That would be the "procurement spec for homenet". Are we ready to w= rite that today?? > =20 > Regards, > Brian > =20 > > What do you think? > >=20 > > Regards, > > Jordi > > =20 > >=20 > > -----Mensaje original----- > > De: v6ops en nombre de Brian E Carpenter= > > Organizaci=C3=B3n: University of Auckland > > Responder a: > > Fecha: domingo, 11 de junio de 2017, 3:54 > > Para: Fred Baker > > CC: IPv6 Operations > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.t= xt > >=20 > > On 11/06/2017 08:55, Fred Baker wrote: > > >=20 > > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > > >> "The end-user network is a stub network." > > >> > > >> That is no better capability or functionality than IP4. Ap= art from > > >> NAT, it's the same. > > >> > > >> So, naturally, HNCP and homenet is out of scope. > > >=20 > > > no hats > > >=20 > > > I'm not sure how you get from "stub network" to "no HNCP". = The residential network is a stub, which is to say it offers no transit s= ervices. Enterprise and university networks are also stubs; they offer no= transit services. However, they can have a great deal of internal comple= xity. > > >=20 > > > Why does making the home offer no transit services preclude= HNCP and homenet? > > =20 > > It doesn't so my phrasing was a bit wrong. The point is that = what the > > draft describes is services to hosts, not services to hosts a= nd additional > > routers. IMHO, that should be made explicit in the title and = abstract and > > the very beginning of the introduction, even sooner than: > > =20 > > "Automatic provisioning of more > > complex topology than a single router with multiple LAN inter= faces is > > out of scope for this document." > > =20 > > It's a truth in advertising issue, and it needs to leave the = door > > open for a future spec that does require support for more com= plex > > topologies. > > =20 > > Brian > > =20 > > =20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > =20 > > =20 > >=20 > >=20 > >=20 > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > >=20 > > This electronic message contains information which may be privile= ged or confidential. The information is intended to be for the use of the= individual(s) named above. If you are not the intended recipient be awar= e that any disclosure, copying, distribution or use of the contents of th= is information, including attached files, is prohibited. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > =20 > _______________________________________________ > 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.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that= any disclosure, copying, distribution or use of the contents of this inf= ormation, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Jun 11 23:59:01 2017 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 622A8128A32 for ; Sun, 11 Jun 2017 23:59:00 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K55Gld_bWzf for ; Sun, 11 Jun 2017 23:58:57 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6941289B0 for ; Sun, 11 Jun 2017 23:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497250733; x=1497855533; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=hwfRA7FKr3E5+kiAeDokGiNfc 2Duh2pIRUyjUao8QkQ=; b=AL5+SGqc8wk4I9z/k8aXM4lFj4p0wrGSc/N25k0vS X++jWXLl73Wym0KSL3xQVpfOHKItEV9Wc90wv/IAlnzlXhoNbvtYGsaZzkd9GYo8 R3ob1NkFR58V5qWbZIsybJ59JlSaAUdho/4+gPo60UEKF53Cf2PBvrDWDfGqzfoC kE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=SoBiTUOJ45R/W1az6b7l8doYcxCDnc89PCwVKv0uK1wvS7CBQdOLX2Sb9gwi WiwcHIuJveLB1FKaIbyIaiLwLkb7ngcA5c5Vlr11CZOjQqjnDe9iCqZcM 9fjqyXlIfY70UMnzQs9K7HhZghG8PLs/cnx4STJYtZFb1HWvXjrYD0=; X-MDAV-Processed: mail.consulintel.es, Mon, 12 Jun 2017 08:58:53 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 12 Jun 2017 08:58:52 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449281.msg for ; Mon, 12 Jun 2017 08:58:51 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170612:md50005449281::NJFddx1O0mbxYwew:0000CmZn X-Return-Path: prvs=1336cd027b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 12 Jun 2017 08:58:48 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> <88747290-5541-4504-BE95-AD579659680D@consulintel.es> <5149a791-3891-5c3f-14c3-b07e365bb18f@gmail.com> In-Reply-To: <5149a791-3891-5c3f-14c3-b07e365bb18f@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 06:59:00 -0000 Hi Brian, Not exactly: #1. A vanilla CE router that simply support an IPv6 provider, and IPv6 host= s on directly attached /64 subnets. #2. IPv6 subnetting and routing on the customer side (by default, supported by HNCP and BABEL). #3. IPv4 coexistence (this is =E2=80=9Cdiff=E2=80=9D from the actual https:= //datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ - either #1 or #2,= so it will be just coexistentce or coexistence+HNCP. I will cook it today = =E2=80=A6) I still believe that only one document should be enough, that will be #1+2+= 3 and this one is https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084= -bis/ This was discussed in the list and in the Chicago meeting and I understood = we agreed on that =E2=80=A6 However, if now we don't agree on that (3-4 peo= ple voiced against that), then I think we need to choose among #1 OR #2 (th= ose are the 2 ID=E2=80=99s that I submitted yesterday). So clearly, we need a WG decision if we still agree on what we decided a co= uple of months ago, or we have now a different view =E2=80=A6 Saludos, Jordi =20 -----Mensaje original----- De: Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: lunes, 12 de junio de 2017, 3:56 Para: CC: Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt Hi Jordi, =20 I think you are saying that there are several theoretically independent components here: =20 #1. A vanilla CE router that simply support an IPv6 provider, and IPv6 = hosts on directly attached /64 subnets. =20 #2. IPv4 coexistence (with multiple possible solutions on the provider = side) =20 #3. IPv6 subnetting and routing on the customer side (by default, suppo= rted by HNCP and BABEL). =20 You are proposing three drafts, for cases #1 #1+#2 #1+#3 =20 You don't have a draft for #1+#2+#3 =20 Have I understood correctly? =20 If yes, we should perhaps discuss whether that's the best document stru= cture. =20 Regards Brian =20 Regards Brian Carpenter =20 =20 =20 On 12/06/2017 09:25, JORDI PALET MARTINEZ wrote: > Considering your inputs, I=E2=80=99ve summited a =E2=80=9Cmore conser= vative=E2=80=9D version of RFC7084-bis with HNCP support and removing the t= ransition support, which will come in a new document. >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/ >=20 > Opinions? >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: domingo, 11 de junio de 2017, 22:27 > Para: > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > > Hi Brian, > >=20 > > I don=E2=80=99t think the original intent of the document (even= when it was RFC6204 and even before that), was to exclude the support of m= ore complex topologies, but just to make sure that those mechanisms aren=E2= =80=99t described in the document itself. > =20 > Fair enough.=20 > =20 > > And yes, if that=E2=80=99s the case, I agree that there is some= text in the abstract and intro that may preclude the support for HNCP, so = this needs to be changed. > =20 > Right. I think it's important to set the reader's expectations ac= curately in > the first hundred words or so. > =20 > Also this in 4.2. "IPv6 End-User Network Architecture": > "The IPv6 CE router may be manually configured in an arbitrary > topology with a dynamic routing protocol." > should perhaps be extended to make it clear that HNCP is an optio= n. > =20 > > I=E2=80=99m trying to confirm that I understand your point corr= ectly, either > > 1) We have a very basic IPv6-only CE that ONLY allows hosts to = connect to it but no other routers behind it. > > 2) We have non-so-basic IPv6 CE which allows host and automatic= ally provisioned routers behind it. > >=20 > > I=E2=80=99m not making here considerations about transition mec= hanisms, only if the basic CE, the one that most of the ISPs provide for = =E2=80=9Cfree=E2=80=9D to the customers, should support automatic provision= ing (with HNCP) or not? > =20 > Personally, I don't want to encourage 1) because that is, basical= ly, IPv4 > with bigger addresses. The future should be 2). But I don't think= this draft > is aiming to be a procurement spec for homenet, is it? It's more = of a baseline > for 2). And that's fine, as long as nobody reads it and thinks it= 's the > end of the story. > =20 > > Now, do we agree that scenario 1) is unrealistic in the near te= rm? If we still want to define this case, shall it be something like =E2=80= =9CMinimum Requirements for IPv6-only Edge Routers=E2=80=9D, and even not c= onsidering IPv4 support at all there =E2=80=A6 as this may be the case for = very simple networks that only need to connect a few sensors and nothing el= se, etc. This is the case for new networks that are being deployed since th= e start with IPv6-only in mind, and not considering IPv4 support at all. > =20 > Right, but will those really exist? I have no idea, personally. > =20 > > And then we can have a more realistic scenario for a =E2=80=9Cc= ustomer oriented=E2=80=9D CE, which may have the need to HNCP (other router= s may need to be provisioned behind the main one), and has still some apps/= devices with IPv4 support (so transition mechanisms need to be supported fo= r those hosts to work in an IPv6-only access link). This may be what we hav= e as our actual =E2=80=9CBasic Requirements for IPv6 Customer Edge Routers= =E2=80=9D. > =20 > That would be the "procurement spec for homenet". Are we ready to= write that today?? > =20 > Regards, > Brian > =20 > > What do you think? > >=20 > > Regards, > > Jordi > > =20 > >=20 > > -----Mensaje original----- > > De: v6ops en nombre de Brian E Carpent= er > > Organizaci=C3=B3n: University of Auckland > > Responder a: > > Fecha: domingo, 11 de junio de 2017, 3:54 > > Para: Fred Baker > > CC: IPv6 Operations > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03= .txt > >=20 > > On 11/06/2017 08:55, Fred Baker wrote: > > >=20 > > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > > >> "The end-user network is a stub network." > > >> > > >> That is no better capability or functionality than IP4. = Apart from > > >> NAT, it's the same. > > >> > > >> So, naturally, HNCP and homenet is out of scope. > > >=20 > > > no hats > > >=20 > > > I'm not sure how you get from "stub network" to "no HNCP"= . The residential network is a stub, which is to say it offers no transit s= ervices. Enterprise and university networks are also stubs; they offer no t= ransit services. However, they can have a great deal of internal complexity= . > > >=20 > > > Why does making the home offer no transit services preclu= de HNCP and homenet? > > =20 > > It doesn't so my phrasing was a bit wrong. The point is tha= t what the > > draft describes is services to hosts, not services to hosts= and additional > > routers. IMHO, that should be made explicit in the title an= d abstract and > > the very beginning of the introduction, even sooner than: > > =20 > > "Automatic provisioning of more > > complex topology than a single router with multiple LAN int= erfaces is > > out of scope for this document." > > =20 > > It's a truth in advertising issue, and it needs to leave th= e door > > open for a future spec that does require support for more c= omplex > > topologies. > > =20 > > Brian > > =20 > > =20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > =20 > > =20 > >=20 > >=20 > >=20 > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > >=20 > > This electronic message contains information which may be privi= leged or confidential. The information is intended to be for the use of the= individual(s) named above. If you are not the intended recipient be aware = that any disclosure, copying, distribution or use of the contents of this i= nformation, including attached files, is prohibited. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > =20 > _______________________________________________ > 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.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > 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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Jun 12 01:23:44 2017 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 512B61273B1 for ; Mon, 12 Jun 2017 01:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 j5YgdAOvuHK4 for ; Mon, 12 Jun 2017 01:23:41 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFACF129C4B for ; Mon, 12 Jun 2017 01:23:40 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id ECCC2200F9; Mon, 12 Jun 2017 10:23:38 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id C90C41A0064; Mon, 12 Jun 2017 10:23:38 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM71.corporate.adroot.infra.ftgroup ([fe80::d559:a7fd:890d:dd99%21]) with mapi id 14.03.0339.000; Mon, 12 Jun 2017 10:23:38 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt Thread-Index: AQHS4dW+hTydLRpwoEKEuXguyLnvMKIg5mGw Date: Mon, 12 Jun 2017 08:23:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009FE10B6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <149606921435.3762.14727398533646344700@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E76580@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:23:43 -0000 SGkgSm9yZGksIA0KDQpUaGFuayB5b3UgZm9yIHRha2luZyBjYXJlIG9mIHRoZSBjb21tZW50cy4g DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKg OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSk9S REkgUEFMRVQNCj4gTUFSVElORVoNCj4gRW52b3nDqcKgOiBzYW1lZGkgMTAganVpbiAyMDE3IDEy OjM4DQo+IMOAwqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMtMDIudHh0DQo+IA0KPiBIaSBNb2hh bWVkLA0KPiANCj4gSSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gd2hpY2ggdGhlIGZvbGxv d2luZyBjaGFuZ2VzDQo+IA0KPiAgICAxLiAgTFc0TzYtNSByZW1vdmVkLCB3YXMgYSBtaXN0YWtl IGR1ZSB0byBjb3B5LXBhc3RlIGZyb20gRFMtTElURS4NCj4gDQo+ICAgIDIuICBSZW1vdmVkIGNp dGF0aW9uIHRvIGluZGl2aWR1YWwgSS1EcyBmb3IgREhDUHY2IG9wdGlvbnMuDQo+IA0KPiBPZiBj b3Vyc2UsIHlvdSB3ZXJlIHJpZ2h0IHJlZ2FyZGluZyBMVzQwNi01LCBnb29kIGNhdGNoLCBpdCB3 YXMgdGhlIGNvbW1vbg0KPiBjb3B5L3Bhc3RlIGlzc3VlIOKApg0KPiANCj4gSSBhbHNvIHJlbW92 ZWQgdGhlIHJlZmVyZW5jZSB0byB0aGUgaW5kaXZpZHVhbCBJLUQuDQo+IA0KPiBSZWdhcmRpbmcg b2Jzb2xldGluZyBvciB1cGRhdGluZywgSSB0aGluayB0aGlzIHJlcXVpcmVzIHNvbWUgbW9yZQ0K PiBkaXNjdXNzaW9uLCBhbHNvIGNvbnNpZGVyaW5nIHRoZSBvdGhlciBjb21tZW50cyByZWNlaXZl ZCBpbiB0aGUgbGlzdC4NCj4gTGV04oCZcyBhcHByb2FjaCB0aGF0IGluIHRoZSBuZXh0IHdlZWtz Lg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9w cy1yZmM3MDg0LQ0KPiBiaXMvP2luY2x1ZGVfdGV4dD0xDQo+IA0KPiBSZWdhcmRzLA0KPiBKb3Jk aQ0KPiANCj4gDQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiA8bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gUmVzcG9uZGVyIGE6IDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KPiBGZWNoYTogbWnDqXJjb2xlcywgMzEgZGUgbWF5byBkZSAyMDE3LCAxMDox MA0KPiBQYXJhOiAiam9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXMiIDxqb3JkaS5wYWxldEBjb25z dWxpbnRlbC5lcz4sDQo+ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0KPiBBc3Vu dG86IFJFOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMt MDIudHh0DQo+IA0KPiAgICAgSGkgSm9yZGksDQo+IA0KPiAgICAgVGhhbmsgeW91IGZvciB1cGRh dGluZyB0aGUgZHJhZnQuIEJlbG93IHRoZSBjb21tZW50cyB0aGF0IEkgZG8gdGhpbmsNCj4gYXJl IHN0aWxsIG9wZW46DQo+IA0KPiAgICAgKiBSZW1vdmUgY2l0YXRpb25zIHRvIGluZGl2aWR1YWwg SS1EcyBmcm9tIHRoZSBkcmFmdC4NCj4gICAgICogSSdtIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQg dGhlIG1vdGl2YXRpb24gZm9yIExXNE82LTUuIFBsZWFzZSBub3RlDQo+IHRoYXQgdGhpcyBpcyBu b3QgZXF1aXZhbGVudCB0byBEU0xJVEUtNCBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCBpbiBE Uy0NCj4gTGl0ZSB0aGVyZSBhcmUgbm8gSVB2NCBhZGRyZXNzIGFzc2lnbmVkIHRvIHRoZSBDUEUg ZnJvbSB0aGUgbmV0d29yaywgd2hpbGUNCj4gdGhlcmUgaXMgb25lIGZvciBsdzRvNi4gSSBzdWdn ZXN0IHRvIGRlbGV0ZSBMVzRPNi01Lg0KPiAgICAgKiBVbmxlc3MgSSdtIG1pc3Rha2VuLCBJIGRv bid0IHJlbWVtYmVyIHRoZXJlIHdhcyBhIGNvbmNsdXNpb24gYWJvdXQNCj4gb2Jzb2xldGluZyBS RkM3MDg0IG9yIG5vdC4NCj4gDQo+ICAgICBDaGVlcnMsDQo+ICAgICBNZWQNCj4gDQo+ICAgICA+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiAgICAgPiBEZSA6IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKT1JESSBQQUxFVA0KPiAgICAg PiBNQVJUSU5FWg0KPiAgICAgPiBFbnZvecOpIDogbHVuZGkgMjkgbWFpIDIwMTcgMTY6NTQNCj4g ICAgID4gw4AgOiB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMtMDIudHh0DQo+ICAgICA+DQo+ ICAgICA+IEhpIGFsbCwNCj4gICAgID4NCj4gICAgID4gVGhpcyBpcyBhbiB1cGRhdGVkIHZlcnNp b24gb2YgdGhpcyBkb2N1bWVudCwgaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmcNCj4gICAgID4gY2hh bmdlczoNCj4gICAgID4NCj4gICAgID4gMTEuICBBTk5FWCBEOiBDaGFuZ2VzIGZyb20gUkZDNzA4 NC1iaXMtMDENCj4gICAgID4NCj4gICAgID4gICAgU2VjdGlvbiB0byBiZSByZW1vdmVkIGZvciBX R0xDLiAgU2lnbmlmaWNhbnQgdXBkYXRlcyBhcmU6DQo+ICAgICA+DQo+ICAgICA+ICAgIDEuICBH LTUgYWRkZWQgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggW1JGQzc2MDhdLg0KPiAgICAgPg0KPiAg ICAgPiAgICAyLiAgTFc0TzYtNSByZW1vdmVkLg0KPiAgICAgPg0KPiAgICAgPiAgICAzLiAgTUFQ RS0zIHJlbW92ZWQuDQo+ICAgICA+DQo+ICAgICA+ICAgIDQuICBNQVBULTMgcmVtb3ZlZC4NCj4g ICAgID4NCj4gICAgID4gICAgNS4gIEluY2x1ZGVkIG5vbi1ub3JtYXRpdmUgcmVmZXJlbmNlIHRv IFtSRkM3ODQ5XSB0byBjbGFyaWZ5IHRoYXQNCj4gdGhlDQo+ICAgICA+ICAgICAgICBkZXRhaWxz IG9mIHRoZSBjb25uZWN0aXZpdHkgdG8gM0dQUC9MVEUgbmV0d29ya3MgaXMgb3V0IG9mDQo+IHRo ZQ0KPiAgICAgPiBzY29wZS4NCj4gICAgID4NCj4gICAgID4gICAgNi4gIFNwbGl0IG9mIHRyYW5z aXRpb24gaW4gdHdvIHN1Yi1zZWN0aW9ucyBmb3IgdGhlIHNha2Ugb2YNCj4gY2xhcml0eS4NCj4g ICAgID4NCj4gICAgID4gMiwgMyBhbmQgNCBhYm92ZSAoYWRkZWQgaW4gdGhlIHByZXZpb3VzIHZl cnNpb24pIHdlcmUgcmVmZXJyaW5nIHRvDQo+IHRoZQ0KPiAgICAgPiBleHBsaWNpdCBtZW50aW9u IG9mIE5BVCBiZWhhdmlvci4gQXMgZWFjaCBtZWNoYW5pc20gaGFzIHRoZSByZWxldmFudA0KPiB0 ZXh0DQo+ICAgICA+IGluIGl0cyByZXNwZWN0aXZlIFJGQywgSSBsZWF2ZSB0aGF0IHRvIHRob3Nl IGRvY3VtZW50cywgdG8gYXZvaWQgYW55DQo+ICAgICA+IG1pc3VuZGVyc3RhbmRpbmcgb3IgY29u ZmxpY3QuDQo+ICAgICA+DQo+ICAgICA+IFJlZ2FyZHMsDQo+ICAgICA+IEpvcmRpDQo+ICAgICA+ DQo+ICAgICA+DQo+ICAgICA+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+ICAgICA+IERl OiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIDxpbnRlcm5ldC0N Cj4gZHJhZnRzQGlldGYub3JnPg0KPiAgICAgPiBSZXNwb25kZXIgYTogPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NCj4gICAgID4gRmVjaGE6IGx1bmVzLCAyOSBkZSBtYXlvIGRlIDIwMTcsIDEx OjQ2DQo+ICAgICA+IFBhcmE6IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+ICAgICA+IENDOiA8 djZvcHNAaWV0Zi5vcmc+DQo+ICAgICA+IEFzdW50bzogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXY2b3BzLXJmYzcwODQtYmlzLTAyLnR4dA0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAg PiAgICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtDQo+IERyYWZ0cw0KPiAgICAgPiBkaXJlY3Rvcmllcy4NCj4gICAgID4gICAgIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBvZiB0aGUgSUVU Ri4NCj4gICAgID4NCj4gICAgID4gICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogQmFzaWMg UmVxdWlyZW1lbnRzIGZvciBJUHY2IEN1c3RvbWVyDQo+IEVkZ2UNCj4gICAgID4gUm91dGVycw0K PiAgICAgPiAgICAgICAgICAgICBBdXRob3IgICAgICAgICAgOiBKb3JkaSBQYWxldCBNYXJ0aW5l eg0KPiAgICAgPiAgICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4 NC1iaXMtMDIudHh0DQo+ICAgICA+ICAgICAJUGFnZXMgICAgICAgICAgIDogMzANCj4gICAgID4g ICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA1LTI5DQo+ICAgICA+DQo+ICAgICA+ICAgICBB YnN0cmFjdDoNCj4gICAgID4gICAgICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVpcmVt ZW50cyBmb3IgYW4gSVB2NiBDdXN0b21lcg0KPiBFZGdlIChDRSkNCj4gICAgID4gICAgICAgIHJv dXRlci4gIFNwZWNpZmljYWxseSwgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50 DQo+IGZvY3VzZXMNCj4gICAgID4gICAgICAgIG9uIHRoZSBiYXNpYyBwcm92aXNpb25pbmcgb2Yg YW4gSVB2NiBDRSByb3V0ZXIgYW5kIHRoZQ0KPiBwcm92aXNpb25pbmcNCj4gICAgID4gICAgICAg IG9mIElQdjYgaG9zdHMgYXR0YWNoZWQgdG8gaXQuICBUaGUgZG9jdW1lbnQgYWxzbyBjb3ZlcnMN Cj4gc2V2ZXJhbA0KPiAgICAgPiAgICAgICAgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMsIGFzIHJl cXVpcmVkIGluIGEgd29ybGQgd2hlcmUgSVB2NA0KPiAgICAgPiBhZGRyZXNzZXMNCj4gICAgID4g ICAgICAgIGFyZSBubyBsb25nZXIgYXZhaWxhYmxlLCBzbyBob3N0cyBpbiB0aGUgY3VzdG9tZXIg TEFOcyB3aXRoDQo+IElQdjQtDQo+ICAgICA+IG9ubHkNCj4gICAgID4gICAgICAgIG9yIElQdjYt b25seSBhcHBsaWNhdGlvbnMgb3IgZGV2aWNlcywgcmVxdWlyaW5nIHRvDQo+IGNvbW11bmljYXRl IHdpdGgNCj4gICAgID4gICAgICAgIElQdjQtb25seSBzZXJ2aWNlcyBhdCB0aGUgSW50ZXJuZXQs IGFyZSBhYmxlIHRvIGRvIHNvLiAgVGhlDQo+ICAgICA+IGRvY3VtZW50DQo+ICAgICA+ICAgICAg ICBvYnNvbGV0ZXMgUkZDIDcwODQuDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gICAgID4g ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtcmZj NzA4NC1iaXMvDQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ICAgICA+ICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1yZmM3MDg0LWJpcy0wMg0KPiAgICAgPiAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXJmYzcwODQt DQo+IGJpcy0wMg0KPiAgICAgPg0KPiAgICAgPiAgICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMtDQo+IDAyDQo+ICAg ICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZQ0KPiBvZg0KPiAgICAgPiBzdWJtaXNzaW9u DQo+ICAgICA+ICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiAgICAgPg0KPiAgICAgPiAgICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiAgICAg PiAgICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gICAgID4NCj4gICAg ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ICAgICA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAgIHY2b3BzQGlldGYub3Jn DQo+ICAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gICAgID4gSVB2 NCBpcyBvdmVyDQo+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0K PiAgICAgPiBodHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQo+ICAgICA+IFRoZSBJUHY2IENvbXBh bnkNCj4gICAgID4NCj4gICAgID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQNCj4gb3INCj4gICAgID4gY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhl DQo+ICAgICA+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgYmUNCj4gYXdhcmUNCj4gICAgID4gdGhhdCBhbnkgZGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YNCj4gdGhp cw0KPiAgICAgPiBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9o aWJpdGVkLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBpcyBvdmVyDQo+ IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8vd3d3LmNvbnN1 bGludGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNv bmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNl IG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlDQo+IHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlp bmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMNCj4gaW5mb3Jt YXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g djZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Jun 12 01:41:20 2017 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 6E5BA1293D6; Mon, 12 Jun 2017 01:41:12 -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.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149725687240.10251.17883808298330157987@ietfa.amsl.com> Date: Mon, 12 Jun 2017 01:41:12 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:41:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-04.txt Pages : 31 Date : 2017-06-12 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it and the support of HNCP ([RFC7788]) for automated provisioning of downstream routers. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 12 01:44:21 2017 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 9B4B4129C5E for ; Mon, 12 Jun 2017 01:44:19 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3ejclJIvmY5 for ; Mon, 12 Jun 2017 01:44:17 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38653129C56 for ; Mon, 12 Jun 2017 01:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497257055; x=1497861855; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=ln+GFy1+zkVMxiY+xoYR63gQ4 +UtPhJPtl5HLryvAFE=; b=srT18RGzF99g5mjm2ISFd9Zy+jG8NQSay3UClZcOR 0UuDqBAfslMyYXBj+9hyQPHI24sBDYPcX4aOTG8sxj5hz1qOHgfUdLqkfeyqEvE7 Tr9MguBjqUhiOLNi90oQU7bf90CfalfyJAbIdP8FpeO20ax1ACD6nO1b24b0sZ/N ck= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Kb1HapYWc5pz9bQQer6gH+S80wnQeoHOlhvE9FsTU+yPRnzEYHD0i1XDbgow R4ra+LFSnidwcldFEQ+JZ53IuZdO4/aRNZXxfydlCr3i62Llj29UWItJn zAJBIWt2cg9OqHGRt35l3dqvgs2oe/z7hsn4+VRuVzwE0jPf6QzzU0=; X-MDAV-Processed: mail.consulintel.es, Mon, 12 Jun 2017 10:44:15 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 12 Jun 2017 10:44:14 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449339.msg for ; Mon, 12 Jun 2017 10:44:13 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170612:md50005449339::VIvH5aOH2XzdUoCq:00006pzx X-Return-Path: prvs=1336cd027b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 12 Jun 2017 10:44:08 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <871023AF-5D40-43AF-A56E-78B0B7F428E2@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt References: <149606921435.3762.14727398533646344700@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E76580@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009FE10B6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009FE10B6@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:44:20 -0000 Actually, thanks to you for all your inputs! I just uploaded a new version, just considering the clarifications suggeste= d by Brian regarding support of =E2=80=9Cinternal/downstream=E2=80=9D route= rs. https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/?include_text= =3D1 I didn't change the =E2=80=9Ctitle=E2=80=9D as I think still makes sense if= we decide to keep going this path =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: lunes, 12 de junio de 2017, 10:23 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt Hi Jordi,=20 =20 Thank you for taking care of the comments.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=C3=A9 : samedi 10 juin 2017 12:38 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 > Hi Mohamed, >=20 > I just uploaded a new version which the following changes >=20 > 1. LW4O6-5 removed, was a mistake due to copy-paste from DS-LITE. >=20 > 2. Removed citation to individual I-Ds for DHCPv6 options. >=20 > Of course, you were right regarding LW406-5, good catch, it was the c= ommon > copy/paste issue =E2=80=A6 >=20 > I also removed the reference to the individual I-D. >=20 > Regarding obsoleting or updating, I think this requires some more > discussion, also considering the other comments received in the list. > Let=E2=80=99s approach that in the next weeks. >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084- > bis/?include_text=3D1 >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: > Responder a: > Fecha: mi=C3=A9rcoles, 31 de mayo de 2017, 10:10 > Para: "jordi.palet@consulintel.es" , > "v6ops@ietf.org" > Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 > Hi Jordi, >=20 > Thank you for updating the draft. Below the comments that I do th= ink > are still open: >=20 > * Remove citations to individual I-Ds from the draft. > * I'm not sure to understand the motivation for LW4O6-5. Please n= ote > that this is not equivalent to DSLITE-4 for the simple reason that in= DS- > Lite there are no IPv4 address assigned to the CPE from the network, = while > there is one for lw4o6. I suggest to delete LW4O6-5. > * Unless I'm mistaken, I don't remember there was a conclusion ab= out > obsoleting RFC7084 or not. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI = PALET > > MARTINEZ > > Envoy=C3=A9 : lundi 29 mai 2017 16:54 > > =C3=80 : v6ops@ietf.org > > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02= .txt > > > > Hi all, > > > > This is an updated version of this document, including the foll= owing > > changes: > > > > 11. ANNEX D: Changes from RFC7084-bis-01 > > > > Section to be removed for WGLC. Significant updates are: > > > > 1. G-5 added in order to comply with [RFC7608]. > > > > 2. LW4O6-5 removed. > > > > 3. MAPE-3 removed. > > > > 4. MAPT-3 removed. > > > > 5. Included non-normative reference to [RFC7849] to clarify= that > the > > details of the connectivity to 3GPP/LTE networks is out = of > the > > scope. > > > > 6. Split of transition in two sub-sections for the sake of > clarity. > > > > 2, 3 and 4 above (added in the previous version) were referring= to > the > > explicit mention of NAT behavior. As each mechanism has the rel= evant > text > > in its respective RFC, I leave that to those documents, to avoi= d any > > misunderstanding or conflict. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: v6ops en nombre de drafts@ietf.org> > > Responder a: > > Fecha: lunes, 29 de mayo de 2017, 11:46 > > Para: > > CC: > > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet= - > Drafts > > directories. > > This draft is a work item of the IPv6 Operations of the IET= F. > > > > Title : Basic Requirements for IPv6 Custo= mer > Edge > > Routers > > Author : Jordi Palet Martinez > > Filename : draft-ietf-v6ops-rfc7084-bis-02.txt > > Pages : 30 > > Date : 2017-05-29 > > > > Abstract: > > This document specifies requirements for an IPv6 Custome= r > Edge (CE) > > router. Specifically, the current version of this docum= ent > focuses > > on the basic provisioning of an IPv6 CE router and the > provisioning > > of IPv6 hosts attached to it. The document also covers > several > > transition technologies, as required in a world where IP= v4 > > addresses > > are no longer available, so hosts in the customer LANs w= ith > IPv4- > > only > > or IPv6-only applications or devices, requiring to > communicate with > > IPv4-only services at the Internet, are able to do so. = The > > document > > obsoletes RFC 7084. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-b= is/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7= 084- > bis-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc708= 4-bis- > 02 > > > > > > Please note that it may take a couple of minutes from the t= ime > of > > submission > > until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged > or > > confidential. The information is intended to be for the use of = the > > individual(s) named above. If you are not the intended recipien= t be > aware > > that any disclosure, copying, distribution or use of the conten= ts of > this > > information, including attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be a= ware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. >=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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Jun 12 06:03:18 2017 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 367B712EAC6 for ; Mon, 12 Jun 2017 06:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 D6g_0nQsK2vO for ; Mon, 12 Jun 2017 06:03:14 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 719DD12EABA for ; Mon, 12 Jun 2017 06:03:14 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5CCtm32037850; Mon, 12 Jun 2017 09:03:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2b1s58jxkq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 09:03:06 -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 v5CD34lt017046; Mon, 12 Jun 2017 09:03:05 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5CD2vdK016845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Jun 2017 09:02:58 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi134.aldc.att.com (RSA Interceptor); Mon, 12 Jun 2017 13:02:44 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.82]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Mon, 12 Jun 2017 09:02:43 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 Thread-Index: AQHS4o5H8RMV17LEQdK5y4qf5zFJhqIhLcNQ Date: Mon, 12 Jun 2017 13:02:43 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB879D0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> In-Reply-To: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.217.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_09:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120228 Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:03:16 -0000 PiBCYXNpY2FsbHksIHdlIG5lZWQgdG8gZ28gYmFjayB0byBSRkM2MjA0ICh3aGljaCBkaWRu4oCZ dCBpbmNsdWRlZCB0cmFuc2l0aW9uIGF0DQo+IGFsbCkgYW5kIGV2ZW4gbW9yZSBOT1QgaW5jbHVk ZSBJUHY0IHN1cHBvcnQgYXQgYWxsDQoNClJGQyA3MDg0IGFkZGVkIHJlcXVpcmVtZW50cyBmb3Ig TUFYIFNPTCBSVCAoUkZDIDcwODMpIHRvIFJGQyA2MjA0LiBJbiBmYWN0LCB0aGlzIG9uZSByZXF1 aXJlbWVudCB3YXMgcmVzcG9uc2libGUgZm9yIGRlbGF5aW5nIHB1YmxpY2F0aW9uIG9mIFJGQyA3 MDg0IGJ5IGFsbW9zdCBhIHllYXIuIEl0IHdhcyBzdWNoIGFuIGltcG9ydGFudCByZXF1aXJlbWVu dCB0aGF0IGV2ZXJ5b25lIGFncmVlZCBpdCB3YXMgYmV0dGVyIHRvIHdhaXQgZm9yIHRoaXMgdGhh biB0byBwdWJsaXNoIHdpdGhvdXQgaXQuDQpUaGVyZSB3ZXJlIGFsc28gYSBmZXcgb3RoZXIgY2hh bmdlcyB0byBSRkMgNjIwNCByZXF1aXJlbWVudHMsIGJ1dCB0aGF0IHdhcyBieSBmYXIgdGhlIG1v c3QgaW1wb3J0YW50IGFuZCBtb3N0IG5lZWRlZC4gDQpUaGVyZWZvcmUsIEkgZG8gbm90IHN1cHBv cnQgcmV2ZXJ0aW5nIHRvIFJGQyA2MjA0LiANCldoZW4gSGFucyBMaXUgd2FzIGRpc3Rpbmd1aXNo aW5nIGJldHdlZW4gc3VwcG9ydCBmb3IgUkZDIDYyMDQgYW5kIFJGQyA3MDg0LCBJJ20gaG9waW5n IGhlIGRpZG4ndCBtZWFuIHRoYXQgQ0UgUm91dGVyIHZlbmRvcnMgYXJlbid0IHN1cHBvcnRpbmcg TUFYIFNPTCBSVC4gSSB0aGluayBNQVggU09MIFJUIGRpZCBnZXQgYWRkZWQgdG8gdGhlIFVOSC1J T0wgSVB2NiBSZWFkeSBDRSBSb3V0ZXIgdGVzdHMuIEknbSBob3BpbmcgaGUganVzdCBtZWFudCB0 aGF0IG1hbnkgQ0UgUm91dGVycyBkb24ndCBzdXBwb3J0IGFueSB0cmFuc2l0aW9uIHRlY2hub2xv Z2llcy4NCg0KVGhlICJUcmFuc2l0aW9uIFRlY2hub2xvZ2llcyBTdXBwb3J0IiBzZWN0aW9uIHRo YXQgd2FzIGFkZGVkIHdhcyBkb25lIHdpdGggcHVyZWx5ICJvcHRpb25hbCIgbGFuZ3VhZ2UuIFRo ZXJlIGlzIG5vdCBhIHNpbmdsZSBtYW5kYXRvcnkgdHJhbnNpdGlvbiB0ZWNobm9sb2d5IGluIFJG QyA3MDg0LiBBIENFIFJvdXRlciBjYW4gYmUgMTAwJSBjb21wbGlhbnQgd2l0aCBSRkMgNzA4NCBh bmQgc3VwcG9ydCBubyB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcy4NCg0KSSdtIHBlcmZlY3RseSBo YXBweSB3aXRoIHB1bGxpbmcgdGhlIGVudGlyZSAiVHJhbnNpdGlvbiBUZWNobm9sb2dpZXMgU3Vw cG9ydCIgc2VjdGlvbiBvdXQgb2YgYSBSRkMgNzA4NC1iaXMuDQpCYXJiYXJhDQo= From nobody Mon Jun 12 06:14:38 2017 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 C93B6129515 for ; Mon, 12 Jun 2017 06:14:37 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZXWaXZw0EdC for ; Mon, 12 Jun 2017 06:14:35 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC871205F1 for ; Mon, 12 Jun 2017 06:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497273273; x=1497878073; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=8Lr9GfWQFAdXfjP2TKzRkK9ld Bee/w/lU7fAY8XW6Z8=; b=ZiUVbHuVUhYoX6gIbqkpW2NcFrvcjAFOUrjv29OIv Ix2CtQJhvxhYqwKYyVDc+E0vhDrxHhzn4LXW69Uw8xiNg0ymOd0AlpqNx6v020LJ 6458wk3OZKvrOdTCEkpo+79B2SGcBO61pMuEHEfwRzW7qujVGLiIiqHhtTkqIANS r4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nP4BgR672wFJtsqoK7NvEtofIaCXCcutnfit746+Oswir7/XaBi4VyKQ28Ko MvRiLbepbo9XTuFMcqNKHcIuarOvSiyl2k+MSiVX4bubYkQ+ip5/HcL03 u9FGOEOxetCBI2vJCiKfsOu0fjRbd3zK4kQAJpn9Fqlavj5fd6I8b0=; X-MDAV-Processed: mail.consulintel.es, Mon, 12 Jun 2017 15:14:33 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 12 Jun 2017 15:14:32 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449514.msg for ; Mon, 12 Jun 2017 15:14:31 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170612:md50005449514::ppcFzARSGLr9vA2j:00003dp6 X-Return-Path: prvs=1336cd027b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 12 Jun 2017 15:14:26 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 References: <5DDD9835-86D9-41AF-951E-F2FF7C281926@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB879D0@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB879D0@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:14:38 -0000 Hi Barbara, Agree, I was not considering dropping RFC7083 at all. In RFC7084-bis I conserved the "optional" language status for the transitio= n, so I still think this is the correct way forward. Despite that, I think = if you look to either 1) https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis2/?include= _text=3D1 or 2) https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/?in= clude_text=3D1 You will be fine, as in both cases transition support has been completely r= emoved and that will be a separated document. Difference among both of them: 1) Is an =E2=80=9CIPv6-only=E2=80=9D CE, very minimalistic approach, for si= mple networks, may be even =E2=80=9Csmaller=E2=80=9D ones that a home netwo= rk. 2) Is an IPv6 CE, =E2=80=9Cdual-stack=E2=80=9D support, including HNCP. Somehow both of them are in the =E2=80=9Cmiddle way=E2=80=9D between 6204 a= nd 7084. Of course, other combinations are possible =E2=80=A6=20 Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: lunes, 12 de junio de 2017, 15:02 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02 > Basically, we need to go back to RFC6204 (which didn=E2=80=99t includ= ed transition at > all) and even more NOT include IPv4 support at all =20 RFC 7084 added requirements for MAX SOL RT (RFC 7083) to RFC 6204. In f= act, this one requirement was responsible for delaying publication of RFC 7= 084 by almost a year. It was such an important requirement that everyone ag= reed it was better to wait for this than to publish without it. There were also a few other changes to RFC 6204 requirements, but that = was by far the most important and most needed.=20 Therefore, I do not support reverting to RFC 6204.=20 When Hans Liu was distinguishing between support for RFC 6204 and RFC 7= 084, I'm hoping he didn't mean that CE Router vendors aren't supporting MAX= SOL RT. I think MAX SOL RT did get added to the UNH-IOL IPv6 Ready CE Rout= er tests. I'm hoping he just meant that many CE Routers don't support any t= ransition technologies. =20 The "Transition Technologies Support" section that was added was done w= ith purely "optional" language. There is not a single mandatory transition = technology in RFC 7084. A CE Router can be 100% compliant with RFC 7084 and= support no transition technologies. =20 I'm perfectly happy with pulling the entire "Transition Technologies Su= pport" section out of a RFC 7084-bis. Barbara =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Jun 12 08:46:19 2017 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 7DD6E129C67 for ; Mon, 12 Jun 2017 08:46:18 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8nEn_AoK1yX for ; Mon, 12 Jun 2017 08:46:16 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6F8126C26 for ; Mon, 12 Jun 2017 08:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497282374; x=1497887174; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=tqKjAapvfCbdNR9L2MlUZChWs 8xInZTwYmX8+HkmuP4=; b=AdKWDkpjF0BzmMvaoqc5ARVXf6qFR9V/48vTDUmPb GuS9bb/j5/EtAh4ASy1Ya75nX35MjmfDJizagcDJohyXewtjV/GKT4h3xwLM3S/Y ocObN0S2F/p65PIDI3ccrt08Iv7UJiLjFWgABu8tPHklfl8qfhep/OpnRRZKbgww AE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=iNVfZPmxuRLwCSc/W11G/zaKu7Yk739tYdifnofL7mAsqEN3XAeUf44hxvdv Iu4Qkgker3cqXTU+Cea/UuKUjpzn5sS5psWpcO9Tr1KLgVk2KWJsaX8KG q/GfBLekVJrLuitQFKZZTsdDiKEuZbw9W3wC49J3spI7d3kKTsf6zk=; X-MDAV-Processed: mail.consulintel.es, Mon, 12 Jun 2017 17:46:14 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 12 Jun 2017 17:46:14 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005449608.msg for ; Mon, 12 Jun 2017 17:46:12 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170612:md50005449608::2r48qXOo9/p/08ko:0000FxHb X-Return-Path: prvs=1336cd027b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 12 Jun 2017 17:46:11 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <13410EAA-124B-47CE-903A-42FC50117811@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-rfc7084-bis-transition-00.txt References: <149728221256.10326.5799460386710503503.idtracker@ietfa.amsl.com> In-Reply-To: <149728221256.10326.5799460386710503503.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-transition-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:46:18 -0000 This is the document with the transition requirements for CEs. https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition/ Basically, it cites =E2=80=9Cwhatever=E2=80=9D version we decide to take as= the RFC7084-bis and =E2=80=9Cincrease=E2=80=9D those minimum requirements = with the transition part. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: lunes, 12 de junio de 2017, 17:43 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-transiti= on-00.txt =20 A new version of I-D, draft-palet-v6ops-rfc7084-bis-transition-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-rfc7084-bis-transition Revision: 00 Title: Transition Requirements for IPv6 Customer Edge Routers Document date: 2017-06-11 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= rfc7084-bis-transition-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7= 084-bis-transition/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-b= is-transition-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -rfc7084-bis-transition-00 =20 =20 Abstract: This document specifies the transition requirements for an IPv6 Customer Edge (CE) router. Specifically, this document extends the "Minimum Requirements for IPv6-only Customer Edge Routers" (draft- palet-v6ops-rfc7084-bis2) in order to allow the provisioning of IPv6 transition services for the hosts attached to it and the support of HNCP ([RFC7788]) for automated provisioning of downstream routers. The document covers several transition technologies, either for delivering IPv6 in IPv4-only access networks and specially for delivering IPv4 "as a service" as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs wit= h IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Jun 12 13:57:05 2017 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 07EB9128C81 for ; Mon, 12 Jun 2017 13:57:04 -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 j3_wz5wHgP1r for ; Mon, 12 Jun 2017 13:57:01 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4396D129AB0 for ; Mon, 12 Jun 2017 13:57:01 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id f185so50035147pgc.0 for ; Mon, 12 Jun 2017 13:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gyx6dgAg6OEhCB9cM1M5VdzAY4KKdGgMT1WZIezL+g0=; b=hprHY2X/xDpaiUWoLGJhuORFrEa1r3UVWelB82dZCbRMIOOXiiLA6yVLHH51mA6pLb U8XxgHmu60nt7p7Xxg2bGAoLCHBEPhbRlc8zTpdjePUX6Lb7CQFxRsupuoAtv1e+1InJ GAMtfB6L5/jm1N9npoJ7K7O5iK88H4kD5/bxDbrbUrNZ491ZmKh18jVMbORKieAkKZgC obVqKUXQZqZCB5zdsOt4LpMQRmsKYqxH7qLcPXAE0NffMeZLGobYU946snBMI0z3IH98 HzzRLXLPdK8cpCdMSdU7OocSQbt2dscuGCXuwEeCbgU7ilZ3+EjwknbQgGqhN3FVu/tf rmIg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gyx6dgAg6OEhCB9cM1M5VdzAY4KKdGgMT1WZIezL+g0=; b=uSmKXlInA/aVFbAom97hmu/WsheCkGjG/M7cupmTVON5u8Xntt1huCh4PTeGiroYGO VJPKtpzw9SPm2LiPHMAdMckeoJJjB0M//TwoHNZKdN+UK4bSqQsYfGlLk5A9GZ0RJAhH QzAkOVZyd79cPhXNGx6lY+Mlf+4LZt7B66ZXiOExdpBhRxrfsMvWJEot16aDUo1l13gx FLg9W1vBwm0cuPuCpHAV7vZ5pOtbyxLDPQugmI05SVkC6wJNaT6KqAtMBjcGrQ8XeCBd 9qlOcj19oJ8M1fFucaO+mIGgOLikfw4x6QAsP5kDzNnZWQLWU/RNn8ebb+59ulOkeLAq MRdA== X-Gm-Message-State: AODbwcBSvJTXerKQT1Y0vYLU5FaQN0pE+1dlWdHZSaYKwyJIB1wEtn7r w3wvmAlaBswpEf8F X-Received: by 10.99.109.7 with SMTP id i7mr57386035pgc.143.1497301020330; Mon, 12 Jun 2017 13:57:00 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r77sm20238465pfg.95.2017.06.12.13.56.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 13:56:59 -0700 (PDT) To: v6ops@ietf.org References: <149709081349.2551.13636210837767273446@ietfa.amsl.com> <3e5a7c1c-9a2d-99e4-ea2f-5219ef620b9e@gmail.com> <5fb916ef-d9c7-9f1c-6cc7-16573cfcc2d7@gmail.com> <837E1BB8-950C-41E9-8DE2-13419F699C99@consulintel.es> <88747290-5541-4504-BE95-AD579659680D@consulintel.es> <5149a791-3891-5c3f-14c3-b07e365bb18f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9958584f-a5cd-e06f-1923-ca8918b67068@gmail.com> Date: Tue, 13 Jun 2017 08:56:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:57:04 -0000 On 12/06/2017 18:58, JORDI PALET MARTINEZ wrote: > Hi Brian, >=20 > Not exactly: >=20 > #1. A vanilla CE router that simply support an IPv6 provider, and IPv6 = hosts > on directly attached /64 subnets. >=20 > #2. IPv6 subnetting and routing on the customer side (by default, suppo= rted > by HNCP and BABEL). >=20 > #3. IPv4 coexistence (this is =E2=80=9Cdiff=E2=80=9D from the actual ht= tps://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ - either #1 = or #2, so it will be just coexistentce or coexistence+HNCP. I will cook i= t today =E2=80=A6) >=20 > I still believe that only one document should be enough, that will be #= 1+2+3 and this one is https://datatracker.ietf.org/doc/draft-ietf-v6ops-r= fc7084-bis/ Yes, *if* the 3 different aspects are clearly separated. I think that is a matter of document organisation, not of technical content. Nothing wrong with including a more formal version of the #1 #2 #3 list in the Introduction, to make everything clear for the reader. > This was discussed in the list and in the Chicago meeting and I underst= ood we agreed on that =E2=80=A6 However, if now we don't agree on that (3= -4 people voiced against that), then I think we need to choose among #1 O= R #2 (those are the 2 ID=E2=80=99s that I submitted yesterday). To me it seems that if the three aspects are clearly separated, then even people who don't want #2 in particular as a required feature should be able to agree. Those people just use #1 and #3 to define their product or procurement spec. > So clearly, we need a WG decision if we still agree on what we decided = a couple of months ago, or we have now a different view =E2=80=A6 Yes.=20 Brian >=20 > Saludos, > Jordi > =20 >=20 > -----Mensaje original----- > De: Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Responder a: > Fecha: lunes, 12 de junio de 2017, 3:56 > Para: > CC: > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt >=20 > Hi Jordi, > =20 > I think you are saying that there are several theoretically indepen= dent > components here: > =20 > #1. A vanilla CE router that simply support an IPv6 provider, and I= Pv6 hosts > on directly attached /64 subnets. > =20 > #2. IPv4 coexistence (with multiple possible solutions on the provi= der side) > =20 > #3. IPv6 subnetting and routing on the customer side (by default, s= upported > by HNCP and BABEL). > =20 > You are proposing three drafts, for cases > #1 > #1+#2 > #1+#3 > =20 > You don't have a draft for #1+#2+#3 > =20 > Have I understood correctly? > =20 > If yes, we should perhaps discuss whether that's the best document = structure. > =20 > Regards > Brian > =20 > Regards > Brian Carpenter > =20 > =20 > =20 > On 12/06/2017 09:25, JORDI PALET MARTINEZ wrote: > > Considering your inputs, I=E2=80=99ve summited a =E2=80=9Cmore co= nservative=E2=80=9D version of RFC7084-bis with HNCP support and removing= the transition support, which will come in a new document. > >=20 > > https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-h= ncp/ > >=20 > > Opinions? > >=20 > > Regards, > > Jordi > > =20 > >=20 > > -----Mensaje original----- > > De: v6ops en nombre de Brian E Carpenter= > > Organizaci=C3=B3n: University of Auckland > > Responder a: > > Fecha: domingo, 11 de junio de 2017, 22:27 > > Para: > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.t= xt > >=20 > > On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote: > > > Hi Brian, > > >=20 > > > I don=E2=80=99t think the original intent of the document (= even when it was RFC6204 and even before that), was to exclude the suppor= t of more complex topologies, but just to make sure that those mechanisms= aren=E2=80=99t described in the document itself. > > =20 > > Fair enough.=20 > > =20 > > > And yes, if that=E2=80=99s the case, I agree that there is = some text in the abstract and intro that may preclude the support for HNC= P, so this needs to be changed. > > =20 > > Right. I think it's important to set the reader's expectation= s accurately in > > the first hundred words or so. > > =20 > > Also this in 4.2. "IPv6 End-User Network Architecture": > > "The IPv6 CE router may be manually configured in an arbitrar= y > > topology with a dynamic routing protocol." > > should perhaps be extended to make it clear that HNCP is an o= ption. > > =20 > > > I=E2=80=99m trying to confirm that I understand your point = correctly, either > > > 1) We have a very basic IPv6-only CE that ONLY allows hosts= to connect to it but no other routers behind it. > > > 2) We have non-so-basic IPv6 CE which allows host and autom= atically provisioned routers behind it. > > >=20 > > > I=E2=80=99m not making here considerations about transition= mechanisms, only if the basic CE, the one that most of the ISPs provide = for =E2=80=9Cfree=E2=80=9D to the customers, should support automatic pro= visioning (with HNCP) or not? > > =20 > > Personally, I don't want to encourage 1) because that is, bas= ically, IPv4 > > with bigger addresses. The future should be 2). But I don't t= hink this draft > > is aiming to be a procurement spec for homenet, is it? It's m= ore of a baseline > > for 2). And that's fine, as long as nobody reads it and think= s it's the > > end of the story. > > =20 > > > Now, do we agree that scenario 1) is unrealistic in the nea= r term? If we still want to define this case, shall it be something like = =E2=80=9CMinimum Requirements for IPv6-only Edge Routers=E2=80=9D, and ev= en not considering IPv4 support at all there =E2=80=A6 as this may be the= case for very simple networks that only need to connect a few sensors an= d nothing else, etc. This is the case for new networks that are being dep= loyed since the start with IPv6-only in mind, and not considering IPv4 su= pport at all. > > =20 > > Right, but will those really exist? I have no idea, personall= y. > > =20 > > > And then we can have a more realistic scenario for a =E2=80= =9Ccustomer oriented=E2=80=9D CE, which may have the need to HNCP (other = routers may need to be provisioned behind the main one), and has still so= me apps/devices with IPv4 support (so transition mechanisms need to be su= pported for those hosts to work in an IPv6-only access link). This may be= what we have as our actual =E2=80=9CBasic Requirements for IPv6 Customer= Edge Routers=E2=80=9D. > > =20 > > That would be the "procurement spec for homenet". Are we read= y to write that today?? > > =20 > > Regards, > > Brian > > =20 > > > What do you think? > > >=20 > > > Regards, > > > Jordi > > > =20 > > >=20 > > > -----Mensaje original----- > > > De: v6ops en nombre de Brian E Car= penter > > > Organizaci=C3=B3n: University of Auckland > > > Responder a: > > > Fecha: domingo, 11 de junio de 2017, 3:54 > > > Para: Fred Baker > > > CC: IPv6 Operations > > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bi= s-03.txt > > >=20 > > > On 11/06/2017 08:55, Fred Baker wrote: > > > >=20 > > > > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter wrote: > > > >> "The end-user network is a stub network." > > > >> > > > >> That is no better capability or functionality than I= P4. Apart from > > > >> NAT, it's the same. > > > >> > > > >> So, naturally, HNCP and homenet is out of scope. > > > >=20 > > > > no hats > > > >=20 > > > > I'm not sure how you get from "stub network" to "no H= NCP". The residential network is a stub, which is to say it offers no tra= nsit services. Enterprise and university networks are also stubs; they of= fer no transit services. However, they can have a great deal of internal = complexity. > > > >=20 > > > > Why does making the home offer no transit services pr= eclude HNCP and homenet? > > > =20 > > > It doesn't so my phrasing was a bit wrong. The point is= that what the > > > draft describes is services to hosts, not services to h= osts and additional > > > routers. IMHO, that should be made explicit in the titl= e and abstract and > > > the very beginning of the introduction, even sooner tha= n: > > > =20 > > > "Automatic provisioning of more > > > complex topology than a single router with multiple LAN= interfaces is > > > out of scope for this document." > > > =20 > > > It's a truth in advertising issue, and it needs to leav= e the door > > > open for a future spec that does require support for mo= re complex > > > topologies. > > > =20 > > > Brian > > > =20 > > > =20 > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.consulintel.es > > > The IPv6 Company > > >=20 > > > This electronic message contains information which may be p= rivileged or confidential. The information is intended to be for the use = of the individual(s) named above. If you are not the intended recipient b= e aware that any disclosure, copying, distribution or use of the contents= of this information, including attached files, is prohibited. > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > > =20 > > _______________________________________________ > > 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.consulintel.es > > The IPv6 Company > >=20 > > This electronic message contains information which may be privile= ged or confidential. The information is intended to be for the use of the= individual(s) named above. If you are not the intended recipient be awar= e that any disclosure, copying, distribution or use of the contents of th= is information, including attached files, is prohibited. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > =20 > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that= any disclosure, copying, distribution or use of the contents of this inf= ormation, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Jun 13 13:41:38 2017 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 E2779126E3A; Tue, 13 Jun 2017 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 C2cnO0PZ6214; Tue, 13 Jun 2017 13:41:29 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FB01243F3; Tue, 13 Jun 2017 13:41:29 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id s3so76623595oia.0; Tue, 13 Jun 2017 13:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :cc:to:message-id; bh=MaQM+fH5HXZGUpqcKB/fmPl5ho4Nq930vUkAJiRLD2I=; b=UrZl9HHBblWgBq4RyuCPut+OuyHILVBsvRKl/8I1EGAvzuZ2ve3PlMXXYGy5q4G2kz zAkWPJSAWhZhl/IrfjjBz4DgL+GT4T6/4JMwgw3IM1Jn+Oa52aT1tvwzwHQV1Q/Ji2Sz FjSJXmJrT0ffFHNI0eaNJT7u7i6UjOSr6WldIn2KLyLR25096XdxV5Sk2ZJ1ZJ7pqsKb 0sHQIIfTjI+MsPsnvaZ9PM0zvoE51SdB8BfuQAL0lJzMslMBNkZhp0W0KmrtSK91pYY4 hjY5t7MhE6VijY3gOq3o+fHZbPunUC4Xe+2u+IX26B9RAeQK8RZQ2IPXufxLAOj0zEml Aw3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:cc:to:message-id; bh=MaQM+fH5HXZGUpqcKB/fmPl5ho4Nq930vUkAJiRLD2I=; b=pCHHFFqhWizMyTl+FsjEInma/8yAEE9yopshL+2wxtKFKh5bsHDSMcilJQVxlhnDeB JaK3Iemuwvpxj9sXFUykTKJnPL3JeCzN+BeY257UnDpS3RN7rNf7JIktFjN+4pRdqQzW 8mcEzQw4OUp4JQwZ8ut6bMJCJYYSC7K08FSwfhiBsBPJcK0U4g6pv6dMyFPTfWbFQdZ7 uZf4GuG6o0MC/K44mscPC81pSaQkbAxhioBz4LuWx2HcrHfyTRoQf1RP2/iRpRcoIzhi gdQufSpftdkwlY4ftKX3defIx1f56VjboAAeHypUx0lcSJg81icS/5ZW1YxTwDgjsTT3 y9ag== X-Gm-Message-State: AKS2vOxDTVKEm0fCGh50qRHWErh1c4rueMZlnYFoY8XljUjiOwkKqp3k CPYHX12UzIvarE/HINo= X-Received: by 10.202.104.99 with SMTP id d96mr1238604oic.61.1497386488284; Tue, 13 Jun 2017 13:41:28 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:19c::1000? ([2600:8802:5600:19c::1000]) by smtp.gmail.com with ESMTPSA id p8sm914557oif.22.2017.06.13.13.41.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:41:27 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 13 Jun 2017 13:41:27 -0700 References: Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org To: IPv6 Operations Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: Directorate comments on draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:41:34 -0000 I'm forwarding a note from our illustrious AD, and seeking working group = commentary. The draft that we sent the IESG asked for BCP status, and = reviews from multiple quarters view that negatively. I may be a "best = practice" later, but for now they recommend it be informational. Opinions? > Begin forwarded message: >=20 > From: Warren Kumari > Subject: Directorate comments on = draft-ietf-v6ops-unique-ipv6-prefix-per-host > Date: June 13, 2017 at 11:19:11 AM PDT > To: V6ops Chairs , = draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "Ronald P. = Bonica" > Resent-From: > Resent-To: rbonica@juniper.net, lee@asgard.org, = fredbaker.ietf@gmail.com >=20 > Hi there, >=20 > Both the OpsDir[1] and Gen-ART reviews[2][3] disagreed with the BCP > status of this document -- I've been giving it some thought and I also > disagree; it seems like it is much more of an Informational (but > useful) document. I also agree that a better definition of tracks > would be good, but this is what we currently have... >=20 > I've see the discussion with Joel and Brian, and am quite sure that > the IESG will not agree with the BCP status (esp. because it has been > called out in the directorate reviews), and will likely result it in > being shipped back to the WG. >=20 > I propose the chairs (or myself) sending mail to the WG saying that > we'd like to reclassify as Informational and see if anyone objects > strongly. >=20 > Thoughts? >=20 > W > = [1]:https://datatracker.ietf.org/doc/review-ietf-v6ops-unique-ipv6-prefix-= per-host-03-opsdir-lc-chown-2017-06-06/ > [2]: = https://datatracker.ietf.org/doc/review-ietf-v6ops-unique-ipv6-prefix-per-= host-03-genart-lc-halpern-2017-05-25/ > = [3]:https://datatracker.ietf.org/doc/review-ietf-v6ops-unique-ipv6-prefix-= per-host-02-genart-lc-halpern-2017-04-13/ >=20 >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From nobody Wed Jun 14 23:14:53 2017 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 60321129B02 for ; Wed, 14 Jun 2017 23:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xMf2gB4-zKb1 for ; Wed, 14 Jun 2017 23:14:50 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD47D1294C7 for ; Wed, 14 Jun 2017 23:14:49 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m62so12502315itc.0 for ; Wed, 14 Jun 2017 23:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NyG8tpZy5PVce+ihH3HOOhf5EKqsAdnRlUyVzNs8+G0=; b=GoFCiIqXufpr+xuTALu/t5UjnPWtV20JRPt6Zgle45zd3fezpqxiu/QMYPw5zu9Wd5 qCvbrzMYkbUs1/F41NECK88Z6gwF+SUT3mR427g5+eqC93/yAPH9KdZnSMDIOWvMUNXg J2Sz+pqciGYEm0jPSmqHlY+d2d3T6QZqYjyfzaa89N7gannPiBFwjmb2KrdLr7rBLjaW 8Sn74ZKvPxO9YMFzpBq+yyELpEsg4JGTgsubag1sLlJUTm0FBfvHXVsho7e3tE3xa2Ez i8EFtl18r+Amow1xvpijS7sg3AFmxinC4YGD0QtSuJOhTWhUbth6O9wwtkN7ZFwCs2Xp Sp9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NyG8tpZy5PVce+ihH3HOOhf5EKqsAdnRlUyVzNs8+G0=; b=M5Sr4nH4cVUA1O6lReAFPmVSi6jyzpH2CoI74fi8CZffPdrTQye+APXEc0WIFS+z6H TgHcrjyoH03ujLTTKRfJM4d52FJwmfYPpU5zt6+h/gsqKj3w4bG2uYBatcj6jnS4S8jA OtncPXjlq9rS1mKN7cB7S/Y8BNhhZqn7QP+x0MhNV1iLO2q6WgqXyaOON91pBUZGqXVl AHqYGtOGSobkkcMqVqHqhqB144un1uB1kNaOnp9/l99ubhJd1iWVUxUXBLPVHxnHkSGo 5EtnglSYvWZ71pFJZFt9pwyneU0vKgNXnTI0KW3egTegw/IIetzru10WupSa4R0mgRS0 bXhg== X-Gm-Message-State: AKS2vOxgjJ7FHvB8HDFtmG6QIsc7dEnLHoE0n3ypDd0r3VG2rJZIYqFC n8REypcrtHHNZo0Qc+gKoG+45zlf75x5ep4= X-Received: by 10.36.29.147 with SMTP id 141mr3505457itj.83.1497507289130; Wed, 14 Jun 2017 23:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.232 with HTTP; Wed, 14 Jun 2017 23:14:28 -0700 (PDT) From: Jen Linkova Date: Thu, 15 Jun 2017 16:14:28 +1000 Message-ID: To: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 06:14:52 -0000 Well, better late than never, right? So following the discussion on https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00 and the sad fact that default address selection rule 5.5 is not widely implemented (yet), I've finally managed to write down how multihoming on PA address space could be done now in *some* cases: https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00 Comments are highly appreciated. P.S. It's '00' version, far from being perfect, I'll keep polish it and -01 will be submitted before the IETF99 deadline. -- SY, Jen Linkova aka Furry From nobody Thu Jun 15 07:07:30 2017 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 86D6B1294FA for ; Thu, 15 Jun 2017 07:07:29 -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 xmZD-IRsccGB for ; Thu, 15 Jun 2017 07:07:28 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD49126FDC for ; Thu, 15 Jun 2017 07:07:27 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id 106so10438069otc.2 for ; Thu, 15 Jun 2017 07:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=n0qkQLEgQYaAmsqqVzdt4+P2TnpTRl3eOLwekAGPyVA=; b=dtgv1fh9BvcM059pTkWWQk5L9dZ7/FhMGjBLLJYhzGBa/g7kCKAcHpXx2gBvGGgML+ AkgjtYvGi3lYvfp6K+qHSLwYPI5u4EpI9b9e40RSBze1ihIzdE2myZVCm+SsStjYZn6i 1C+3D8UP2e5Rj6wQoNF0bjSxeSb51hjO+oi1Mr5YLlir+QDaHdsQPTcQV3+PKxKiFAua sinH5xgBOaglNPP2QYxcdxjHfVR/98yivYa7m2lB6t0ozinO9gTzWzbov6LhK0AdBXoY Rw0nUmsSvP9YCi+LziltZAYNI+DRjtNiwnwuCSLqUW/LYKd7vHYJbcCZZ4CRHYy9F4Fr iAeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=n0qkQLEgQYaAmsqqVzdt4+P2TnpTRl3eOLwekAGPyVA=; b=LYXBheYR4p3g6tOJ7hb1wZj5TeJrP8PLcALvtscYLw2yOM1dK0mWwE3mls3T24ETJe E91TfdHsUwMI8BWBArzamSqnzjzBLeJIlfPjvO8WppNJ8whVy3uoOwkLXUlvL/GUJbA3 7HzuE9MCOJCzeIdOjgk5JaFg7gXbYS/Nd0Je/rlOQT686p8mO5EhiTyoHDx8TywLHdvA 6eUtYTZLAeYOkmRIwDN7k2qPqy8figODRnwL8K/JN7+49mxu/y+QBoYkwYQcrdmghA/1 /yZ8OHEtCPMoAHy9QUtJ7/rcCqh2qBL5z12jgYLIoZPfOXOqkNif/0yGIKNzXXzba+kN M7HQ== X-Gm-Message-State: AKS2vOxrZRqQy2gXifR0+K7kSm8RBJNS2YMWSjWsY3TIQoieIj+OFZ1d YL1/BS8zlOILHOExTnk= X-Received: by 10.157.36.132 with SMTP id z4mr3501865ota.158.1497535647056; Thu, 15 Jun 2017 07:07:27 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:19c::1dda? ([2600:8802:5600:19c::1dda]) by smtp.gmail.com with ESMTPSA id f24sm125281otc.1.2017.06.15.07.07.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 07:07:25 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> Date: Thu, 15 Jun 2017 07:07:24 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:07:29 -0000 We have several new drafts that the chairs would like working group = discussion on, if only to gauge interest. Jen sent a note regarding hers = a moment ago. Jordi has, following feedback, divided 70844bis, and we = are looking for commentary on each. 2017-06-14 draft-linkova-v6ops-conditional-ras 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, 2017-06-12 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition "Transition Requirements for IPv6 Customer Edge Routers", Jordi Palet, 2017-06-12 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi = Palet, 2017-06-11 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi = Palet, 2017-06-11 From nobody Thu Jun 15 11:02:14 2017 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 DBE481287A5 for ; Thu, 15 Jun 2017 11:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 gGFPKGm92NN9 for ; Thu, 15 Jun 2017 11:02:11 -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 6AFB51286B1 for ; Thu, 15 Jun 2017 11:02:11 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5FEOtoo048188 for ; Thu, 15 Jun 2017 10:33:45 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2b3umh121a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 15 Jun 2017 10:33:44 -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 v5FEXhqu032163 for ; Thu, 15 Jun 2017 10:33:43 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5FEXciH032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 Jun 2017 10:33:39 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi134.aldc.att.com (RSA Interceptor) for ; Thu, 15 Jun 2017 14:33:18 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Thu, 15 Jun 2017 10:33:18 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkA== Date: Thu, 15 Jun 2017 14:33:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_07:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150250 Archived-At: Subject: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:02:13 -0000 I don't think this is the right recommendation: =20 L-12: The IPv6-only CE router SHOULD implement a DNS proxy as described in [RFC5625]. There are many CE routers that pass to LAN devices the address of WAN-based= DNS servers (of ISP or Google, etc.) and do not implement a DNS server as = a forwarding proxy. This "SHOULD" requirement in the context of a CE Router= that does not implement a forwarding proxy is meaningless, and not impleme= nting a forwarding proxy is very valid and does not need to be discouraged.= On the other hand, if a forwarding proxy is implemented, doing so accordin= g to RFC 5625 needs to be required. Forwarding proxies that aren't complian= t with RFC 5625 have no business being deployed to mass market consumers. Note that BBF TR-124 has a requirement for RFC 5625 worded as: "If the RG's DNS server is implemented as a forwarding proxy, it MUST be do= ne according to the recommendations in RFC 5625." Barbara From nobody Thu Jun 15 11:12:37 2017 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 AEA21127342 for ; Thu, 15 Jun 2017 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y9ZKgIP51vd for ; Thu, 15 Jun 2017 11:12:33 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FFC12706D for ; Thu, 15 Jun 2017 11:12:33 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id u12so31103353qth.0 for ; Thu, 15 Jun 2017 11:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=py3JjW/1V5lE04QykosTx14FYxAyPYXsOqhPsTY7pkM=; b=yLpp7RjyfmgAdNSKw9RBATa/RfdDsRh6ZvaLN3XjhXXZaQQkhoBTxqRWXigrH6tJsq Pdi5tWw5EPpJntIDH2bUrbQU3nBjW9Yz0DNmkmQ3w16s+yO+ZE1GF4zwgNq5KMtsGPHX dtUA3tnAGPLjgBmiJOLVFf9bbVBenBUtkRMzdZEbKUPbcuNKA9vQbIhIN/rlRPZW+aCm M8Jq58HeFQ7tmy7lbJXAJq1jcB5vnUBtRdd1AKYW9AEaLey6ut1Aq2oomyh/44E5sie8 XvZYIZ8pB5f696e4T/WRdhvEqIIpF71LyzhpJpUdQBqKZUM7NV58JQSJCKhehByXLS5S 050w== 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=py3JjW/1V5lE04QykosTx14FYxAyPYXsOqhPsTY7pkM=; b=j1fSUv3iFFb7jv/get8sdbGGfc9a+peDYxXAtb4iqw+snxzw4w7Dgmg/DoLATMoBiP YVwZjsCZzSsT5ZHu9SG6NI6aNI9uIxEMRjQBYIi5L5AsGYb72nSyU2YasBQGXYEjf8JM wst/tHNUFyfR4JwZywbMFL1/ugOzhCVK6Af0AzmCQ9jofVEPw607zSmq9tXTXeCRryXj u4lXXxnf2jTIJ4/S2HMSE9lH0OaE/XGr1fg1t6b3d3i3mTyvRyQoDcEhwgn4qgrD5Vov XdY1zVEJEQa6YMIOkbCRDU+4nxVxm7Cs8fjihVMTlsr8H3rZbtigqvzEjZLFz+oED79r yFYg== X-Gm-Message-State: AKS2vOyx1nHF/DXFOq7hnyMQnr5AMn0MydqRsZjSaQeETDYJf6VzLTAw WWz5pMRSRe0fZXHI X-Received: by 10.200.37.204 with SMTP id f12mr8299882qtf.138.1497550352307; Thu, 15 Jun 2017 11:12:32 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n206sm511052qkn.65.2017.06.15.11.12.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 11:12:31 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C91853EF-8D5D-4015-A7EA-D40E2AE8C3E6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 14:12:30 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: "v6ops@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 18:12:35 -0000 --Apple-Mail=_C91853EF-8D5D-4015-A7EA-D40E2AE8C3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2017, at 10:33 AM, STARK, BARBARA H wrote: > There are many CE routers that pass to LAN devices the address of = WAN-based DNS servers (of ISP or Google, etc.) and do not implement a = DNS server as a forwarding proxy. This "SHOULD" requirement in the = context of a CE Router that does not implement a forwarding proxy is = meaningless, and not implementing a forwarding proxy is very valid and = does not need to be discouraged. On the other hand, if a forwarding = proxy is implemented, doing so according to RFC 5625 needs to be = required. Forwarding proxies that aren't compliant with RFC 5625 have no = business being deployed to mass market consumers. The reason this is here is that naming has to work when the northbound = interface of the CE router is not connected. This is not to say that = there is any local name service, but simply that the CE router has to = have an IP address for the resolver that it can give out at that time, = and may not have an IP address for an _external_ resolver that can be = assumed will be functional when the northbound interface reconnects. --Apple-Mail=_C91853EF-8D5D-4015-A7EA-D40E2AE8C3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 15, 2017, at 10:33 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
There are many CE = routers that pass to LAN devices the address of WAN-based DNS servers = (of ISP or Google, etc.) and do not implement a DNS server as a = forwarding proxy. This "SHOULD" requirement in the context of a CE = Router that does not implement a forwarding proxy is meaningless, and = not implementing a forwarding proxy is very valid and does not need to = be discouraged. On the other hand, if a forwarding proxy is implemented, = doing so according to RFC 5625 needs to be required. Forwarding proxies = that aren't compliant with RFC 5625 have no business being deployed to = mass market consumers.

The reason this is here is that naming has to work when the = northbound interface of the CE router is not connected.   This is = not to say that there is any local name service, but simply that the CE = router has to have an IP address for the resolver that it can give out = at that time, and may not have an IP address for an _external_ resolver = that can be assumed will be functional when the northbound interface = reconnects.

= --Apple-Mail=_C91853EF-8D5D-4015-A7EA-D40E2AE8C3E6-- From nobody Thu Jun 15 12:39:30 2017 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 59DE81277BB for ; Thu, 15 Jun 2017 12:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Zzho9JjD4E for ; Thu, 15 Jun 2017 12:39:27 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EABA1201F2 for ; Thu, 15 Jun 2017 12:39:27 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s66so11850354pfs.1 for ; Thu, 15 Jun 2017 12:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SOtU6U5e5QvaDcz5MEUIAMzh1s3F7SGa9fKEiYPmcOo=; b=ze1jClrQ0IN54eQZ7MqcvFF7v1srFSPdF+Byuc3yP/f0mUGTI42FztsCOLlZ1RZUkA cEe5gXBC+iFvZRM/bzGUIdZ8NxAm/zB3U6nwbL+9VSR/8DqAytUEI2L3vM3o/CvWuhNw r8VxzEKlc6YzvLJxqbGctMs0/vRaCPUt96zIvrFGhZNDElZujSXgritYry9TFVj1Z19H FVNkUrhcu4Y1GsodeOXPz4GdVtzubUIJmM11C0TYRLjYhfs28+UBEjt2hRHVdlMHQK0N wWz38zgSN2jpTLmshwu9vWUnYPcTy9VKegcmQWYIHML0xL6igSI7377TQiAvA7rsHJrl reXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SOtU6U5e5QvaDcz5MEUIAMzh1s3F7SGa9fKEiYPmcOo=; b=JApWVN0olecj3aPmLaDFGMKZWgChhSw5QpuKtdagTcXhHugfc3rAyzun5Ft03KzLOS tRI2KGQes4ixMWYFVajSv4uIOa0l/m3+QQe9RfWYx+h7b4xE2eQwTdRYefrRhn+33OtW dDYuRTYjji1tLKH1EtxQ09TgRJnmlY8feS6OEUyPspNNuougREGwOQPF6PvIlXVRpV4q xRftlh8qCpGtkdOmQjuiFjHYHfAQDaddg/SI4RB68QYULHpWJIi1+4cY096uO6S6ZbaK xzhGv4sWAVraXMIl7fZYL0pAzfZ/Wngq/tRDwa2CHirV8Qt7yCWAw94hfqoLHz8On+2f oWFg== X-Gm-Message-State: AKS2vOzPoFAzbZJaN3gYzNIAdoi8/ncinHAo51kirNZzMRw1bbgMxH0P myXy//mcmTl2AUUUE4xit5koK23mEIM1 X-Received: by 10.99.6.65 with SMTP id 62mr7075827pgg.157.1497555567179; Thu, 15 Jun 2017 12:39:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.2 with HTTP; Thu, 15 Jun 2017 12:39:26 -0700 (PDT) Received: by 10.100.178.2 with HTTP; Thu, 15 Jun 2017 12:39:26 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Ted Lemon Date: Thu, 15 Jun 2017 15:39:26 -0400 Message-ID: To: "STARK, BARBARA H" Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a114eae229d0c9e055204d35e" Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:39:29 -0000 --001a114eae229d0c9e055204d35e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why is that device a router at all, and not a bridge? Does it have a DHCP server? On Jun 15, 2017 3:29 PM, "STARK, BARBARA H" wrote: There are many CE routers that pass to LAN devices the address of WAN-based DNS servers (of ISP or Google, etc.) and do not implement a DNS server as a forwarding proxy. This "SHOULD" requirement in the context of a CE Router that does not implement a forwarding proxy is meaningless, and not implementing a forwarding proxy is very valid and does not need to be discouraged. On the other hand, if a forwarding proxy is implemented, doing so according to RFC 5625 needs to be required. Forwarding proxies that aren't compliant with RFC 5625 have no business being deployed to mass market consumers. The reason this is here is that naming has to work when the northbound interface of the CE router is not connected. This is not to say that there is any local name service, but simply that the CE router has to have an IP address for the resolver that it can give out at that time, and may not have an IP address for an _external_ resolver that can be assumed will be functional when the northbound interface reconnects. Having an IP address of a resolver to hand out is very different than requiring all CE Routers to be the resolver. I very much disagree that all CE Routers be required to be the resolver of a local name service or be capable of being the resolver. The scenario where the ISP provides a very low-end single-LAN-port router with DSL/DOCSIS/etc modem, and the user is then expected to supply a more functional router (if the user wants to enable a home network) is not uncommon. Those low-end router/modems should never be expected to provide a resolver function for a local name service. That should be done by the more functional router the user supplies. These low-end routers were specifically intended to be covered by RFC 7084. The word =E2=80=9CBasic=E2=80=9D in the title was very intentional. --001a114eae229d0c9e055204d35e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why is that device a router at all, and not a bridge?=C2= =A0 Does it have a DHCP server?

On Jun 15, 2017 3:29 PM, "STARK, BARBARA H" &= lt;bs7652@att.com> wrote:

There are many CE routers that pass to LAN devices= the address of WAN-based DNS servers (of ISP or Google, etc.) and do not i= mplement a DNS server as a forwarding proxy. This "SHOULD" requirement in the context of a CE Router that does not= implement a forwarding proxy is meaningless, and not implementing a forwar= ding proxy is very valid and does not need to be discouraged. On the other = hand, if a forwarding proxy is implemented, doing so according to RFC 5625 needs to be required. Forwarding proxies th= at aren't compliant with RFC 5625 have no business being deployed to ma= ss market consumers.

=C2=A0

The reason this is here is that naming has to work w= hen the northbound interface of the CE router is not connected. =C2=A0 This= is not to say that there is any local name service, but simply that the CE= router has to have an IP address for the resolver that it can give out at that time, and may not have an IP address= for an _external_ resolver that can be assumed will be functional when the= northbound interface reconnects.

=C2=A0

<BHS> Having an IP addres= s of a resolver to hand out is very different than requiring all CE Routers= to be the resolver. I very much disagree that all CE Routers be required to be the resolver of a local name service or be capable of be= ing the resolver. The scenario where the ISP provides a very low-end single= -LAN-port router with DSL/DOCSIS/etc modem, and the user is then expected t= o supply a more functional router (if the user wants to enable a home network) is not uncommon. Those low-en= d router/modems should never be expected to provide a resolver function for= a local name service. That should be done by the more functional router th= e user supplies. These low-end routers were specifically intended to be covered by RFC 7084. The word =E2=80=9CBa= sic=E2=80=9D in the title was very intentional.


--001a114eae229d0c9e055204d35e-- From nobody Thu Jun 15 13:21:04 2017 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 4FCC6128D40 for ; Thu, 15 Jun 2017 13:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 ag4X0RBynDMz for ; Thu, 15 Jun 2017 13:21:01 -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 D4D701201F2 for ; Thu, 15 Jun 2017 13:21:01 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5FJP1Kv011411; Thu, 15 Jun 2017 15:29:28 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2b4026rvak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 15:29:28 -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 v5FJTR1f027495; Thu, 15 Jun 2017 15:29:27 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5FJTJ1L027404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 15:29:20 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi134.aldc.att.com (RSA Interceptor); Thu, 15 Jun 2017 19:29:03 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Thu, 15 Jun 2017 15:29:03 -0400 From: "STARK, BARBARA H" To: Ted Lemon CC: "v6ops@ietf.org" Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAQkasAAAYWBAA= Date: Thu, 15 Jun 2017 19:29:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.238] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DB94531GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_spam policy=outbound_policy score=60 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=60 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150335 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:21:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DB94531GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are many CE routers that pass to LAN devices the address of WAN-based= DNS servers (of ISP or Google, etc.) and do not implement a DNS server as = a forwarding proxy. This "SHOULD" requirement in the context of a CE Router= that does not implement a forwarding proxy is meaningless, and not impleme= nting a forwarding proxy is very valid and does not need to be discouraged.= On the other hand, if a forwarding proxy is implemented, doing so accordin= g to RFC 5625 needs to be required. Forwarding proxies that aren't complian= t with RFC 5625 have no business being deployed to mass market consumers. The reason this is here is that naming has to work when the northbound inte= rface of the CE router is not connected. This is not to say that there is= any local name service, but simply that the CE router has to have an IP ad= dress for the resolver that it can give out at that time, and may not have = an IP address for an _external_ resolver that can be assumed will be functi= onal when the northbound interface reconnects. Having an IP address of a resolver to hand out is very different than= requiring all CE Routers to be the resolver. I very much disagree that all= CE Routers be required to be the resolver of a local name service or be ca= pable of being the resolver. The scenario where the ISP provides a very low= -end single-LAN-port router with DSL/DOCSIS/etc modem, and the user is then= expected to supply a more functional router (if the user wants to enable a= home network) is not uncommon. Those low-end router/modems should never be= expected to provide a resolver function for a local name service. That sho= uld be done by the more functional router the user supplies. These low-end = routers were specifically intended to be covered by RFC 7084. The word "Bas= ic" in the title was very intentional. --_000_2D09D61DDFA73D4C884805CC7865E6114DB94531GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are many CE routers that pass to LAN devices= the address of WAN-based DNS servers (of ISP or Google, etc.) and do not i= mplement a DNS server as a forwarding proxy. This "SHOULD" requirement in the context of a CE Router that does not= implement a forwarding proxy is meaningless, and not implementing a forwar= ding proxy is very valid and does not need to be discouraged. On the other = hand, if a forwarding proxy is implemented, doing so according to RFC 5625 needs to be required. Forwarding proxies th= at aren't compliant with RFC 5625 have no business being deployed to mass m= arket consumers.

 

The reason this is here is that naming has to work w= hen the northbound interface of the CE router is not connected.   This= is not to say that there is any local name service, but simply that the CE= router has to have an IP address for the resolver that it can give out at that time, and may not have an IP address= for an _external_ resolver that can be assumed will be functional when the= northbound interface reconnects.

 

<BHS> Having an IP address of a= resolver to hand out is very different than requiring all CE Routers to be= the resolver. I very much disagree that all CE Routers be required to be the resolver of a local name service or be capable of be= ing the resolver. The scenario where the ISP provides a very low-end single= -LAN-port router with DSL/DOCSIS/etc modem, and the user is then expected t= o supply a more functional router (if the user wants to enable a home network) is not uncommon. Those low-en= d router/modems should never be expected to provide a resolver function for= a local name service. That should be done by the more functional router th= e user supplies. These low-end routers were specifically intended to be covered by RFC 7084. The word “Basi= c” in the title was very intentional.

--_000_2D09D61DDFA73D4C884805CC7865E6114DB94531GAALPA1MSGUSRBF_-- From nobody Thu Jun 15 14:37:48 2017 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 D86351204DA for ; Thu, 15 Jun 2017 14:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 ay9T_IpKEyqo for ; Thu, 15 Jun 2017 14:37:44 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 55ED7128DF6 for ; Thu, 15 Jun 2017 14:37:44 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5FLZPGL028474; Thu, 15 Jun 2017 17:37:38 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2b4038xnp4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 17:37:37 -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 v5FLbaqk011529; Thu, 15 Jun 2017 17:37:37 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5FLbVXL011492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 17:37:33 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 15 Jun 2017 21:37:16 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0319.002; Thu, 15 Jun 2017 17:37:16 -0400 From: "STARK, BARBARA H" To: Ted Lemon CC: IPv6 Ops WG Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAQkasAAAYWBAD//6SSPf//4nKQ Date: Thu, 15 Jun 2017 21:37:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB94898@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.196.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_11:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150373 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 21:37:46 -0000 PiBXaHkgaXMgdGhhdCBkZXZpY2UgYSByb3V0ZXIgYXQgYWxsLCBhbmQgbm90IGEgYnJpZGdlP8Kg IA0KDQpCZWNhdXNlIGJ5IG1ha2luZyBpdCBhIHJvdXRlciwgaGVscCBkZXNrIGNhbGxzIChxdWFu dGl0eSBhbmQgIGR1cmF0aW9uKSB3ZXJlIHJlZHVjZWQgc2lnbmlmaWNhbnRseS4gQWxsIHRoZSBz dHVmZiBmb3IgZGVhbGluZyB3aXRoIFBQUG9FIGNvbmZpZ3VyYXRpb24sIDZyZCBjb25maWd1cmF0 aW9uLCBhbmQgYmVpbmcgYWJsZSB0byB0cm91Ymxlc2hvb3QgYXQgYW4gSVAgbGF5ZXIgd2l0aCBh IHNpbmdsZSB0eXBlIG9mIHJvdXRlciwgYW5kIHRoYXQgcm91dGVyIGlzIG1hbmFnZWQsIGlzIHNv LW8tbyBtdWNoIGVhc2llci4gQW5kIHdpdGggdGhlIGFiaWxpdHkgdG8gZGVjcmVhc2UgaGVscCBk ZXNrIGNhbGxzIGFuZCByZWR1Y2UgY2FsbCB0aW1lIGZvciBoZWxwIGRlc2sgY2FsbHMgYW5kIGlu Y3JlYXNlIHRoZSBwcmVjaXNpb24gb2YgaGVscCBkZXNrIGRpYWdub3N0aWNzLCBjdXN0b21lciBz YXRpc2ZhY3Rpb24sIG9uIGF2ZXJhZ2UsIGlzIGluY3JlYXNlZC4gDQoNCj4gRG9lcyBpdCBoYXZl IGEgREhDUCBzZXJ2ZXI/DQpZZXMuIEluIG9yZGVyIHRvIGJlIGFibGUgdG8gcHV0IGFueSBzb3J0 IG9mIElQIGRldmljZSAoc2luZ2xlIFBDIG9yICJtb3JlIGZ1bmN0aW9uYWwgcm91dGVyIikgYmVo aW5kIGl0IGFuZCBoYXZlIGV2ZXJ5dGhpbmcgImp1c3Qgd29yayIgd2l0aCBsaXR0bGUgbW9yZSB0 aGFuICJwbHVnIGluIHRoZSBFdGhlcm5ldCBjYWJsZSIgZm9yIGluc3RydWN0aW9ucywgREhDUHY0 IGhhcyB0byBiZSB0aGVyZS4gQmVjYXVzZSBhbGwgZ29vZCBJUHY2LWNhcGFibGUgQ0Ugcm91dGVy cyBzdXBwb3J0IERIQ1B2NiBJQV9QRCBjbGllbnQgcmVxdWVzdHMgdG8gdGhlIFdBTiwgREhDUHY2 IGZvciBJQV9QRCBpcyBhbHNvIHRoZXJlLiANCg0KQmFyYmFyYQ0K From nobody Thu Jun 15 14:39:55 2017 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 56073128DF6 for ; Thu, 15 Jun 2017 14:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VUlIaLWL73qR for ; Thu, 15 Jun 2017 14:39:51 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 381581204DA for ; Thu, 15 Jun 2017 14:39:51 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k145so14913694oih.3 for ; Thu, 15 Jun 2017 14:39:51 -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=VilxlFX0oi6Prh77ZrbrziG/igXf/hpHSihXJW0Vc9U=; b=tduYCWvIJU+Q1JtQJ7ojno1SZ0y8zu5q6xFUm/4xCQj+ffkLq7A4h1F7BrncmKjbga 3+LQUKEixTw0reSjSBlp4uRlJ7fPysD0WVJrQQ/cYC6wGT9fajehaVHkmkNKakmjDeZ8 iYqwcaBaGaqctyGp4i+HW7PSbQYfxySCTh4+qCODwxHW8n5av10XAMjkZAP69vWlcolM pLFUqGAs7Kp9dTi8JewEaavY6bfeNQy+ztUHTelezbPazWmIYt5hAqhLp6C8yhC8G/1T LIVJG3OIEEBJAcD9uSF5CtIzbLjlPMxjya74vECZsshWeeE2Vm3oBb37hNOWo93DMvew y7jQ== 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=VilxlFX0oi6Prh77ZrbrziG/igXf/hpHSihXJW0Vc9U=; b=dpNKsLoEztoEQo/I/uLpWFryeiR0QuwfjGiHwMpWLdcPEbomeKNHvrHePdrSCDbC3W LrtFWKtnO9bng+14lmEuCUPpS103ZBtuddgGUhm7AP5AXcuEyDq1MQHyKlwKuUSyl4zW UMdP907X2/amLqcCgMNVipvhD/1vMa/fEjmY7ROqWHqcaYI7VhBIYJbCvRcTNYDf6N0u RbFuTg+AbqlORTBOWQG50Z64J5OQUHMDo6BVSDakiLpTaKPaVH1w5PPSFoOfOTPydBzF izIgnVN23MnVcsGUOaLI/75sNO05BqcePfGiNaOb/HcpyluIiL0veZ4zyioJTg/nP8nX ewFg== X-Gm-Message-State: AKS2vOxiWPQM3KbIuf4i+X3J+RrWLyfWRiIQRStDdKmVaOHD1nmlXEIG +qh+dMnsTsc/HA== X-Received: by 10.202.52.194 with SMTP id b185mr3870554oia.8.1497562790600; Thu, 15 Jun 2017 14:39:50 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::123d? ([2600:8802:5600:1e::123d]) by smtp.gmail.com with ESMTPSA id w130sm219610oiw.13.2017.06.15.14.39.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 14:39:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 15 Jun 2017 14:39:48 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 21:39:53 -0000 So - you are suggesting that L-12 be worded similarly to TR-124: "*IF* = ... *THEN* ...". Right? > On Jun 15, 2017, at 7:33 AM, STARK, BARBARA H wrote: >=20 > I don't think this is the right recommendation: =20 > L-12: The IPv6-only CE router SHOULD implement a DNS proxy as > described in [RFC5625]. >=20 > There are many CE routers that pass to LAN devices the address of = WAN-based DNS servers (of ISP or Google, etc.) and do not implement a = DNS server as a forwarding proxy. This "SHOULD" requirement in the = context of a CE Router that does not implement a forwarding proxy is = meaningless, and not implementing a forwarding proxy is very valid and = does not need to be discouraged. On the other hand, if a forwarding = proxy is implemented, doing so according to RFC 5625 needs to be = required. Forwarding proxies that aren't compliant with RFC 5625 have no = business being deployed to mass market consumers. >=20 > Note that BBF TR-124 has a requirement for RFC 5625 worded as: > "If the RG's DNS server is implemented as a forwarding proxy, it MUST = be done according to the recommendations in RFC 5625." >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 15 14:53:37 2017 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 81C8C12956C for ; Thu, 15 Jun 2017 14:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-R7UOzqUZhE for ; Thu, 15 Jun 2017 14:53:34 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9937512952E for ; Thu, 15 Jun 2017 14:53:34 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c10so38996356qtd.1 for ; Thu, 15 Jun 2017 14:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dIDuL/0lC69WtEURlp68G0mWh8nJO1jbakzbBF+3olw=; b=BDeZlJeAe077HZG9rabw1t05dw1ooFQVs8NyIkB8MKiByGVVDwnE2PxD6oJIeSio3q BaH2LVe7Sr341XPFyR/50uGBZ/XqYhlKTi2bkileH0B765m1O2NPCeERfo1mmsJaNeIk OnFaWZbD2Hp+CV8YvAzI3d/AK5+r6/1NKQP/rQGKwEEUwQDKt3F8yvAI7B6LakWrLhHK lSdzEryq5lZIC5EhnL35ecyIN+hyl9BxkicbMctYYmeqRMI2oHPRL1EJzipu0LlQZv5O U4k1bGbqFPbcABiwoIJxIIR3aCVo28ZbP7pH72ZLB87lxCbQljeE1qf8vy3ubfr0LPMs Ijbw== 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=dIDuL/0lC69WtEURlp68G0mWh8nJO1jbakzbBF+3olw=; b=en6O4SrFyu8E3fQFG8rSgP4aRu18g3NV7r5BpBGEo5LhWHbwDfLF5ad1ah7ESdM3Ar kUcbrH0W/gF/FY0P7As649+lpozLOYiDXBHYOngx2HDPZgaE3fVfwSdGfoe7mb5aD208 dB50K9gebnkU5UaVqKuifIVrCL6F7WgCXaQrRtRGG6+iw7qGotjqjqey6RxM+jjvCXEq 0NI8q56qPJCaV8qzxeV5sZWxjzcqfVcNRLy+PRuUDVjsfowJZkzATxjWNVGtnfKfy7qs ypN7kX8BIe9qouwHLpfBC35r5a6rRS5LfhNXt22IGZtq5GON0zmjijs4df5gceDNFyji X8Nw== X-Gm-Message-State: AKS2vOx9Ybn7eTkutgAbZsP/V8I9m3AV9FdGNokmjF1TphHzxKM2csCU 0q4/HToDYHufOnQa X-Received: by 10.237.54.71 with SMTP id e65mr9687725qtb.146.1497563613783; Thu, 15 Jun 2017 14:53:33 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e4sm282857qkb.30.2017.06.15.14.53.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 14:53:32 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B6C6FBA1-6C94-4F85-B923-C1AD44BB9179" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 17:53:31 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB94898@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: IPv6 Ops WG To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94898@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 21:53:36 -0000 --Apple-Mail=_B6C6FBA1-6C94-4F85-B923-C1AD44BB9179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2017, at 5:37 PM, STARK, BARBARA H wrote: > Yes. In order to be able to put any sort of IP device (single PC or = "more functional router") behind it and have everything "just work" with = little more than "plug in the Ethernet cable" for instructions, DHCPv4 = has to be there. Because all good IPv6-capable CE routers support DHCPv6 = IA_PD client requests to the WAN, DHCPv6 for IA_PD is also there.=20 If it's got a DHCP server, it's hard to see why it can't have a DNS = proxy. I wrote a pretty fancy one that adds edns0 options one way and = drops them the other (meaning it's remembering outstanding = transactions). It's about 32k of code, compiled, with packet dump code = for debugging still in. I suspect if you took out all the stuff that's = not needed for a bare DNS proxy, it would be more like 16k. I realize = that cheap CE routers have limited space, but it's hard to believe that = their space is _that_ limited. That said, if you want to remove this requirement, you need to solve the = problem the requirement solves some other way. --Apple-Mail=_B6C6FBA1-6C94-4F85-B923-C1AD44BB9179 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 15, 2017, at 5:37 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
Yes. In order to be = able to put any sort of IP device (single PC or "more functional = router") behind it and have everything "just work" with little more than = "plug in the Ethernet cable" for instructions, DHCPv4 has to be there. = Because all good IPv6-capable CE routers support DHCPv6 IA_PD client = requests to the WAN, DHCPv6 for IA_PD is also there. 

If it's got a DHCP server, it's hard = to see why it can't have a DNS proxy.   I wrote a pretty fancy one = that adds edns0 options one way and drops them the other (meaning it's = remembering outstanding transactions).  It's about 32k of code, = compiled, with packet dump code for debugging still in.   I suspect = if you took out all the stuff that's not needed for a bare DNS proxy, it = would be more like 16k.   I realize that cheap CE routers have = limited space, but it's hard to believe that their space is _that_ = limited.

That = said, if you want to remove this requirement, you need to solve the = problem the requirement solves some other way.

= --Apple-Mail=_B6C6FBA1-6C94-4F85-B923-C1AD44BB9179-- From nobody Thu Jun 15 14:57:19 2017 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 1349C129465 for ; Thu, 15 Jun 2017 14:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McFhzIurMCSA for ; Thu, 15 Jun 2017 14:57:15 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9A31275AB for ; Thu, 15 Jun 2017 14:57:15 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id m31so16111090uam.1 for ; Thu, 15 Jun 2017 14:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=epgjlDvF/MCYlLvFhLe36ukse+bogFRkzU6Bn6dppsQ=; b=yUctJEG4g9tZQxg3Fzv5Uje8VkVnV5YLnTTCrr8Glhh4prKsUvQwKxFidJf/1/FQ7L HACb7goro9LUdY+cBwdRvX8PIlFFlKfd7ZMVRMJe44rwzxZA5thBkrxvT83f2K4cHgE0 cnD/Xeh4wGHgbwHLieddLzhRK6jrRS5ZVHOJ+9NMvhfzjyHbdmS6QkNY5RxWGkmMDBcK o5P6cuW9SEi2bR3NhT4Sa/g1YR5/jAS+bnnsN5YTmYX8G3Qtu9sELZ50b4JcseBvz7p5 Ij9FxaSX+s6l6ML/S8/wgbPkq/dLIR9YuNLHgZ6CZloMpEil2s1mppAv/+ux3W6752xo 7aVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=epgjlDvF/MCYlLvFhLe36ukse+bogFRkzU6Bn6dppsQ=; b=RSR3QYmFnQCoUZlchsDx5Ea2Rofyh1gBcri4oev3kMf9GwdIqqxdztqwMXGoYI406B Vi3MyP0MVYNjXbafDm6thjGDhm4Jry6MKGwYqfnHmtpjIVMKz/Ga/4OHUZG0qMWQwi/q pMMyDgON3DgzZXeMVuyLxCliP8PsRr/0bUvDrL4xR1Ua35JVaoVNVAgpkEDGyTMi8LY2 YPthtZNYGWfj+XS1yKj7xIRPqB6gD2qBJTjCu5Fqq+dfIiKp7N03JBd8535WXsTvFOpf oAX4A/J5zczhXkWg9/8cw4W0/wo7wtlUqdm6Kwdb372cV5rQVnKGlgb506pdILhKM+JI XHWw== X-Gm-Message-State: AKS2vOyeCD9yMqewRB04offyO8sMCFrQONxnYuPgj88aE/9PICVIKDXs B/8KVX1S5lbBViw1SkYHEKZLFqxPH7+g X-Received: by 10.159.60.162 with SMTP id s34mr4689878uai.89.1497563834786; Thu, 15 Jun 2017 14:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Thu, 15 Jun 2017 14:56:34 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Warren Kumari Date: Thu, 15 Jun 2017 17:56:34 -0400 Message-ID: To: "STARK, BARBARA H" Cc: Ted Lemon , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 21:57:18 -0000 On Thu, Jun 15, 2017 at 3:29 PM, STARK, BARBARA H wrote: > There are many CE routers that pass to LAN devices the address of WAN-bas= ed > DNS servers (of ISP or Google, etc.) and do not implement a DNS server as= a > forwarding proxy. This "SHOULD" requirement in the context of a CE Router > that does not implement a forwarding proxy is meaningless, and not > implementing a forwarding proxy is very valid and does not need to be > discouraged. On the other hand, if a forwarding proxy is implemented, doi= ng > so according to RFC 5625 needs to be required. Forwarding proxies that > aren't compliant with RFC 5625 have no business being deployed to mass > market consumers. > > > > The reason this is here is that naming has to work when the northbound > interface of the CE router is not connected. This is not to say that th= ere > is any local name service, but simply that the CE router has to have an I= P > address for the resolver that it can give out at that time, and may not h= ave > an IP address for an _external_ resolver that can be assumed will be > functional when the northbound interface reconnects. > > > > Having an IP address of a resolver to hand out is very different th= an > requiring all CE Routers to be the resolver. I very much disagree that al= l > CE Routers be required to be the resolver of a local name service or be > capable of being the resolver. I agree -- there is a huge amount of DNS breakage caused by CE trying to be "clever" with DNS. Suggesting that vendors SHOULD implement some sort of DNS thingie that they a: don't really want to and b: have little skill in is likely to end in yet more pain. I'd really suggest that the DNSOP WG be consulted on this particular point -- I think that they will have some useful input. W > The scenario where the ISP provides a very > low-end single-LAN-port router with DSL/DOCSIS/etc modem, and the user is > then expected to supply a more functional router (if the user wants to > enable a home network) is not uncommon. Those low-end router/modems shoul= d > never be expected to provide a resolver function for a local name service= . > That should be done by the more functional router the user supplies. Thes= e > low-end routers were specifically intended to be covered by RFC 7084. The > word =E2=80=9CBasic=E2=80=9D in the title was very intentional. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jun 15 15:28:29 2017 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 6899612EAB0 for ; Thu, 15 Jun 2017 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuH24GLXzllY for ; Thu, 15 Jun 2017 15:28:25 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312F01296C6 for ; Thu, 15 Jun 2017 15:28:25 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c10so40019383qtd.1 for ; Thu, 15 Jun 2017 15:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cmUgtTog64M8P5mtSs8tkCzyHnJW3ob5fSYHnTNfNN4=; b=rCZGvpCsiwS/qsOeUzOBez8/NytXq1dYGg85g2F691zECWUDshufccSnOBL6BIjtRl bLVwEfTwz1SzX5i95UqbxOJ75VtB98HdNrb+eawuib1Ch+xJ+4nlLd8I+UXle6Ae8wsS AuvEMncacfOUIXJoGSpjbv7VGV0vtItFAySwuelf5HEgGZc8Ej9rXnG2V3vIPmOY/bLs SiXF7BWSPOI3hC39B8DFRx7Bd8akmVAfaWG3sFARNFhfVID0a9zL43SVzoQRjUS/bpqM YMMRlyEivp3hAYVBmtcdVpDfsVLTj3gP+8d3KpcQzzvefJGE0fpC1HnQeKGKarlv2o4a TqGw== 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=cmUgtTog64M8P5mtSs8tkCzyHnJW3ob5fSYHnTNfNN4=; b=Sdz8KosRH0OFBF8n8vA9bMygqVMCKgIN0ArRInGi6AvLZf2Yxn4n2vHu8XlH6HH9SM fYb7T7jqCLw+jDynEHd6vtQf2zTx/QXmVDPEA9Jy1pl6kRLOyAK26bILTm7hleDgZnm2 W/nh9O9VN9q8DrnI9UIIjg3jOwvgRDIiXGb8PX3Q9K3KAMh73NxQ/1aSixyVWBXeUlft w6XheNLEPeHWboZ53Kfs0FnvQFBDJjOCL9pfdzEdEQWuv0dvR9YrgeeJNAIfZZyizjQh hi5Lq3j89tqJbQol7B7Ddj7yD6IkQFRwYCMcT7/VPJVqUHEHFx7KZkfQ23FJySLgKZhd 9/PA== X-Gm-Message-State: AKS2vOxkdcdP+2Eno6+PbD3RBqzOxk2GDCR3qQQG9XUbm8ugoD49krby XQNn8ESF31x460rE5vFnLw== X-Received: by 10.55.72.13 with SMTP id v13mr9330127qka.12.1497565704315; Thu, 15 Jun 2017 15:28:24 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a45sm391526qtb.16.2017.06.15.15.28.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 15:28:23 -0700 (PDT) From: Ted Lemon Message-Id: <1A5A196E-D385-458A-A403-B4776A5BF36F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_185986AC-9BC5-446D-91C9-BC4FE8E40715" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 18:28:22 -0400 In-Reply-To: Cc: "STARK, BARBARA H" , "v6ops@ietf.org" To: Warren Kumari References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 22:28:27 -0000 --Apple-Mail=_185986AC-9BC5-446D-91C9-BC4FE8E40715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2017, at 5:56 PM, Warren Kumari wrote: > I agree -- there is a huge amount of DNS breakage caused by CE trying > to be "clever" with DNS. Suggesting that vendors SHOULD implement some > sort of DNS thingie that they a: don't really want to and b: have > little skill in is likely to end in yet more pain. Warren, that's all very well and good, but it's important to understand = _why_ this is a requirement, and not just say "oh, this is a bad idea, = let's get rid of it." It's definitely true that badly-implemented proxies are a problem. So = if the problem the proxies are meant to be solved can be solved in some = easier way, it's a great idea to do that. But what is that easier way? = Alternatively, perhaps it's okay if, when my internet connection comes = up, I don't necessarily have actually connectivity for some period of = time. That's definitely easier to implement. We can even jigger the = amount of time by, for example, requiring that when the upstream = resolvers' IP addresses are not known, we give out short leases, or = require that when the connection comes back, a new RA be sent = immediately (depending on whether we're talking IPv4 or IPv6). I don't think that bringing this to DNSOP actually tells us anything. = The problem of bad DNS proxies is already well-understood in the DNSOP = working group, and indeed there's an excellent RFC that explains how to = make good (or less bad, depending on your prejudices) proxies. This is = really a host configuration problem, not a DNS problem. So what is the = value in bringing that screaming horde of = lunatics^H^H^H^H^H^H^H^H^H^H^Hwise and knowledgable bunch of IETF = greybeards into this conversation? --Apple-Mail=_185986AC-9BC5-446D-91C9-BC4FE8E40715 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 15, 2017, at 5:56 PM, Warren Kumari <warren@kumari.net> = wrote:
I agree -- there is = a huge amount of DNS breakage caused by CE trying
to be "clever" with DNS. Suggesting that vendors = SHOULD implement some
sort of DNS thingie = that they a: don't really want to and b: have
little skill in is likely to end in yet more = pain.

Warren, that's all very well and good, but it's important to = understand _why_ this is a requirement, and not just say "oh, this is a = bad idea, let's get rid of it."

It's definitely true that = badly-implemented proxies are a problem.   So if the problem the = proxies are meant to be solved can be solved in some easier way, it's a = great idea to do that.   But what is that easier way?   = Alternatively, perhaps it's okay if, when my internet connection comes = up, I don't necessarily have actually connectivity for some period of = time.   That's definitely easier to implement.   We can even = jigger the amount of time by, for example, requiring that when the = upstream resolvers' IP addresses are not known, we give out short = leases, or require that when the connection comes back, a new RA be sent = immediately (depending on whether we're talking IPv4 or IPv6).

I don't think that = bringing this to DNSOP actually tells us anything.   The problem of = bad DNS proxies is already well-understood in the DNSOP working group, = and indeed there's an excellent RFC that explains how to make good (or = less bad, depending on your prejudices) proxies.   This is really a = host configuration problem, not a DNS problem.   So what is the = value in bringing that screaming horde of = lunatics^H^H^H^H^H^H^H^H^H^H^Hwise and knowledgable bunch of IETF = greybeards into this conversation?

= --Apple-Mail=_185986AC-9BC5-446D-91C9-BC4FE8E40715-- From nobody Thu Jun 15 15:33:30 2017 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 0787212EABA for ; Thu, 15 Jun 2017 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNqOOIMExwPi for ; Thu, 15 Jun 2017 15:33:26 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E0312EAB6 for ; Thu, 15 Jun 2017 15:33:26 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id u19so40129484qta.3 for ; Thu, 15 Jun 2017 15:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=akmYlPO7ash0NuMtacBd1MBZwpKGqCmGvCA8zi09v5I=; b=O2IJuIMkxWtd/VQLqs8O2bda1DE90NHR6osRP5GAGrzVHbpPU6TWVxcu5mlsY1gATH MFiW3Y/v/9QBKw0BFN5RJFCKy6cAI0riopxvrvkc3ycdGWtc28qold96Sc/vaw5k4+Oj x/G9VvvKKtildRoVehgvFMBYPMoOsXM8WR3DvuiwaoadfGmt9+ai+1Qk1WALTnrdPx9f Ulkm1i+JyKtv2S2GW4Ky+0teTGNeVrXCWwlWfXNQax9LO1hEYbceRPCasXW+YH1WzADM M58hf1f4N1Mh91ePF6s+muFd85g3AWExKBGf0mIPFcAeKtffXXN1M3MLZPi/N7Ps9aON G3Fw== 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=akmYlPO7ash0NuMtacBd1MBZwpKGqCmGvCA8zi09v5I=; b=B8j3VTXfjW17LP0BH6nvKzpgrL0ZnFIv+f1dpl/jmWPQy4n+/b/QbgV5A1NjtIthNU hs6BWWcib9S5OCpJ28Ras5m+fDAsZjZfrCqCk5RFEyf2cBiR0LJTd6Z2KH6HdamjY0mr vey2q1JXFtHzsJA0HCwSHUkccQ8mOlz4TAo26F4OALUj8DsL+yWkWrDzgZObYDPdVHyg msemdH7aH9/l9LZVTFMBrNyzVfjC11wL5qBIl9WG5ZdKkK3ILcVfUQcyj/Ua1ZQtidLS jPLn6WmkPVBeSYt8uu17RoElOwhzrvSSME9u8NqtaqCKWWN7b6NnrJT2ZBNvnaAj5Gws COwg== X-Gm-Message-State: AKS2vOyBoAMh6BwhfBqJUR0oNaCJmlluGwXd8X119Gh3TlQsOAV5GLPu Mp1hutGfaGHfFh03 X-Received: by 10.237.44.7 with SMTP id f7mr9759417qtd.142.1497566005309; Thu, 15 Jun 2017 15:33:25 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m4sm504544qkm.9.2017.06.15.15.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 15:33:24 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3549E004-B94F-487E-81EC-D2E6ABE3A4E3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 18:33:23 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB94AED@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: IPv6 Ops WG To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94898@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94AED@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 22:33:28 -0000 --Apple-Mail=_3549E004-B94F-487E-81EC-D2E6ABE3A4E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 15, 2017, at 6:26 PM, STARK, BARBARA H wrote: > It=E2=80=99s not just about limited space. It=E2=80=99s about = needing to support the code in documentation, help desk training, fully = test the code, etc. And it=E2=80=99s about a complete lack of customer = demand for this functionality in these devices. Customers don't want their DNS to work if they power on their home = router before they power on their cheap CE router that it's plugged = into? =20 > That said, if you want to remove this requirement, you need to solve = the problem the requirement solves some other way. > =20 > Hmm. I appreciate your goal of wanting the home network to have = a name server. I even think it=E2=80=99s a really good idea for there to = be a name server in the home network. I just think a 7074-bis is the = wrong medium. It=E2=80=99s not something that=E2=80=99s needed for basic = IPv6 connectivity. Perhaps homenet could create a homenet router profile = for more functional homenet routers. I am _not talking about_ homenet naming here. The reason that CE = routers have DNS Proxies is that when the uplink isn't available and the = end-user device asks a question, the CE router has to be able to give it = an answer that will work once the uplink _is_ present. Or, the network = has to not work until the uplink is present. Either way, this violates = the principle of least surprise for the end user and generates support = desk calls, and that's why so many CE routers _do_ have DNS proxies. If there's a way around this for CE routers you send out to end users, = that's great, but you haven't explained what it is. --Apple-Mail=_3549E004-B94F-487E-81EC-D2E6ABE3A4E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 15, 2017, at 6:26 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
<bhs> It=E2=80=99s not just about = limited space. It=E2=80=99s about needing to support the code in = documentation, help desk training, fully test the code, etc. And it=E2=80=99= s about a complete lack of customer demand for this functionality in = these devices.

Customers don't want their DNS to work if they power on = their home router before they power on their cheap CE router that it's = plugged into?
 
That said, if you want to remove this = requirement, you need to solve the problem the requirement solves some = other way.
 
<bhs> Hmm. I = appreciate your goal of wanting the home network to have a name server. = I even think it=E2=80=99s a really good idea for there to be a name = server in the home network. I just think a 7074-bis is the wrong medium. = It=E2=80=99s not something that=E2=80=99s needed for basic IPv6 = connectivity. Perhaps homenet could create a homenet router profile for = more functional homenet = routers.

I am _not talking about_ homenet naming here.   The = reason that CE routers have DNS Proxies is that when the uplink isn't = available and the end-user device asks a question, the CE router has to = be able to give it an answer that will work once the uplink _is_ = present.   Or, the network has to not work until the uplink is = present.   Either way, this violates the principle of least = surprise for the end user and generates support desk calls, and that's = why so many CE routers _do_ have DNS proxies.

If there's a way around this for CE = routers you send out to end users, that's great, but you haven't = explained what it is.

= --Apple-Mail=_3549E004-B94F-487E-81EC-D2E6ABE3A4E3-- From nobody Thu Jun 15 16:25:09 2017 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 ED0DB12EAF0 for ; Thu, 15 Jun 2017 16:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 FuiMeuZdN9fs for ; Thu, 15 Jun 2017 16:25:06 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 6D9D71294DB for ; Thu, 15 Jun 2017 16:25:06 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5FM5bJw023910; Thu, 15 Jun 2017 18:13:31 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2b40394n7f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 18:13:31 -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 v5FMDUdU020560; Thu, 15 Jun 2017 18:13:30 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5FMDOAD020462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 18:13:26 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 15 Jun 2017 22:13:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Thu, 15 Jun 2017 18:13:09 -0400 From: "STARK, BARBARA H" To: Fred Baker CC: "v6ops@ietf.org" Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAXzxMAAAfgvIA= Date: Thu, 15 Jun 2017 22:13:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.196.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_11:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150382 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 23:25:08 -0000 > So - you are suggesting that L-12 be worded similarly to TR-124: "*IF* ..= . > *THEN* ...". Right? Yes.=20 But... I phrased it obtusely in case others had different goals in mind. I wasn't = sure whether the goal was to recommend implementing a forwarding proxy, or = recommending that a forwarding proxy be implemented according to RFC 5625. Per Ted's response, it appears the goal was to recommend implementing a for= warding proxy to support a name server. My proposed words wouldn't address = that. Barbara From nobody Thu Jun 15 17:02:10 2017 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 C169812951F for ; Thu, 15 Jun 2017 17:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Uig4o0yBwxqZ for ; Thu, 15 Jun 2017 17:02:07 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F10128B8F for ; Thu, 15 Jun 2017 17:02:07 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C47BB34942F; Fri, 16 Jun 2017 00:02:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AE4EC160099; Fri, 16 Jun 2017 00:02:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 94D69160097; Fri, 16 Jun 2017 00:02:03 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mZQGNu2PmNRa; Fri, 16 Jun 2017 00:02:03 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 42088160069; Fri, 16 Jun 2017 00:02:03 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D44D47BC77F3; Fri, 16 Jun 2017 10:02:00 +1000 (AEST) To: "STARK, BARBARA H" Cc: Fred Baker , "v6ops@ietf.org" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-reply-to: Your message of "Thu, 15 Jun 2017 22:13:08 +0000." <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 16 Jun 2017 10:02:00 +1000 Message-Id: <20170616000200.D44D47BC77F3@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 00:02:09 -0000 DNS proxies are a cop out by router manufactures. Routers need full blown DNS VALIDATING RECURSIVE SERVERS which also are authoritative for the local zones of the home as well as for locally served dns zones [1]. If you do to do a proxy there SHOULD be seperate addresses advertised for each upstream server so that the properties of the upstream servers are not mixed and so that extensions like DNS COOKIE (RFC 7873) work. If the proxy talks to multiple upstream servers that support DNS COOKIE the unnecessary BADCOOKIE due to the proxy mixing transaction streams will result in unnecessary TCP fallback. If the reply to a retried request with a fresh Server Cookie is BADCOOKIE, the client SHOULD retry using TCP as the transport, since the server will likely process the request normally based on the security provided by TCP (see Section 5.2.3). Mark [1] https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml. In message <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com>, "STARK, BARBARA H" writes: > > So - you are suggesting that L-12 be worded similarly to TR-124: "*IF* ... > > *THEN* ...". Right? > > Yes. > But... > I phrased it obtusely in case others had different goals in mind. I wasn't sure whether the goal was to recommend implem > enting a forwarding proxy, or recommending that a forwarding proxy be implemented according to RFC 5625. > Per Ted's response, it appears the goal was to recommend implementing a forwarding proxy to support a name server. My pr > oposed words wouldn't address that. > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 15 17:44:34 2017 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 637DE126D85 for ; Thu, 15 Jun 2017 17:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ordnance-co.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sQ0TYGHFKyl for ; Thu, 15 Jun 2017 17:44:30 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83686126E3A for ; Thu, 15 Jun 2017 17:44:30 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m62so26962132itc.0 for ; Thu, 15 Jun 2017 17:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ordnance-co.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:content-language:content-transfer-encoding :mime-version; bh=QVhxOCRb+TVFSkRMmmfZNRnccLV3Wxr6nodK5aoGg4w=; b=siQFhjSQCfEn3gKl/ybaEpV7V50CNlF8a+iDaM3t1GSHVjeq5/DNJ3nI5959IGy23d Z9Z24ftN6OXG0PPSqXlRjWqcXltEsDCpTUGB4gioXwggHq4ODgnPRiHoIEBwtNTSA1pq sfzM0Qo5claosu0GkWRR0MMAQIDOkHuCP31Qimvxx0E2rEkdPqzyIYJJZ1DJOX7LUM8i WP3Htnvj1hzR/MjndbdVR2sxWFwB0bz51KLIrPC7wAPPgn8nUGOOUwqdsh2kn3IR/nfp EUvbpPdYt/f767kUfSJFMj8gVoWdTPLbYfGrSx3F4R3yrph/UjZbcUoBwubBys2XrkHW keNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:content-language :content-transfer-encoding:mime-version; bh=QVhxOCRb+TVFSkRMmmfZNRnccLV3Wxr6nodK5aoGg4w=; b=nwoF8L/QmaHhrs9gDv/S/CsHnnDTNgk3f1E0K+Hp/o9HaBUYFzj2zB78hTD08knaKQ Rm7BqXNDlhZ4tmisAjqgrCTnau34ORAQS+ts9YlqUN8Ay9GRsfi4bSnNnBWs8tViAjVh GmU2NtKGZ23PhvizB7PN/k8QEKxaWpAZtXtxNpeFh+9n8wwm84+65HRFEyI1h89NH2Tt HZ9yHds8ZlZ0l8opgC8kinpkOBQ7UORuiPB5clbfU2P1F03RWUgZnQRmjvN1dTIpwPG2 XnHEadB+MyrFDm9Y65WWFkQigncTNOd07k9PZ9DMotOiPWMTNW8W8uXXadqJijGyX3qR dPgA== X-Gm-Message-State: AKS2vOylz0LLvFd34GT7teaMBab1UdNOGNsJitp5b/LuXQ2rmYIuA0dh cGCGOE7lPaLcsMWFtZeBLQ== X-Received: by 10.36.17.198 with SMTP id 189mr8100770itf.17.1497573869689; Thu, 15 Jun 2017 17:44:29 -0700 (PDT) Received: from PS1PR03MB1467.apcprd03.prod.outlook.com ([40.96.2.253]) by smtp.gmail.com with ESMTPSA id u191sm869618ita.22.2017.06.15.17.44.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jun 2017 17:44:29 -0700 (PDT) From: David Hooton To: Mark Andrews CC: "v6ops@ietf.org" Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AUExQ0NE5/Y1f7lXuChACaHbZP2Y0jNEQTQ5NTFDQ0Q1NTkxdTNCNDIxnOKFUz4= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 16 Jun 2017 00:44:26 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170616000200.D44D47BC77F3@rock.dv.isc.org> In-Reply-To: <20170616000200.D44D47BC77F3@rock.dv.isc.org> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 00:44:32 -0000 On 16/6/17, 10:02 am, "v6ops on behalf of Mark Andrews" wrote: DNS proxies are a cop out by router manufactures. Routers need full blown DNS VALIDATING RECURSIVE SERVERS which also are authoritativ= e for the local zones of the home as well as for locally served dns zones [1]. =20 Mark this is completely crazy and if we were to do it the world would end. = How many CPE=92s have you ever seen that en-masse run current, secure and p= atched versions of the daemons they use? If the standard becomes every CPE = running a full blown DNS resolver, I predict it will take ~6 weeks before w= e see the first in a long and agonising list of DNS based denial of service= s and mass CPE compromises. Further to this it will take approximately 10 y= ears before the problem is resolved by the CPE in question failing/being ta= ken out of service. As an operator, I would be far more comfortable with the CPE being as light= as humanly possible with as few running processes as possible using a mech= anism that refers all subscriber requests on my network to my centralised, = secure and properly maintained resolver/ntp/whatever infrastructure. Instea= d of making things more complicated or expecting that upstream servers supp= ort something special, I would suggest that the user get what they should w= hen a service isn=92t working =96 a failure with a short TTL. Once the link= comes up their service should start working.=20 Having a full blown resolver on the CPE isn=92t going to give the user a di= fferent outcome in a link down situation =96 the lookup is going to fail re= gardless so if you want DNS proxies gone why not get rid of DNS resolution = on the CPE all together? Short TTL leases aren=92t a terrible way of doing this, you would just need= to be careful that it doesn=92t spiral into a denial of service on the CPE= so lease times would need to back off incrementally after say 15 minutes. Kind Regards, David Hooton Founder | Ordnance Cloud Scale, Carrier Grade P: +61415850000 T: @dave_hooton W: ordnance.co =20 From nobody Thu Jun 15 17:53:15 2017 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 57FA0127077 for ; Thu, 15 Jun 2017 17:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 LqQqlMfRYkvE for ; Thu, 15 Jun 2017 17:53:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 47F1C124BE8 for ; Thu, 15 Jun 2017 17:53:11 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5FMPW1h005388; Thu, 15 Jun 2017 18:26:59 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2b411g5v1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 18:26:59 -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 v5FMQwK8032751; Thu, 15 Jun 2017 18:26:58 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5FMQsTo032694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Jun 2017 18:26:54 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 15 Jun 2017 22:26:47 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Thu, 15 Jun 2017 18:26:47 -0400 From: "STARK, BARBARA H" To: Ted Lemon CC: IPv6 Ops WG Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAQkasAAAYWBAD//6SSPf//4nKQgACGDICAAD1xcA== Date: Thu, 15 Jun 2017 22:26:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB94AED@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94531@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94898@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.196.253] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DB94AEDGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_11:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150387 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 00:53:13 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DB94AEDGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If it's got a DHCP server, it's hard to see why it can't have a DNS proxy. = I wrote a pretty fancy one that adds edns0 options one way and drops them= the other (meaning it's remembering outstanding transactions). It's about= 32k of code, compiled, with packet dump code for debugging still in. I s= uspect if you took out all the stuff that's not needed for a bare DNS proxy= , it would be more like 16k. I realize that cheap CE routers have limited= space, but it's hard to believe that their space is _that_ limited. It's not just about limited space. It's about needing to support the = code in documentation, help desk training, fully test the code, etc. And it= 's about a complete lack of customer demand for this functionality in these= devices. That said, if you want to remove this requirement, you need to solve the pr= oblem the requirement solves some other way. Hmm. I appreciate your goal of wanting the home network to have a nam= e server. I even think it's a really good idea for there to be a name serve= r in the home network. I just think a 7074-bis is the wrong medium. It's no= t something that's needed for basic IPv6 connectivity. Perhaps homenet coul= d create a homenet router profile for more functional homenet routers. Barbara --_000_2D09D61DDFA73D4C884805CC7865E6114DB94AEDGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

If it's got a DHCP server, it's hard to see why it c= an't have a DNS proxy.   I wrote a pretty fancy one that adds edns0 op= tions one way and drops them the other (meaning it's remembering outstandin= g transactions).  It's about 32k of code, compiled, with packet dump code for debugging still in.   I suspect i= f you took out all the stuff that's not needed for a bare DNS proxy, it wou= ld be more like 16k.   I realize that cheap CE routers have limited sp= ace, but it's hard to believe that their space is _that_ limited.

 

<bhs> It’s not just about= limited space. It’s about needing to support the code in documentati= on, help desk training, fully test the code, etc. And it’s about a complete lack of customer demand for this functionality in these devices= .

 

That said, if you want to remove this requirement, y= ou need to solve the problem the requirement solves some other way.

 

<bhs> Hmm. I appreciate your go= al of wanting the home network to have a name server. I even think it’= ;s a really good idea for there to be a name server in the home network. I just think a 7074-bis is the wrong medium. It’s not = something that’s needed for basic IPv6 connectivity. Perhaps homenet = could create a homenet router profile for more functional homenet routers.

Barbara

--_000_2D09D61DDFA73D4C884805CC7865E6114DB94AEDGAALPA1MSGUSRBF_-- From nobody Thu Jun 15 18:27:26 2017 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 31D6F129408 for ; Thu, 15 Jun 2017 18:27:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GRuQXYZEO9W for ; Thu, 15 Jun 2017 18:27:23 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3E01205F1 for ; Thu, 15 Jun 2017 18:27:22 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c10so44221046qtd.1 for ; Thu, 15 Jun 2017 18:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tjxLqRdXkgsgVwl2NOXQ8vYX5GTJib2N9HBSLjj8JX8=; b=Q40vdnNPkF5N6gFh1EQJlkQCMvv4KNVDkz6zqlBQIBagOiQ8OW21LJWKdRZmF9r98k RfW52GpfnqnGrUBQtaZr/OFXp3W+1IW21qF4L8jBoo6VJn8OhN97EZt6RkPEQMq9MJeX ipzmrkfxCtef4npvJr+NXg4CsXCDw0xKXYZlgXy7/nUZDS4Axs2Ey/Tor2gscIkqzLbU kOQpQQ3zOf0QR+1BgHJIFru/sb2bs+fCYbTRCu4SlyoqSWXsx1NUB3E3FZKUzXnb99Th xUjwX9+3NN5Ffrjl7ibxL92ZiLqoxqnGQa38sLvYqjc+9Aucz50gEi4ZMiNG8NSkS8Vp RRwg== 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=tjxLqRdXkgsgVwl2NOXQ8vYX5GTJib2N9HBSLjj8JX8=; b=fZHTnvFuLg0NGSWp9W/GPbJuj5HvT8NWG0KW1bkSmN3I4NOzsORNpmapNzhDpM/ykj B6nIF/aHpsHTo8UVxWS0Si0N79/0D+ADgdqeyY5lMd5x1/JPpYtTVjNfcnO2SApVPDvG 6s3uU2B+KJqgAnF+nq0qDRfD/PVH6+P/ZM0AE/beQ/0Fa5ZL3wd1fFS9+kEZLoqgWddc xTR9sK4M19R3krXUQIQco97GCSsGpGEy3KsileD2R+hIQgwWoXRLUR3cDoKEVTuZ5duG Jn+uDIlOtqGgXLxxUmWczQxHehxrJxsTzXikvcUYO3lKoBO4ME5Vp9OhEpwCOrmGsXhZ Kp0w== X-Gm-Message-State: AKS2vOwy3PodIFhCKV5UlLaLIdzZXDGHHSKhCMdKSV144Jh+0+5AFGJI JmHDXeRl/x3IIq8F X-Received: by 10.237.61.39 with SMTP id g36mr9748422qtf.60.1497576442163; Thu, 15 Jun 2017 18:27:22 -0700 (PDT) Received: from macbook-pro-6.lan (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f85sm763715qkh.6.2017.06.15.18.27.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 18:27:21 -0700 (PDT) From: Ted Lemon Message-Id: <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B343A8C3-1399-4DB3-98DB-4119515B48D0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 21:27:19 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Fred Baker , "v6ops@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:27:25 -0000 --Apple-Mail=_B343A8C3-1399-4DB3-98DB-4119515B48D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2017, at 6:13 PM, STARK, BARBARA H wrote: > Per Ted's response, it appears the goal was to recommend implementing = a forwarding proxy to support a name server. My proposed words wouldn't = address that. As has been pointed out to me off-list, one way to solve this problem is = to simply eliminate any mention of DHCPv6 on the home LAN. If the only = way to get a DNS configuration is RDNSS, then the need for the proxy = goes away. Unfortunately, the problem remains if the device supports any of the = IPv4 transition mechanism that provide IPv4 on the LAN. A good reason = to just use NAT64, but of course I'm sure that's a can of worms nobody = wants to open. :) --Apple-Mail=_B343A8C3-1399-4DB3-98DB-4119515B48D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 15, 2017, at 6:13 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
Per Ted's response, = it appears the goal was to recommend implementing a forwarding proxy to = support a name server. My proposed words wouldn't address = that.

As = has been pointed out to me off-list, one way to solve this problem is to = simply eliminate any mention of DHCPv6 on the home LAN.   If the = only way to get a DNS configuration is RDNSS, then the need for the = proxy goes away.

Unfortunately, the problem remains if the device supports any = of the IPv4 transition mechanism that provide IPv4 on the LAN.   A = good reason to just use NAT64, but of course I'm sure that's a can of = worms nobody wants to open. :)

= --Apple-Mail=_B343A8C3-1399-4DB3-98DB-4119515B48D0-- From nobody Thu Jun 15 18:48:27 2017 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 F3445128799 for ; Thu, 15 Jun 2017 18:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 UUlgiZ9JCPT4 for ; Thu, 15 Jun 2017 18:48:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5E71205F1 for ; Thu, 15 Jun 2017 18:48:22 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 78CEA34930F; Fri, 16 Jun 2017 01:48:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 52BD6160069; Fri, 16 Jun 2017 01:48:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 07E5B16007A; Fri, 16 Jun 2017 01:48:19 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4fPcnlgvEuxZ; Fri, 16 Jun 2017 01:48:18 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 52B89160069; Fri, 16 Jun 2017 01:48:18 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 450A77BC8ACF; Fri, 16 Jun 2017 11:48:15 +1000 (AEST) To: David Hooton Cc: "v6ops@ietf.org" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170616000200.D44D47BC77F3@rock.dv.isc.org> In-reply-to: Your message of "Fri, 16 Jun 2017 00:44:26 +0000." Date: Fri, 16 Jun 2017 11:48:15 +1000 Message-Id: <20170616014815.450A77BC8ACF@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:48:26 -0000 In message , David Hooton writes: > On 16/6/17, 10:02 am, "v6ops on behalf of Mark Andrews" > wrote: > DNS proxies are a cop out by router manufactures. Routers need > full blown DNS VALIDATING RECURSIVE SERVERS which also are > authoritative > for the local zones of the home as well as for locally served dns > zones [1]. > > Mark this is completely crazy and if we were to do it the world would > end. How many CPE's have you ever seen that en-masse run current, secure > and patched versions of the daemons they use? If the standard becomes > every CPE running a full blown DNS resolver, I predict it will take ~6 > weeks before we see the first in a long and agonising list of DNS based > denial of services and mass CPE compromises. Further to this it will take > approximately 10 years before the problem is resolved by the CPE in > question failing/being taken out of service. All I see here is FUD. DNS servers are not like you portray them to be and yes I am acutely aware of how many CVE notices we (ISC) have issued and what they are for [1]. I'm also aware that they are almost always for the server choosing to shut itself down rather than continuing to run in a known bad state. I also know that running the nameserver from launchd or as a Windows service with restart enabled mitigates the issue. ISC however can't assume that that is the case so we issue CVE notices. [1] https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html > As an operator, I would be far more comfortable with the CPE being as > light as humanly possible with as few running processes as possible using > a mechanism that refers all subscriber requests on my network to my > centralised, secure and properly maintained resolver/ntp/whatever > infrastructure. Instead of making things more complicated or expecting > that upstream servers support something special, I would suggest that the > user get what they should when a service isn't working, a failure with a > short TTL. Once the link comes up their service should start working. So basically stuff the home user when the link is down rather than keep what is reachable working. > Having a full blown resolver on the CPE isn't going to give the user a > different outcome in a link down situation , the lookup is going to fail > regardless so if you want DNS proxies gone why not get rid of DNS > resolution on the CPE all together? So you don't think internal services should continue to work when the link is down. That customer privacy shouldn't be preserved. DNS proxies leak like a sieve when it comes to customer privacy. > Short TTL leases aren't a terrible way of doing this, you would just need > to be careful that it doesn't spiral into a denial of service on the CPE > so lease times would need to back off incrementally after say 15 minutes. > > Kind Regards, > > David Hooton > Founder | Ordnance > Cloud Scale, Carrier Grade > P: +61415850000 T: @dave_hooton W: ordnance.co -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 15 19:09:31 2017 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 F34B7128BA2 for ; Thu, 15 Jun 2017 19:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxHw_EsIbI1G for ; Thu, 15 Jun 2017 19:09:28 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DDF127241 for ; Thu, 15 Jun 2017 19:09:28 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id w1so44874275qtg.2 for ; Thu, 15 Jun 2017 19:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VATPtbwibMKbfpnJpEPWHgReNjj2namdWQqdRpFlRyQ=; b=e3gUf3tmTbSrYayAz0fPIrcWil6RPwtCI1+74FuMkBQLgleaozGCeqf9g8YKmnRlA3 DF+EtHL9t2SVWfX377nfqYfTkKX3SoMkDf8og+5RRfwB6TK0vVkwJXIEeMKqUFMZK1M4 XuCvupediF8nt8zj6Uq+sMnhpL2fVBsp+DvLpY5b7M34zIBe/c6FHlBuF7fpoDYvwvP/ ED27Vy8KT4Xb33CtT9Z/KIwpyT4cCnuU+SqgqsWZjQEvekEoGUjOupmFesMWQffXW6uv gBwlDlNnyzyyYKpKYP4EPGCE6aoJYrQtT9PpvkYHWvEUjFIQmqq0r7J9x/UVj2TI8c5X idjg== 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=VATPtbwibMKbfpnJpEPWHgReNjj2namdWQqdRpFlRyQ=; b=N75xqL5QMTH6pVtpJFZG7ezIQmCHQ0nndjwvbU9mFOEozaWHCHdFZ6apQewQEu9DS/ mjZl+bJkfPKmlxmNzjhE9Ml0J35jH84wU2x7b9jf065jsPapzs7OI+EaL1sVr/darsgl zhRkpOLWn43dNMBbxP5aMcpzkrdIg7p3E4jtKcHqK20tuj6FN8wlmfsTWzsKriIxkTW+ hhdWhpRpDEMxNI9KgZkrl84fKLL4LfmJGkRsjD8WEOliHRS+a84AJfiZRH8DBLP9Yp1C XLxU1lsl5TP/uMao5BM0Si0gQdt9F5d3Ib4moPeAluaqto2ycHnFdMcofmph3Wi2IlF6 Nx6Q== X-Gm-Message-State: AKS2vOxzCmuOoXxvxJ9Ygwp83vSVwCuj9KUXcMMNWHZEcBaLM5HR7oqV skrKwwJCJ/eR0pns X-Received: by 10.55.95.194 with SMTP id t185mr9761391qkb.119.1497578967627; Thu, 15 Jun 2017 19:09:27 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m14sm273618qki.35.2017.06.15.19.09.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 19:09:26 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_899E3C6D-FA38-4D89-9C8A-B0A4D93BB56E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 22:09:25 -0400 In-Reply-To: <20170616014815.450A77BC8ACF@rock.dv.isc.org> Cc: David Hooton , "v6ops@ietf.org" To: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170616000200.D44D47BC77F3@rock.dv.isc.org> <20170616014815.450A77BC8ACF@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 02:09:31 -0000 --Apple-Mail=_899E3C6D-FA38-4D89-9C8A-B0A4D93BB56E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 15, 2017, at 9:48 PM, Mark Andrews wrote: > So you don't think internal services should continue to work when > the link is down. That customer privacy shouldn't be preserved. > DNS proxies leak like a sieve when it comes to customer privacy. Mark, this is the IPv6 router requirements document, not the Homenet = router requirements document. Even in the latter case, getting a full = DNS server into the router is a bit of a sticky wicket, but it can't be = required in 7084-bis, because that's not the target use case. --Apple-Mail=_899E3C6D-FA38-4D89-9C8A-B0A4D93BB56E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 15, 2017, at 9:48 PM, Mark Andrews <marka@isc.org> = wrote:
So you don't think = internal services should continue to work when
the link is down.  That customer privacy = shouldn't be preserved.
DNS proxies leak = like a sieve when it comes to customer = privacy.

Mark, this is the IPv6 router requirements document, not the = Homenet router requirements document. Even in the latter case, getting a = full DNS server into the router is a bit of a sticky wicket, but it = can't be required in 7084-bis, because that's not the target use = case.

= --Apple-Mail=_899E3C6D-FA38-4D89-9C8A-B0A4D93BB56E-- From nobody Thu Jun 15 20:15:51 2017 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 8741F1277BB for ; Thu, 15 Jun 2017 20:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 86-rgvkPUSZC for ; Thu, 15 Jun 2017 20:15:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2BE126C3D for ; Thu, 15 Jun 2017 20:15:49 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B2C833493A5; Fri, 16 Jun 2017 03:15:46 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A0896160069; Fri, 16 Jun 2017 03:15:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8EB0816007A; Fri, 16 Jun 2017 03:15:46 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pKgbztaQ8q8F; Fri, 16 Jun 2017 03:15:46 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4657B160069; Fri, 16 Jun 2017 03:15:46 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D0C147BCB18D; Fri, 16 Jun 2017 13:15:43 +1000 (AEST) To: Ted Lemon Cc: "STARK, BARBARA H" , "v6ops@ietf.org" From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com> In-reply-to: Your message of "Thu, 15 Jun 2017 21:27:19 -0400." <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com> Date: Fri, 16 Jun 2017 13:15:43 +1000 Message-Id: <20170616031543.D0C147BCB18D@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 03:15:50 -0000 In message <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com>, Ted Lemon writes: > > On Jun 15, 2017, at 6:13 PM, STARK, BARBARA H wrote: > > Per Ted's response, it appears the goal was to recommend implementing a > > forwarding proxy to support a name server. My proposed words wouldn't > > address that. > > As has been pointed out to me off-list, one way to solve this problem is > to simply eliminate any mention of DHCPv6 on the home LAN. If the only > way to get a DNS configuration is RDNSS, then the need for the proxy goes > away. How the DNS recursive service is implemented (local recursive, proxy, remote recursive) is independent of the mechanism to discover it (DHCPv6, RDNSS). > Unfortunately, the problem remains if the device supports any of the IPv4 > transition mechanism that provide IPv4 on the LAN. A good reason to > just use NAT64, but of course I'm sure that's a can of worms nobody wants > to open. :) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 15 23:58:55 2017 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 059DC12EC85 for ; Thu, 15 Jun 2017 23:58:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ordnance-co.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mCXNK8tXdhs for ; Thu, 15 Jun 2017 23:58:52 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5A912EC7E for ; Thu, 15 Jun 2017 23:58:45 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id k71so16967507pgd.2 for ; Thu, 15 Jun 2017 23:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ordnance-co.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:content-language:content-transfer-encoding :mime-version; bh=ozY7v3IClBixm9C8lQ1x4ZvhvnSWOFcnwt4j8XSM7HM=; b=mACicp4DPluukq1FEMYmS4RomFlquu5ZN63/+4nMa8uKTlsTLcKxPuG0z7CI3c5nr0 8Y/IanQdsmgx4oFIOMRbiR0eZpUnbxC+ipupSRJoWuOnz6Nk7v9nIYrdGjMs7ed+jyls 9WZ2tS0dS4+9e7efC9nj149APT8FgpuOenrhOCqGzxyPpujfvCvLTe7+DiYohA8SqTQt E2iMrJvScLGXJof9XntPA8EerjWom+pfyITseI3U6ceM0lGjBYBOknyUOYAtJgLB1xoG pFqjJR1AEVlh52ZCrdr9IEWdOVUu8WEug7m7E8gGa/zxTSLh4evylqWmga89jcnzMQtr ro/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:content-language :content-transfer-encoding:mime-version; bh=ozY7v3IClBixm9C8lQ1x4ZvhvnSWOFcnwt4j8XSM7HM=; b=n2DU/TU/16a/k+7pB0BsJyzTJKPJbhnF+ZC2y2ajSaYmRBRjej7RL8aV/aRL3qbnVP 2EPEv26GJHsRwyJMyvGIM56AZGDc4sFhF4Q9cYRCO5ycD9qdmKz3vC+YdRxGqQs3woOC Er07cnxtvSIWAUhKWhkL5o6PzGTVFKWm2t7g9RQ/kjOW3jxaQ1HQ2cItLOt9aYF/GPdv m9kp+MHXgoU89F+voHWcQiLqdrVcRBr19K2+L21b7zSHVgVUGAEto12bX7a7+syl+n5u Yw7CwS89MYBZPwmVvZqFApFUT6p+HrAwX9gXtgxJ2+UeQHlqCdWkW0ZmOgIkvo6tfc4C mbtA== X-Gm-Message-State: AKS2vOwDTluS0KPjpSFa5FvaNyUxWpVL+9YmU+U9R3XnQb9F8fBI5Kus j1YUGS3K/IySkuV2 X-Received: by 10.84.143.70 with SMTP id 64mr10882279ply.36.1497596325479; Thu, 15 Jun 2017 23:58:45 -0700 (PDT) Received: from PS1PR03MB1467.apcprd03.prod.outlook.com ([40.96.2.253]) by smtp.gmail.com with ESMTPSA id q76sm2444189pfg.117.2017.06.15.23.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jun 2017 23:58:44 -0700 (PDT) From: David Hooton To: Mark Andrews CC: "v6ops@ietf.org" Thread-Topic: [v6ops] 7084-bis DNS proxy requirement Thread-Index: AUExQ0NE5/Y1f7lXuChACaHbZP2Y0jNEQTQ5NTFDQ0QzQjQyMTAxRDcxMEQgNiBGQjU4MZlW2t0M X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 16 Jun 2017 06:58:38 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170616000200.D44D47BC77F3@rock.dv.isc.org> <20170616014815.450A77BC8ACF@rock.dv.isc.org> In-Reply-To: <20170616014815.450A77BC8ACF@rock.dv.isc.org> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 06:58:54 -0000 On 16/6/17, 11:48 am, "Mark Andrews" wrote: > Mark this is completely crazy and if we were to do it the world would > end. How many CPE's have you ever seen that en-masse run current, sec= ure > and patched versions of the daemons they use? If the standard becomes > every CPE running a full blown DNS resolver, I predict it will take ~= 6 > weeks before we see the first in a long and agonising list of DNS bas= ed > denial of services and mass CPE compromises. Further to this it will = take > approximately 10 years before the problem is resolved by the CPE in > question failing/being taken out of service. =20 All I see here is FUD. DNS servers are not like you portray them to be and yes I am acutely aware of how many CVE notices we (ISC) have issued and what they are for [1]. =20 I used drama to communicate a point and I apologise if it made the message = less clear. My point wasn=92t that the guys writing DNS daemons don=92t kno= w what they are doing because we all know you guys are excellent at what yo= u do.=20 My point was - why would you want, by default to install code that can, wil= l and absolutely should require updating more often than once every 10 year= s onto some of most poorly maintained and patched infrastructure on the int= ernet? There are far better maintained places for this kind of network func= tion to exist that ARE well maintained, often automatically by OS and appli= cation vendors.=20 > As an operator, I would be far more comfortable with the CPE being as > light as humanly possible with as few running processes as possible u= sing > a mechanism that refers all subscriber requests on my network to my > centralised, secure and properly maintained resolver/ntp/whatever > infrastructure. Instead of making things more complicated or expectin= g > that upstream servers support something special, I would suggest that= the > user get what they should when a service isn't working, a failure wit= h a > short TTL. Once the link comes up their service should start working. =20 So basically stuff the home user when the link is down rather than keep what is reachable working. =20 Yes 100% absolutely when the device is configured in its default state.=20 The abstract of the RFC we are discussing says that it is specifically talk= ing about: =93the basic provisioning of an IPv6 CE router and the provision= ing of IPv6 hosts attached to it=94. To me this means provide the most simp= le possible service that when connected to a working internet connection al= locates client hosts a routable IPv6 address(es) and advertises whatever ot= her services are required for the host to configure itself in order to make= the address if has been allocated useful, in this case DNS. If the vendor chooses to offer a full blown locally installed resolver as a= configurable option and the user/service provider chooses to activate it t= here should be nothing preventing them from doing so. This doesn=92t mean t= hat full blown resolvers should be an RFC defined default because it is not= required for the basic connection to work, it is a nice to have. > Having a full blown resolver on the CPE isn't going to give the user = a > different outcome in a link down situation , the lookup is going to f= ail > regardless so if you want DNS proxies gone why not get rid of DNS > resolution on the CPE all together? =20 So you don't think internal services should continue to work when the link is down. That customer privacy shouldn't be preserved. DNS proxies leak like a sieve when it comes to customer privacy. There are plenty of application/OS level options available for local name r= esolution that don=92t require the CPE to be the local network resolver or = even to be online. DNS proxies only leak what the applications using them r= equest, networks are meant to deliver packets as efficiently as possible to= their destinations not fix/prevent errors further up the stack. This problem might be resolved by network functions that sit on the CPE, bu= t are definitely don=92t fall within basic provisioning of an IPv6 CE or th= e hosts attached to it. Kind Regards, David Hooton Founder | Ordnance Cloud Scale, Carrier Grade P: +61415850000 T: @dave_hooton W: ordnance.co =20 From nobody Fri Jun 16 00:26:16 2017 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 6BCD9131551 for ; Fri, 16 Jun 2017 00:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpYSnRPTa4J5 for ; Fri, 16 Jun 2017 00:26:13 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7A5131530 for ; Fri, 16 Jun 2017 00:24:21 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id 84so10209508ybe.0 for ; Fri, 16 Jun 2017 00:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PcXh3FuYZ/3Sqk89XQdx6tgag6VYjPSGvijCxCu3uKI=; b=kaKiFEAXiTiUYy3zplash5LKnp5ICS+ZtV6keOkY9IeQze5MVGzyQS/2zBD4kzaXDu u81qb/3MArLPVfexyvmuw0Gp1Fc8Lf9nlkwlerRmdZIYmRmgP0/gNN50i5NY5uo50ULK ZtxZ9Rkh12N3GL5gCkbAVH1CXgeNelHslsuGXz8HQFkoJYFOyH+9Spu5OKPSW3nHxFar pmUtdWCVfFtY4sss2TL5gRwAz9Wx6GjWy3tAJqw8u0NFjbh4qUs/cg6tFFOc602FTmFX NuDZ+eTfVFcEuHQ8hI62daRJgaTSgy9aHVws0hMbV1ckm46nyWPy8Xsf86reWjioOKb0 RDXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PcXh3FuYZ/3Sqk89XQdx6tgag6VYjPSGvijCxCu3uKI=; b=X28B+QdVE/fSMxQzKGFdso3z7H1dVM8GGu7UR8xirAM3+SU2u2tflqopuHx7NTug4K jNgqThJtBITbOKUrLPuUv9iH8XyWWBJuH4H3sIX+fPNv0hR/79lK7uslzzG3BagJmQmO GAhnT3MV6EJKPtfA1IPg7o5gQtYNJrGQbidefHPlj3VS/M+gjw8yw7C3v7P7hIk3lti4 yCme3KUr2zHIyf66u+v8LzIF824GotSTiagmgS6Ufh/Edvq2j8QQdXQ/2xmfMHb88XC0 x2JGQjSQZnEEa2j+D4g8l+IddjTbv7ux9SvCm0E59bJMQFIwlULWWUT8boZmHYm+42P/ WrWg== X-Gm-Message-State: AKS2vOwb5HjCgt3ltoQ7dlOT7ATLjJRZq52PDar6gq14qjMfqWwdruOP r2LqjD+YyuW5SpJZtcE3cJG5NndFirQd X-Received: by 10.37.48.193 with SMTP id w184mr7757059ybw.193.1497597860883; Fri, 16 Jun 2017 00:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.141 with HTTP; Fri, 16 Jun 2017 00:24:00 -0700 (PDT) In-Reply-To: <20170616031543.D0C147BCB18D@rock.dv.isc.org> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DB94A75@GAALPA1MSGUSRBF.ITServices.sbc.com> <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com> <20170616031543.D0C147BCB18D@rock.dv.isc.org> From: Erik Kline Date: Fri, 16 Jun 2017 16:24:00 +0900 Message-ID: To: Mark Andrews Cc: Ted Lemon , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148b4ae89e1b005520eace3" Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 07:26:15 -0000 --001a1148b4ae89e1b005520eace3 Content-Type: multipart/alternative; boundary="001a1148b4ae843d9f05520eac30" --001a1148b4ae843d9f05520eac30 Content-Type: text/plain; charset="UTF-8" On 16 June 2017 at 12:15, Mark Andrews wrote: > > In message <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com>, Ted Lemon > writes: > > > > On Jun 15, 2017, at 6:13 PM, STARK, BARBARA H wrote: > > > Per Ted's response, it appears the goal was to recommend implementing a > > > forwarding proxy to support a name server. My proposed words wouldn't > > > address that. > > > > As has been pointed out to me off-list, one way to solve this problem is > > to simply eliminate any mention of DHCPv6 on the home LAN. If the only > > way to get a DNS configuration is RDNSS, then the need for the proxy goes > > away. > > How the DNS recursive service is implemented (local recursive, > proxy, remote recursive) is independent of the mechanism to discover > it (DHCPv6, RDNSS). > Except in so much as it's entangled with which nameserver IP address the CPE hands out if it does run a proxy. If the CPE is announcing a non-stable DNS server IP (i.e. one formed from the address space PD'd to it and assuming that prefix can change in future) it will want to be able to deprecate that nameserver and replace it with a new one. Only one of these two protocols supports doing this nicely. --001a1148b4ae843d9f05520eac30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 1= 6 June 2017 at 12:15, Mark Andrews <marka@isc.org> wrote:

In message <206DF35B-A141-494B-BB29-C4FE59DE9A6B@fugue.com>, Ted Lemo= n writes:
>
> On Jun 15, 2017, at 6:13 PM, STARK, BARBARA H <bs7652@att.com> wrote:
> > Per Ted's response, it appears the goal was to recommend impl= ementing a
> > forwarding proxy to support a name server. My proposed words woul= dn't
> > address that.
>
> As has been pointed out to me off-list, one way to solve this problem = is
> to simply eliminate any mention of DHCPv6 on the home LAN.=C2=A0 =C2= =A0If the only
> way to get a DNS configuration is RDNSS, then the need for the proxy g= oes
> away.

How the DNS recursive service is implemented (local recursive,
proxy, remote recursive) is independent of the mechanism to discover
it (DHCPv6, RDNSS).

Except in so much a= s it's entangled with which nameserver IP address the CPE hands out if = it does run a proxy.

If the CPE is announcing a no= n-stable DNS server IP (i.e. one formed from the address space PD'd to = it and assuming that prefix can change in future) it will want to be able t= o deprecate that nameserver and replace it with a new one.=C2=A0 Only one o= f these two protocols supports doing this nicely.
--001a1148b4ae843d9f05520eac30-- --001a1148b4ae89e1b005520eace3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgALDmKpFsIzRLFdUGer3g2reSKBTTfjKO +9P4ONfb4XowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjE2 MDcyNDIxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAI/GQtLEkOj3kzFLNpXzwzLcUU8s9n4VhtRKsUM9DFEXilOT3AWa p8k8/6gq0Z/jwKN28V1vAERLTr/dQR25+hfp3AG1xpZI7eMAWc+VYknBhzS03IrHzWdpS/bZK2H8 jV22E5qfmNpqou61Kw/q1akK4LyF3hymPZ/IyWxHEMt+rKqsZSXndyRNrIpA5q63o649yDvUaFu0 Gf02JOn3hpz+02hqvcF9WWJ97T222a55nMTLY3pTso7KEHx38j0W9GsIOgqXl6/YORdmS56D7GKD QkdTKROCacndZi1tBLMdy3jiDhywHVrPuLjcdgvYzyENpnizmvGpLVIF1cf6fZE= --001a1148b4ae89e1b005520eace3-- From nobody Fri Jun 16 01:54:40 2017 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 E188913170D for ; Fri, 16 Jun 2017 01:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6klNqxwQfwyj for ; Fri, 16 Jun 2017 01:54:38 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D251C13170A for ; Fri, 16 Jun 2017 01:54:37 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4C37BC01A6; Fri, 16 Jun 2017 10:54:36 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.53]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 1DB2E20068; Fri, 16 Jun 2017 10:54:36 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM61.corporate.adroot.infra.ftgroup ([fe80::89e:f34e:3a8e:4519%21]) with mapi id 14.03.0339.000; Fri, 16 Jun 2017 10:54:35 +0200 From: To: "STARK, BARBARA H" , "v6ops@ietf.org" Thread-Topic: 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAmwJAw Date: Fri, 16 Jun 2017 08:54:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009FE320B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:54:40 -0000 Hi Barbara,=20 I would agree with your comment if the requirement was a MUST, but given th= is is a SHOULD + the behavior is widely deployed + a provider may decide to= provision DNS servers with IPv6 addresses only while internal requests may= be placed over IPv4 (think about DS-Lite, MAP & Co), I do support the curr= ent wording in the draft.=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA= H > Envoy=E9=A0: jeudi 15 juin 2017 16:33 > =C0=A0: v6ops@ietf.org > Objet=A0: [v6ops] 7084-bis DNS proxy requirement >=20 > I don't think this is the right recommendation: > L-12: The IPv6-only CE router SHOULD implement a DNS proxy as > described in [RFC5625]. >=20 > There are many CE routers that pass to LAN devices the address of WAN- > based DNS servers (of ISP or Google, etc.) and do not implement a DNS > server as a forwarding proxy. This "SHOULD" requirement in the context of > a CE Router that does not implement a forwarding proxy is meaningless, an= d > not implementing a forwarding proxy is very valid and does not need to be > discouraged. On the other hand, if a forwarding proxy is implemented, > doing so according to RFC 5625 needs to be required. Forwarding proxies > that aren't compliant with RFC 5625 have no business being deployed to > mass market consumers. >=20 > Note that BBF TR-124 has a requirement for RFC 5625 worded as: > "If the RG's DNS server is implemented as a forwarding proxy, it MUST be > done according to the recommendations in RFC 5625." >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 16 05:52:09 2017 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 4EB6E129BCE for ; Fri, 16 Jun 2017 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 XWaVEErvxojb for ; Fri, 16 Jun 2017 05:52:07 -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 E68C4129BA0 for ; Fri, 16 Jun 2017 05:52:06 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5GCjamd013416; Fri, 16 Jun 2017 08:52:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2b4dwcmt16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 08:52:06 -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 v5GCq4jk030730; Fri, 16 Jun 2017 08:52:05 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5GCpwiD030602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Jun 2017 08:51:59 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 16 Jun 2017 12:51:50 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0319.002; Fri, 16 Jun 2017 08:51:50 -0400 From: "STARK, BARBARA H" To: "mohamed.boucadair@orange.com" , "v6ops@ietf.org" Thread-Topic: 7084-bis DNS proxy requirement Thread-Index: AdLl4jQVm5zWmKFERnemh1syE/YSkAAmwJAwAAdbaJA= Date: Fri, 16 Jun 2017 12:51:50 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB98791@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009FE320B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009FE320B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.200.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_07:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160210 Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:52:08 -0000 > I would agree with your comment if the requirement was a MUST, but given > this is a SHOULD + the behavior is widely deployed + a provider may decid= e > to provision DNS servers with IPv6 addresses only while internal requests > may be placed over IPv4 (think about DS-Lite, MAP & Co), I do support the > current wording in the draft. The use case you describe is not necessary to support basic IPv6 connectivi= ty, and does not provide a significantly better user experience in the cont= ext of IPv6 connectivity. Many IPv6-capable CE Routers are deployed and wor= king very well today without this.=20 Requirements in RFC 7084 should be restricted to those that are absolutely = necessary (MUST) or very highly desirable because they will provide a signi= ficantly better user experience (SHOULD) in the context of IPv6 connectivit= y. There are many widely deployed not-necessary-for-IPv6 features in CE router= s that RFC 7084 is properly silent on. Barbara From nobody Fri Jun 16 10:53:17 2017 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 F344D129B48 for ; Fri, 16 Jun 2017 10:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 unkNkCx4bi9h for ; Fri, 16 Jun 2017 10:53:14 -0700 (PDT) Received: from accordion.employees.org (cowbell.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 E89DC129B39 for ; Fri, 16 Jun 2017 10:53:13 -0700 (PDT) Received: from h.hanazo.no (77.16.70.76.tmi.telenormobil.no [77.16.70.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 85CBC2D4FD1; Fri, 16 Jun 2017 17:53:10 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 11FCED475BBC; Fri, 16 Jun 2017 08:34:41 +0200 (CEST) From: otroan@employees.org Message-Id: <6E1501F8-7399-4095-99CA-811B222B9D87@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DD68E61D-B899-4DD5-85CC-88EA5D6057AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 16 Jun 2017 08:34:40 +0200 In-Reply-To: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> Cc: IPv6 Operations To: Fred Baker References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 17:53:16 -0000 --Apple-Mail=_DD68E61D-B899-4DD5-85CC-88EA5D6057AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > We have several new drafts that the chairs would like working group = discussion on, if only to gauge interest. Jen sent a note regarding hers = a moment ago. Jordi has, following feedback, divided 70844bis, and we = are looking for commentary on each. >=20 > 2017-06-14 draft-linkova-v6ops-conditional-ras > 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition > 2017-06-11 draft-palet-v6ops-rfc7084-bis2 > 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis > "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition > "Transition Requirements for IPv6 Customer Edge Routers", Jordi = Palet, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 > "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi = Palet, > 2017-06-11 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp > "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi = Palet, > 2017-06-11 I would prefer to see two IPv6 CE documents. One updated 7084 with HNCP requirements and the transition mechanisms = taken out. One only for the transition mechanisms. Although that might have some = overlap with draft-ietf-softwire-unified-cpe The first is closest to Jordi's rfc7084-bis4-hncp (although there are = not HNCP requirements there yet). The second rfc7084-bis-transition. Although I have issues with the = approach of recommending all options and not making a choice. When the = IETF leaves it to the market to decide, because it cannot reach = consensus, then we should consider that, given this is the closest thing = we have to a "recommendations to the market" style document. I also have issues with the author of these documents replacing the = original author set with himself in the documents. Cheers, Ole --Apple-Mail=_DD68E61D-B899-4DD5-85CC-88EA5D6057AE 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZQ3wAAAoJEL7aWKiYQt92Iz4P/R8fqv0hat4y8hO/4bponRXu RuW63EErWGUNbGmPFJVh2ZXYjXhAecgtL/0NBaGOFNjFzQLJEg/8jRcUIZypvZeY 00yem20x43b0lkUIoq0zBxgy1yOZr2i34HJSkKjjJoubAz0d5IIpuMo2HcQRT/yh 4Eh7fcYgesz3izY88e8ZTJy1gKi4+9W01ZbyHTJMprvrr9MW+tB+LzL3pvEDaxXB YKOlm2PcJ7UEZO2kGdQI6uw2Mo3gBcAfjQ221mPsW0PEcWxSetx2HZXdZBGSDVi9 h2JigcvXl+6Ve9JX3tlKLWcgNb8LALjclAdO0gWdWPQFgBl/3+2Kx/DJra7cdrzh aKuHhseLp2iewykj1mdtYIIAkYXSqCGhV7ObWcD9JEHRebU1LJ9G/mveO/OOF1iY C1FUg/OJ0r194Zf7IW+YYV507RJh1eIjut0RYuqCvkuMhwtg78K8A0GxYXBreDBS O9EsH5IGNSOBT4oBb31aox40SEFgfITRgpPueIAn4t3exHF0+rSU653xkR7d5M/k o2VYB7lCd+h3LfNr0p5JjEXAnI5semXHp4+lfResPujsIbByujZ/lmzOFz7+Wiu3 Uvyo7kjc0AWxMo5NbrgdJXqH4pKzvkevaWOVkUzxxdJO6cKYPLpeU95iidzr0syI m2ZqGuNcsK7ezTCk3Pap =i/c9 -----END PGP SIGNATURE----- --Apple-Mail=_DD68E61D-B899-4DD5-85CC-88EA5D6057AE-- From nobody Fri Jun 16 11:05:45 2017 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 9F22E1294CC for ; Fri, 16 Jun 2017 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLtCysWAngNX for ; Fri, 16 Jun 2017 11:05:41 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27301273B1 for ; Fri, 16 Jun 2017 11:05:41 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u62so4203300pgb.3 for ; Fri, 16 Jun 2017 11:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=YinmYVtzTP/7PpfXamFdW6XKao+EzLrJHTU0jY6eWfI=; b=judzYtPlRh5wfQRchEWqmCuoEtG/7xgtTdKTJ9YCuNvt3yb1lXdUFImVpe3mxQNqrO mc4y5+L1W8gprQ8EVACJ9BhRO2e8sPVoHlJ6+tBAZO4vSoRaiaif0NrcRRBoiE2GUqM0 7/5QzuhvSRWSOuh8Xy406sA92WKJA0ny3k8QOCBREJwYHlxuIFI5G9TtCHqKQTno8nf1 MMNXQgjOpd/rBqNgoFjm4IVZDjYKzTT7Y/u+eD3Cm8BAWEmns4DPt9DTa/f/VXr7B/b9 uXYxXAecl1pUVeIIMew2QKb+D7BMaPWZoIv9hAFUsJX5p267+UxbLLKHnURcvflx8L/m blKQ== 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=YinmYVtzTP/7PpfXamFdW6XKao+EzLrJHTU0jY6eWfI=; b=Fv2KJWpDT3j4mfMyPtM13vukqicuWU7UriDZKlEqM97pYfZ4ewPF2UEBsBlLjXELON zWsiNnbjJ4pDAue/tTWYL5QRtmk+CZ5LnGP1vECG2WAwtVxQB0J4/808YhxSg/HiJGWw jNlk+GL157uRJR6iYTgOQ0chZ3RDMPOJMoEIKY8bRr4WLjtDM+g6YpOIGoFOIPGehw9P f5Eq1s1IKRTXCZTxGzjTwVwZ83Wv+a8mLYzWpYg2sNc7evthyQQY7xvXUI5xFyKKBOoF aKgIQf1OaYDwUciOEmVrESeX/+zLdKFmqmL4B6uyYglfZhtmdxVGC40ITc9g4oiLIemA z5+g== X-Gm-Message-State: AKS2vOxlQqFWw543Zy5hYSSH1frGsOGUltY5agTvVqQQaK4RBsxDX04t 0nqTQit0gSDentgOD3cXWA== X-Received: by 10.84.196.129 with SMTP id l1mr14426226pld.109.1497636340984; Fri, 16 Jun 2017 11:05:40 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:184a:a806:b8e3:2783? ([2620:0:10e7:10:184a:a806:b8e3:2783]) by smtp.gmail.com with ESMTPSA id j62sm5371358pgd.20.2017.06.16.11.05.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 11:05:40 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_EEBEAA2A-DB7F-4655-A302-84E99F24C34E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 16 Jun 2017 11:05:39 -0700 References: <2D09D61DDFA73D4C884805CC7865E6114DB91B3A@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009FE320B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB98791@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "v6ops@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB98791@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-Id: <44E9F42C-38E4-425F-B2B1-3AFEC9C8E253@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 7084-bis DNS proxy requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 18:05:44 -0000 --Apple-Mail=_EEBEAA2A-DB7F-4655-A302-84E99F24C34E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 16, 2017, at 05:51, STARK, BARBARA H wrote: >=20 > The use case you describe is not necessary to support basic IPv6 = connectivity, and does not provide a significantly better user = experience in the context of IPv6 connectivity. Providing hosts on home LANs with a) native IPv6 connectivity using = provider delegated address space, which is subject to change without = prior approval by the subscriber, and b) automatic configuration of DNS = server IPv6 addresses, can be done with a decent user experience using = RDNSS, but not for hosts that only implement DHCPv6, which last we = checked is a significant fraction of the installed base under support. = For them, using a DNS proxy absolutely provides a better user = experience, although I do recognize the desire to downplay the = significance of the improvement. I suppose it=E2=80=99s not actually important to expand the requirements = of what constitutes =E2=80=9Cbasic IPv6 connectivity=E2=80=9D to include = a decent user experience when providers change delegated prefixes. After = all, in many contexts, a decent user experience is a luxury class of = service sold at premium prices. Maybe it would make a lot of sense to = write two RFCs: one for the CE routers sold to the peasants, and another = for the CE routers sold to people whose user experiences are = significant. --james woodyatt > --Apple-Mail=_EEBEAA2A-DB7F-4655-A302-84E99F24C34E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jun 16, 2017, at 05:51, STARK, BARBARA H <bs7652@att.com> = wrote:

The use case you = describe is not necessary to support basic IPv6 connectivity, and does = not provide a significantly better user experience in the context of = IPv6 connectivity.

Providing hosts on home LANs with a) = native IPv6 connectivity using provider delegated address space, which = is subject to change without prior approval by the subscriber, and b) = automatic configuration of DNS server IPv6 addresses, can be done with a = decent user experience using RDNSS, but not for hosts that only = implement DHCPv6, which last we checked is a significant fraction of the = installed base under support. For them, using a DNS proxy absolutely = provides a better user experience, although I do recognize the desire to = downplay the significance of the improvement.

I suppose it=E2=80=99s not actually = important to expand the requirements of what constitutes =E2=80=9Cbasic = IPv6 connectivity=E2=80=9D to include a decent user experience when = providers change delegated prefixes. After all, in many contexts, a = decent user experience is a luxury class of service sold at premium = prices. Maybe it would make a lot of sense to write two RFCs: one for = the CE routers sold to the peasants, and another for the CE routers sold = to people whose user experiences are significant.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_EEBEAA2A-DB7F-4655-A302-84E99F24C34E-- From nobody Fri Jun 16 11:07:33 2017 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 EB195127137 for ; Fri, 16 Jun 2017 11:07: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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erUmN9ys7e9D for ; Fri, 16 Jun 2017 11:07:25 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19031129B73 for ; Fri, 16 Jun 2017 11:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497636442; x=1498241242; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=pkkPV5ZrxHqegtLHU85Xb8+SA agmpBtmlIm908UGYHk=; b=scRZddOh6Y9yOE+NPPjRU9LZEWoNngWCuBTTkeFee 3V1J7rnXFhP6smOjHql3Ai+auxkSbVRWFw0dwAjLxb1LMgSYNb0xQayz4TsGPkdF lwsr7yykDQsAzjBTypqyWmNMu7f3XxsEGHpwf8TpJWgKsT0xudyomqYZJGgiM+DK LY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=k75L6uCoP7a3W4bVh/kVhn+9jXp9H1WxTCQ6hk7MmTU/8JKbF6MC/YNaG6ZU zaeMSzCu0udyIaK1SHbEdH9lwkQgsF67K+MkoPEnW0KGfJHSLK4HElPa3 HUvBarg/690DZlN9wBAQkL31HeyCNUAbIL/E2Ivvklphw5V74y5+fE=; X-MDAV-Processed: mail.consulintel.es, Fri, 16 Jun 2017 20:07:22 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 16 Jun 2017 20:07:21 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452388.msg for ; Fri, 16 Jun 2017 20:07:20 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170616:md50005452388::JgETmo9IKagoY/Me:00002gKy X-Return-Path: prvs=1340bc8c94=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Fri, 16 Jun 2017 20:07:15 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] New drafts References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> <6E1501F8-7399-4095-99CA-811B222B9D87@employees.org> In-Reply-To: <6E1501F8-7399-4095-99CA-811B222B9D87@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 18:07:30 -0000 Hi Ole, Let me explain how this started. Long time ago, I asked in the list to the authors to work on this. As I got= no answer, I asked the authors writing them to the emails in the RFC copie= d the chairs and ADs. I asked them several times, even during the Seoul meeting I asked to meet t= here. I never got an answer. I never understood that attitude, I think is r= eally impolite. I always answer my emails =E2=80=A6 and even more if those = are questions related to the IETF work. So, I asked the chairs about how to proceed, they suggested me to ask the R= FC editor for the XML file and take over that work. I=E2=80=99ve never been= in that situation, but I checked similar situations and saw that the autho= rs get replaced and there is some text recognizing them. In fact, this is the same situation in between you as co-author of RFC6204 = and RFC7084, right? I guess it is related to the need to avoid the need for each =E2=80=9Colder= =E2=80=9D author to ack when a new version is uploaded, right? I=E2=80=99m not feeling there is anything wrong, so if I=E2=80=99m wrong, p= lease explain it, and fine to change whatever is needed, as usual. I guess you=E2=80=99re referring anyway to the authors of the actual =E2=80= =93bis which is a WG item or even those that I have submitted last week rem= oving the transition stuff, because if you look at the content of the one f= or the transition it is probably over 90% new, right? If you have any suggestions about the HNCP part, or how to approach the tra= nsition, please let us know. For the transition, I suggested moving to MUST= at least for some of them when I started this work, but the list didn=E2= =80=99t liked that idea. I also think if we do that, we should also have al= most everything as MUST in the 7084-bis (w/o the transition). Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: viernes, 16 de junio de 2017, 8:34 Para: Fred Baker CC: IPv6 Operations Asunto: Re: [v6ops] New drafts > We have several new drafts that the chairs would like working group d= iscussion on, if only to gauge interest. Jen sent a note regarding hers a m= oment ago. Jordi has, following feedback, divided 70844bis, and we are look= ing for commentary on each. >=20 > 2017-06-14 draft-linkova-v6ops-conditional-ras > 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition > 2017-06-11 draft-palet-v6ops-rfc7084-bis2 > 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis > "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition > "Transition Requirements for IPv6 Customer Edge Routers", Jordi Pale= t, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 > "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi Pa= let, > 2017-06-11 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp > "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi= Palet, > 2017-06-11 =20 I would prefer to see two IPv6 CE documents. One updated 7084 with HNCP requirements and the transition mechanisms t= aken out. One only for the transition mechanisms. Although that might have some o= verlap with draft-ietf-softwire-unified-cpe =20 The first is closest to Jordi's rfc7084-bis4-hncp (although there are n= ot HNCP requirements there yet). The second rfc7084-bis-transition. Although I have issues with the appr= oach of recommending all options and not making a choice. When the IETF lea= ves it to the market to decide, because it cannot reach consensus, then we = should consider that, given this is the closest thing we have to a "recomme= ndations to the market" style document. =20 I also have issues with the author of these documents replacing the ori= ginal author set with himself in the documents. =20 Cheers, Ole _______________________________________________ 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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sat Jun 17 01:49:43 2017 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 504F8126CD6 for ; Sat, 17 Jun 2017 01:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wux84muqePZC for ; Sat, 17 Jun 2017 01:49:39 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CD7127599 for ; Sat, 17 Jun 2017 01:49:38 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id y25so9420922wrd.2 for ; Sat, 17 Jun 2017 01:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Faji0EoS9hfO74LwjSX58o0+5xGyTHQStdfDAFimy9Q=; b=EX5rOfv6wM0/I65ntFM5eJU0nsUR+e9sVma3tOEYlrGsQYzfHV5yqAK86di3dQsEDW G/2dftTRglcWgEm0HHdzV9aIjDkSY27BuHTZqKC/rH9jmFGjUVED7na6ey3MuNBDykzV m381+m96R3Laqro8MFceolBHcdM2cSl5spHGuTWH+jYQWmNfJm1OjBSFU/kj7bSKhx8b 27vn3AGx0p8t9vtC0gjWxNRh/A3tEZP2FgFmt+1bC75xjibv7baIWHYaEqORr/keZSNo cEF0byBsQyqM9ljBzJe2V4otqWwZqSOsc55Ype0n6ZBjzikrfERTDDTB4Rf1NREnFOtS hgkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Faji0EoS9hfO74LwjSX58o0+5xGyTHQStdfDAFimy9Q=; b=qJVndytIxcFGVaX2GIJOXOr1sMoDAIT7nOa+hF9sv9DnRR9gVF3YvAIglZKHuRISdo X5iV+9QE+EOKrlqNqjm/4qQXqUY4PZAs79z2QM9kfndoWBxHAgNHEa79EBS/Pu+O3Uq8 mJ/3pB50o7d1J3q+3FbJIbWpDaDSF8rfHyfXBjwkVwpfFD4F850ODW+cQe2Bu67L4XzH SDsdX5MXR5EVrTmfR3OfuOUud5v56HK66Kjrbxs/gcWa/1pUKKTUAJ+kvUuxy7U1RrVc gepWB95H/2lb0WtWAq5B/kTD0VZSV27XKHFuBdtYHu1mn7JcBvWgorIJkYgzSGbeKu/3 IN7w== X-Gm-Message-State: AKS2vOwYxD5UHfNfQqLaGW7Bz34waC7tWbT5yejsuNnYAlZlN2p5A1kV Ql1BZ50I6xV6zV+VCDWacu4To5rrxpqI X-Received: by 10.223.176.133 with SMTP id i5mr10069316wra.53.1497689377180; Sat, 17 Jun 2017 01:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.168.132 with HTTP; Sat, 17 Jun 2017 01:49:36 -0700 (PDT) X-Originating-IP: [197.250.228.40] Received: by 10.28.168.132 with HTTP; Sat, 17 Jun 2017 01:49:36 -0700 (PDT) In-Reply-To: References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> From: Noah Date: Sat, 17 Jun 2017 11:49:36 +0300 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a1141ae604fa01e055223fbf1" Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 08:49:41 -0000 --001a1141ae604fa01e055223fbf1 Content-Type: text/plain; charset="UTF-8" Hi Fred Thank you for sharing this drafts. Do we also have similar ones for end user devices ref: 1.Android with updates Linux Kernel 2.MacOS/Windows Noah On 15 Jun 2017 5:07 p.m., "Fred Baker" wrote: We have several new drafts that the chairs would like working group discussion on, if only to gauge interest. Jen sent a note regarding hers a moment ago. Jordi has, following feedback, divided 70844bis, and we are looking for commentary on each. 2017-06-14 draft-linkova-v6ops-conditional-ras 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, 2017-06-12 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition "Transition Requirements for IPv6 Customer Edge Routers", Jordi Palet, 2017-06-12 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi Palet, 2017-06-11 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi Palet, 2017-06-11 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --001a1141ae604fa01e055223fbf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fred

Than= k you for sharing this drafts.

Do we also have similar ones for end user devices ref:=C2=A0

1.Android with updates Linux Ke= rnel=C2=A0
2.MacOS/Windows=C2=A0

Noah
=
On 15 Jun 2017 5:07 p.m., "Fred Baker&q= uot; <fredbaker.ietf@gmail.c= om> wrote:
We have = several new drafts that the chairs would like working group discussion on, = if only to gauge interest. Jen sent a note regarding hers a moment ago. Jor= di has, following feedback, divided 70844bis, and we are looking for commen= tary on each.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-14=C2=A0 =C2=A0 =C2=A0 draft-linkova-v6= ops-conditional-ras
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-12=C2=A0 =C2=A0 =C2=A0 draft-palet-v6op= s-rfc7084-bis-transition
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-11=C2=A0 =C2=A0 =C2=A0 draft-palet-v6op= s-rfc7084-bis2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-11=C2=A0 =C2=A0 =C2=A0 draft-palet-v6op= s-rfc7084-bis4-hncp

https://tools.ietf.org/html/draft-ietf-= v6ops-rfc7084-bis
=C2=A0 "Basic Requirements for IPv6 Customer Edge Routers", Jordi= Palet,
=C2=A0 2017-06-12

https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition
=C2=A0 "Transition Requirements for IPv6 Customer Edge Routers", = Jordi Palet,
=C2=A0 2017-06-12

https://tools.ietf.org/html/draft-pa= let-v6ops-rfc7084-bis2
=C2=A0 "Minimum Requirements for IPv6-only Customer Edge Routers"= , Jordi Palet,
=C2=A0 2017-06-11

https://tools.ietf.org/html/draf= t-palet-v6ops-rfc7084-bis4-hncp
=C2=A0 "Basic Requirements for IPv6 Customer Edge Routers with HNCP&qu= ot;, Jordi Palet,
=C2=A0 2017-06-11

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

--001a1141ae604fa01e055223fbf1-- From nobody Sat Jun 17 02:12:39 2017 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 3CEDC12702E for ; Sat, 17 Jun 2017 02:12:38 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAL6hFLC8eLf for ; Sat, 17 Jun 2017 02:12:36 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB899126CB6 for ; Sat, 17 Jun 2017 02:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497690753; x=1498295553; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=KnX5MpuonHx2ZW6LZTP2E8AwM VCdf83d4FFkG0ugdEU=; b=nQs4k2ZPYPspweFlu668YfaTYaHDoDKMiUzQL6MWg LOre/mYW0ryBOGqhStU5Z/8v3yR+azl5kBMhRYvPq+1d4fxU3l1+FxN0VA2vknNz 5UvsyLM3qxuNR0NMRwtBjQ+2SLHaoDf4uQALNuuftgGlM5Vlu02D5yIRuP31I+Ki gA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lnjxSCj+yPXUsKik/gt9a04MiXUjV+PBmMl+l2C/Hz2Ns5JZP/am5tlw8a3P aCvuUmCLTn6sVM5xLaRYZM/NlkroXXM7CqzhuepG18xOVORkVUSgqjJwD V07s7PotEa5tzVoMwolrfIl0Ra/5RyUumU6hQCVB88gFcO8zNYeXrI=; X-MDAV-Processed: mail.consulintel.es, Sat, 17 Jun 2017 11:12:33 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 17 Jun 2017 11:12:32 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452652.msg for ; Sat, 17 Jun 2017 11:12:31 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170617:md50005452652::rY+TK/iWamKqmz+C:00006WkB X-Return-Path: prvs=1341fa1d60=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sat, 17 Jun 2017 11:12:26 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] New drafts References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 09:12:38 -0000 Hi Noah, There is a document for that of course, but it belongs to another WG: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Noah Responder a: Fecha: s=C3=A1bado, 17 de junio de 2017, 10:49 Para: Fred Baker CC: IPv6 Operations Asunto: Re: [v6ops] New drafts Hi Fred Thank you for sharing this drafts. =20 Do we also have similar ones for end user devices ref:=20 =20 1.Android with updates Linux Kernel=20 2.MacOS/Windows=20 =20 Noah =20 =20 On 15 Jun 2017 5:07 p.m., "Fred Baker" wrote= : =20 We have several new drafts that the chairs would like working group dis= cussion on, if only to gauge interest. Jen sent a note regarding hers a mom= ent ago. Jordi has, following feedback, divided 70844bis, and we are lookin= g for commentary on each. =20 2017-06-14 draft-linkova-v6ops-conditional-ras 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp =20 https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, 2017-06-12 =20 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition "Transition Requirements for IPv6 Customer Edge Routers", Jordi Palet= , 2017-06-12 =20 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi Pal= et, 2017-06-11 =20 https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi = Palet, 2017-06-11 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sat Jun 17 13:25:10 2017 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 92216129BC5 for ; Sat, 17 Jun 2017 13:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vVG8l1y6ABl0 for ; Sat, 17 Jun 2017 13:25:07 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D77126CE8 for ; Sat, 17 Jun 2017 13:25:07 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k145so38704537oih.3 for ; Sat, 17 Jun 2017 13:25:07 -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=OxTt2SS9B9+jAYXEjJoK5aSs/yzH0V4MlK0ygd5WNkc=; b=FB6T1KuiVd5lwJBXm4kAWFpe8ozLhDWebNhwO1zqPvh1MuTGgtWPqOAdQGuHaOAJOc H50K7KOZmZQ9Gdy1ucwvQ/n57cYTf3rwht3pP6f3FiB6FFiG+SY0WixsBIn4TIBV037d YjMJyHkC+85n/ykiecjhf6MGXNOHF8aHOSupwooF20uQBGyaH+mIHWYQu0bLD6QOZ+UD MkZQL3DrvpQIySEXhFyFc75oL642yuiIQdLe+7bHDuoYRSKORFu+NW2YEENZgxnDheXq G765HbfHH+gP4+wfjLx1DbFQ7RbBhpS+D10uASf/ENXediI1GzqxezIqpyP/Dfb6VvTa /ezA== 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=OxTt2SS9B9+jAYXEjJoK5aSs/yzH0V4MlK0ygd5WNkc=; b=qjJLPH8MdZH64IKLbbiEpMD4f4lISGHJDHitiGJ+Kn9N853c0csKRK+Qi5dWbvurDi Ft+p8TqOd6w6kSUwH+6aauRP1jBF8Wbf1WP9kp9mIoR5mTrAjhWVPqo0rAzVR3pv/4Ao /8UGZizYijgAH8i/lnIZVabtvBjBjBsVOaah1dLbuqAhO3gIIJWL710YfWe+x5N1cvAu SXi3znwv5WzsUaoYbkTmndv+Movnf7fXEEIKqjy4gfPW376q3GhBQBemMHdXVNWh4Dna 7ZofQ2Crcq+DvRME4gUHaZyeEdY1TZ5lY2WVeLBpioGAn6Mp+d2N1KeKKcNRjGbtlUe2 IiPA== X-Gm-Message-State: AKS2vOzieqOL5mLwLNVS5vjdgg/2e7W+658Y8zZoiRF/Oj439MFEDwLY 2tm52K6/M+wJ+97/jxY= X-Received: by 10.202.208.22 with SMTP id h22mr18585oig.80.1497731106579; Sat, 17 Jun 2017 13:25:06 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::16e5? ([2600:8802:5600:1e::16e5]) by smtp.gmail.com with ESMTPSA id s88sm3203575ota.56.2017.06.17.13.25.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jun 2017 13:25:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Sat, 17 Jun 2017 13:25:03 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <8AACE37B-E760-47D2-B17F-A09AAADF8A9A@gmail.com> References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> To: Noah X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 20:25:10 -0000 > On Jun 17, 2017, at 1:49 AM, Noah wrote: >=20 > Hi Fred >=20 > Thank you for sharing this drafts. >=20 > Do we also have similar ones for end user devices ref:=20 >=20 > 1.Android with updates Linux Kernel=20 > 2.MacOS/Windows=20 >=20 > Noah I'm not sure I understand your question.=20 As Jordi points out, there is an update to IPv6 Node Requirements in = 6man. This document is an important part of the basis for the IPv6 Ready = Logo program, the US Government "Planning Guide/Roadmap Toward IPv6 = Adoption", and RIPE 554. It is not specific to any given platform; it = is intended to describe all platforms. If you're looking for something = specific to Android, Linux, MacOS, Windows, or anything else (such as = perhaps iOS or IoT MCU RTOS's), no, we don't have product-specific = documents, and they are not part of our charter. Does that address what you're looking for, or are you looking for = something else? > On 15 Jun 2017 5:07 p.m., "Fred Baker" = wrote: > We have several new drafts that the chairs would like working group = discussion on, if only to gauge interest. Jen sent a note regarding hers = a moment ago. Jordi has, following feedback, divided 70844bis, and we = are looking for commentary on each. >=20 > 2017-06-14 draft-linkova-v6ops-conditional-ras > 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition > 2017-06-11 draft-palet-v6ops-rfc7084-bis2 > 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis > "Basic Requirements for IPv6 Customer Edge Routers", Jordi Palet, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-transition > "Transition Requirements for IPv6 Customer Edge Routers", Jordi = Palet, > 2017-06-12 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2 > "Minimum Requirements for IPv6-only Customer Edge Routers", Jordi = Palet, > 2017-06-11 >=20 > https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp > "Basic Requirements for IPv6 Customer Edge Routers with HNCP", Jordi = Palet, > 2017-06-11 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sat Jun 17 13:28:46 2017 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 0B2C5129BC5 for ; Sat, 17 Jun 2017 13:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hx_xTM_YGx9U for ; Sat, 17 Jun 2017 13:28:43 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BF9126CE8 for ; Sat, 17 Jun 2017 13:28:43 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id b6so38728644oia.1 for ; Sat, 17 Jun 2017 13:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:reply-to:mime-version:subject :message-id:date:to; bh=a3Ezs1hHxS8pdGUelDxPWHKHcZ8quE/1Fr3PqHRvZFI=; b=vGps+eODbJYkl3i7RT7IGDpNiPacg6hoYi2mrNUoHrFwZFmruFOnA6SBx5wbTdOCh3 LpwJt4imVO64HCuwJfjQO4HKDli3TI9yqqe0anYf540Dd5/llIxNthe3UV2DxaRgbfzp 6DgnAXmv+ZME6LLFeIh8/DUOnaChVpHnCy/EsPaVNwtTaI/IyQ5XaHsLMpTyt1sMWGdA 98Gu5RcDb7m2BK3FzZQBqn4npXKsowv5QqnR7Dlnomi4mvFXjaIh3E8klUBGcgk7drrJ FAScQdNB9Y2b/zNaHQu6YZhOnTXUrBQfS68wvdY0eRYbdDx+SPgGC7Ht9zr+eLm/MXPe UDvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:reply-to :mime-version:subject:message-id:date:to; bh=a3Ezs1hHxS8pdGUelDxPWHKHcZ8quE/1Fr3PqHRvZFI=; b=V4Ofchf7IMhTKq57rE8b1GT/6IQQrfj1QAK5+n9VS1BbOs9zHgCYNbD4YWlpYRH+I6 68MhK0IT8UqgMrGY4fDURwGZtcvrKKxZvS7EYMmmADOVXCUBS0/7yBMnC/nsjwq+KsyB 6S9G2FcwZOAOFQVpjG4rjbCtd4mO+czsFl/BilZa5Q1dh5wN5claJdokKWkSHCyNSkJs AQ4VsMS6V9tpMCKJAXU7U6W2kSDtIZ+ZXQY7fgleIPGeVLUXbWFFwZGgAW8aA3w3kXou wix17Y2d9gYzJR0X7QMcPKrYAMxRT7R8CO8t9dbsYehee9nGyZUakBkldYqWRj6JxPNI 1x4Q== X-Gm-Message-State: AKS2vOxsPsyZIEXx96D2mrPAGpLYi38Nlku4PZnjoxY3gRoaMLJdDeG5 2u+72IjVBg32guMtGM4= X-Received: by 10.202.191.69 with SMTP id p66mr3543230oif.38.1497731322399; Sat, 17 Jun 2017 13:28:42 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::16e5? ([2600:8802:5600:1e::16e5]) by smtp.gmail.com with ESMTPSA id d27sm3277584ote.41.2017.06.17.13.28.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jun 2017 13:28:41 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: V6ops Chairs Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 17 Jun 2017 13:28:40 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] IETF 99 Meetings and agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 20:28:45 -0000 A preliminary IETF agenda has been posted at = https://datatracker.ietf.org/meeting/99/agenda.html. We are scheduled = Tuesday morning and Thursday afternoon. Any heartburn, please let us = know now, as the final agenda is to be posted Friday 23 June. I have also posted a preliminary working group agenda as well, at = https://datatracker.ietf.org/meeting/99/agenda/v6ops/. We have some = remaining time (about an hour), and are considering a fourth invited = talk and several recently-posted drafts: 2017-06-14 draft-linkova-v6ops-conditional-ras 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp Additional new drafts could arrive anytime between now and July 3, and = the chairs solicit comments on the above documents, with a view to = gauging working group interest.= From nobody Sat Jun 17 14:21:14 2017 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 4522D129C1C for ; Sat, 17 Jun 2017 14:21:14 -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 ONnLh_gljtWC for ; Sat, 17 Jun 2017 14:21:12 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4626D129C1A for ; Sat, 17 Jun 2017 14:21:12 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id y47so26556280oty.0 for ; Sat, 17 Jun 2017 14:21:12 -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=kR6cmrm6Y5eZM6NxtmkNest0wWCHdGyIjJDbi6uj80g=; b=uAJbFO9yfI071DCGXvTFmyVx4A/YarEGLWXZ1E2RDKUw9XKtJO6rT1gOcxuZf39Aan QASzDbCammsxXPoUbpjJf4QWUTzGYHPNj4Yk7C77Hk5lt9CUaOPAHrK+JpuqDpfU0DMX f+7kyjwPAqJ6260dW/coec37jdufDvSID0c4kT29dw1N/5P/E2e/hf9P26gXYy4fGmuc DjJitKeDeQqjQMX6IzdPDAvDVw09+zX10QkQwTyEvAys+1RrNv/Pbh8s+08oT1TggYUf Z1x0TPJt53uqfWglg9myvDohDlrtZD29HpUHax+lSyTU5EhsAJER7T6Zm4Rl1c3eZGXg Oilw== 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=kR6cmrm6Y5eZM6NxtmkNest0wWCHdGyIjJDbi6uj80g=; b=etJy/uvHRzmCG5eUWKX5hTQl5UyufvkTrTJl/+O30QQWpcVPMUqtdhajcIlsWfRU/n +XQT1aC1/KW/6VSAP505js+CYc/PKx9Oqtl29Kz+GBeopFRbqX2LYbWER8a7d3aN/ywb JRguCAYOxxqZhiUNSoCoZHwb2PnnzomGcOdbEkQzLJUBm62M8XVQJNfSBAkhbHl5+LXk x2GltB7jKi45N/n7IO5L37qUyxZxKGE+HFSRX1cpDAecbLkXltJA2cr2+AEIFQT6itC5 YJ0LXboBih9THp634/s0vZHABsbFZCkF9qBl3XpFmM84dzTBRz+Xk8ScMJelp5k9cPEo NM4w== X-Gm-Message-State: AKS2vOwOa58MVv7mxpLT1chpwr9Bi3OVTln58fOaepDKLPsGIdeEAYBU OpiAnehduNBXXcjxcMg= X-Received: by 10.157.11.115 with SMTP id p48mr140620otd.165.1497734471485; Sat, 17 Jun 2017 14:21:11 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::16e5? ([2600:8802:5600:1e::16e5]) by smtp.gmail.com with ESMTPSA id j62sm3306440otc.50.2017.06.17.14.21.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jun 2017 14:21:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> Date: Sat, 17 Jun 2017 14:21:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 21:21:14 -0000 In discussion with John Brzozowski, he expressed a concern that CPEs = don't come "out of the box preconfigured for IPv6" as they often do for = IPv4. I had a recent experience with a new router at my home that made = the point in my mind; IPv6 was an "advanced configuration", and the = difference between "auto-configure" and "auto-detect" was a little lost = on me.=20 So I have a question. Do we need to spell this out for CPE vendors? I = have spliced together a draft on the topic. I'd welcome comments that = might improve it, especially if I have something egregiously wrong. = Second, I'm curious whether the working group thinks we need this. Your thoughts? > On Jun 17, 2017, at 2:14 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. >=20 > Name: draft-baker-v6ops-cpe-autoconfigure > Revision: 00 > Title: Requirements for a Zero-Configuration IPv6 CPE > Document date: 2017-06-17 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-baker-v6ops-cpe-autoconfigure-0= 0.txt > Status: = https://datatracker.ietf.org/doc/draft-baker-v6ops-cpe-autoconfigure/ > Htmlized: = https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoconfigure-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-baker-v6ops-cpe-autoconfigure-= 00 >=20 >=20 > Abstract: > This note is a breif exploration of what is required for a CPE to be > auto-configurable from the perspective on an ISP or other upstream > network. It assumes that the CPE may also be IPv4-capable (probably > using NAPT), but that the requirements for that are well understood > and need no further specification. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Sat Jun 17 14:53:32 2017 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 8D724129C49 for ; Sat, 17 Jun 2017 14:53:30 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps3Jp_7XhlEu for ; Sat, 17 Jun 2017 14:53:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0968E129C32 for ; Sat, 17 Jun 2017 14:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497736406; x=1498341206; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=7MWm4GrhiEhFEIGgK34FlklnW zlYHqa6gTFCs+tkxrk=; b=sugHpIv85nQKQrub4N4VBxnCtZ+FsG4I09FYKvLHF gTfGINFiOoNwkGs9rLc4huWD1PzPFRGb5Ul+Tp4e7+Fwn1njsGagHsLYu9bzvOH3 theyvb/TAzx1hEzZ0CbafMW8Vn4Ko5jH25C32d+Mq23LCTmt6zJnSWpRUM6atHJd bY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=aj4X+fN/y/DHCvYnI9bSIw5hEAa85f2zbcHJaeT9cR9sF0YFoiKkEi1WKl3i cH4ycQOLKHtr1gRe2IsfbZ9D/iufbvAvXOLvMQNBcCHqgSqnYXGL1Ugo4 IB/P8wA6RXoLN2t5NKJqMFGRyJ7ysG1RHQXlYItgBbbUYsfABQ9mWY=; X-MDAV-Processed: mail.consulintel.es, Sat, 17 Jun 2017 23:53:26 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 17 Jun 2017 23:53:25 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452783.msg for ; Sat, 17 Jun 2017 23:53:25 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170617:md50005452783::Ibr22pGJ2LZC3XQU:00000I0y X-Return-Path: prvs=1341fa1d60=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sat, 17 Jun 2017 23:53:24 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 21:53:31 -0000 Hi Fred, I just read the document and I think is something needed. In fact, it should be one requirement to be a should or must in the RFC7084= -bis. Not sure if others agree and if there is some way to =E2=80=9Csync=E2= =80=9D a reference in the RFC7084-bis with an individual I-D (I got an inpu= t previously to remove that), until it becomes an RFC (if approved), or it = means =E2=80=9Cholding=E2=80=9D it =E2=80=A6 Of course, if there is no opposition in the WG, this may be approved and go= to the last call quicker than the RFC7084-bis, so not being an issue. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: s=C3=A1bado, 17 de junio de 2017, 23:21 Para: IPv6 Operations Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-auto= configure-00.txt In discussion with John Brzozowski, he expressed a concern that CPEs do= n't come "out of the box preconfigured for IPv6" as they often do for IPv4.= I had a recent experience with a new router at my home that made the point= in my mind; IPv6 was an "advanced configuration", and the difference betwe= en "auto-configure" and "auto-detect" was a little lost on me.=20 =20 So I have a question. Do we need to spell this out for CPE vendors? I h= ave spliced together a draft on the topic. I'd welcome comments that might = improve it, especially if I have something egregiously wrong. Second, I'm c= urious whether the working group thinks we need this. =20 Your thoughts? =20 =20 > On Jun 17, 2017, at 2:14 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. >=20 > Name: draft-baker-v6ops-cpe-autoconfigure > Revision: 00 > Title: Requirements for a Zero-Configuration IPv6 CPE > Document date: 2017-06-17 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-baker-v6op= s-cpe-autoconfigure-00.txt > Status: https://datatracker.ietf.org/doc/draft-baker-v6ops-cp= e-autoconfigure/ > Htmlized: https://tools.ietf.org/html/draft-baker-v6ops-cpe-aut= oconfigure-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-baker-v6o= ps-cpe-autoconfigure-00 >=20 >=20 > Abstract: > This note is a breif exploration of what is required for a CPE to b= e > auto-configurable from the perspective on an ISP or other upstream > network. It assumes that the CPE may also be IPv4-capable (probabl= y > using NAPT), but that the requirements for that are well understood > and need no further specification. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sat Jun 17 15:00:36 2017 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 CF652129C4B for ; Sat, 17 Jun 2017 15:00:33 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2x-lxey4Hkx for ; Sat, 17 Jun 2017 15:00:32 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9570912940F for ; Sat, 17 Jun 2017 15:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497736827; x=1498341627; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=F3qYj8c7niSmYLvkntZLGAbPg k08UsE9i4S5IWx6nxs=; b=IpVE/lzGc+pZtRIq85M5F5kpMlPxak/QIeUwUdyCx X5iTj/TqDZvCoOnSjtNa9XjvB8zoc0d42Q0e/CQGN4J8DkHged/T+30x+vMzgzgh 9J+IRqgtz3YVp11wH4bQxt+sDhAmtMVMpimVLGImEE1FhOnu80+azJKnV3c9/sFZ Is= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=pJ2ZpIckogAfWxY2lC55WXyaCN/C9LeWUA4qdn/qcpgoxkU9mUKxZXaRdCi+ kttaWKNMZI2n5U8I+k3ij8ilH1SGyAsMOF5NYH2oUS4HF6KWkuh7D8aCD IqlVPYhzNecGWMlEyl3j6iZAXAxhzKjTlAMbr4RnTn61k4ImQrMEe0=; X-MDAV-Processed: mail.consulintel.es, Sun, 18 Jun 2017 00:00:27 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 18 Jun 2017 00:00:26 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452785.msg for ; Sun, 18 Jun 2017 00:00:25 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170617:md50005452785::jYeeMVm8xUvOIL84:00002UnX X-Return-Path: prvs=1341fa1d60=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 18 Jun 2017 00:00:24 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <168D56C0-F9B6-4E1D-9ABB-7D5A088D35C2@consulintel.es> Thread-Topic: [v6ops] IETF 99 Meetings and agenda References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] IETF 99 Meetings and agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 22:00:34 -0000 Hi Fred, I believe it makes a lot of sense to have a single slot for all the differe= nt options of the RFC7084-bis related documents. I don=E2=80=99t think it m= eans a lot of extra time, may be 4-5 extra minutes for a couple of slides f= or each additional document explaining the differences from the actual WG i= tem one. Probably the key think here is to take a decision if we want it in= a single document vs split, and in case we choose split, what choice. I don=E2=80=99t know if you agree on that, but I think it can save some dis= cussion time if we can call for a poll in the list, for a week or so, which= will mean I=E2=80=99ve time to submit a new version of each document (or o= nly for the WG choice according to the poll results), before the cut-off. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: V6ops Chairs Fecha: s=C3=A1bado, 17 de junio de 2017, 22:28 Para: IPv6 Operations Asunto: [v6ops] IETF 99 Meetings and agenda A preliminary IETF agenda has been posted at https://datatracker.ietf.o= rg/meeting/99/agenda.html. We are scheduled Tuesday morning and Thursday af= ternoon. Any heartburn, please let us know now, as the final agenda is to b= e posted Friday 23 June. =20 I have also posted a preliminary working group agenda as well, at https= ://datatracker.ietf.org/meeting/99/agenda/v6ops/. We have some remaining ti= me (about an hour), and are considering a fourth invited talk and several r= ecently-posted drafts: =20 2017-06-14 draft-linkova-v6ops-conditional-ras 2017-06-12 draft-palet-v6ops-rfc7084-bis-transition 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp =20 Additional new drafts could arrive anytime between now and July 3, and = the chairs solicit comments on the above documents, with a view to gauging = working group interest. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sat Jun 17 16:07:09 2017 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 004141243F6 for ; Sat, 17 Jun 2017 16:07:08 -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, 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 zoEsa2N8aCUU for ; Sat, 17 Jun 2017 16:07:06 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77281242F7 for ; Sat, 17 Jun 2017 16:07:05 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id k145so39424360oih.3 for ; Sat, 17 Jun 2017 16:07:05 -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=tYxXHhChHwKR8wZ66eTitO4NX74aYDnDfUhtacjN0to=; b=m+KjdY2+8OlSwVi9h7mqrw+uijgCTRauH3RbtiGC1kfAnQw6CLXpMGwNZ1zcYIxoST oWJ5roHNREd/C6LwLpHqZQRVn8ImAM2c0uUraV7lxguwkWyJ5L7Ai0LnL+PYdL4vm3Vd p0C6aJHID+o4a9Q4IyO4pN0Ied+LFm8mljtGsnLb5qo0S81IUIIKsHpq4O28ALEJ5Q6t eTqg5oYoIgQ+cAswRhev/6YQmUVu7sNldA6Kw3wHESRXc2tkeWMBWkybd9tikk/BhxLj P9llKxDH5eHhdiDNxWZZzP9Q6TBHHOBuGytJ5Bf3RxX9yZH/x3R1alYLm/eCj9bMQdT1 +www== 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=tYxXHhChHwKR8wZ66eTitO4NX74aYDnDfUhtacjN0to=; b=UAVOtLx2RhL01BvmqQ69ZbY34I1aLNpd6vNJvcW4025uPgsV0AFhV3lkmiWd4Znupv vQdViYORwb3Tpslg7ryG7ub58fXy7vYUPbb1GqDNDeqHGFVYfAJwZgh3XvV7xTOlIoNI YUNowb9FwKSeoR7GraS56QZYFzLdAkQzrpoz/iikUOuWBno7HauLNnetdXLFbicTmZAG L835yWRjsZHWS6NZQr5Cjkky2mtoCJZVglaMgqyfCT0Jh+npQEvsQeSaVBe0hpvknadr gvfdJyaimFQqFomXtpYES0vYaKRl+K9BMI54l8FKuuXFA1FskA9YbsVXPcjBfOMJgb6z rPSA== X-Gm-Message-State: AKS2vOzPIzxO27yFuIC6rIjn0Rvz5jwq7nV6HFBYHyhlW/V8ehpxX1DZ HVKlHWsAgWR/ClVt3xw= X-Received: by 10.202.104.84 with SMTP id d81mr7452248oic.42.1497740825302; Sat, 17 Jun 2017 16:07:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::16e5? ([2600:8802:5600:1e::16e5]) by smtp.gmail.com with ESMTPSA id 34sm3327158otw.55.2017.06.17.16.07.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jun 2017 16:07:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> Date: Sat, 17 Jun 2017 16:07:02 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <9D6D2A35-769A-4CF4-8214-0401969DF8A0@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 23:07:08 -0000 In which case 7084-bis could refer to it. I tend to worry about having a = requirements document go into algorithms, which this does (I think it's = an obvious algorithm that doesn't need spelled out, but nobody seems to = have realized that when they did their implementations). And the draft is probably imperfect in some way. > On Jun 17, 2017, at 2:53 PM, JORDI PALET MARTINEZ = wrote: >=20 > Hi Fred, >=20 > I just read the document and I think is something needed. >=20 > In fact, it should be one requirement to be a should or must in the = RFC7084-bis. Not sure if others agree and if there is some way to = =E2=80=9Csync=E2=80=9D a reference in the RFC7084-bis with an individual = I-D (I got an input previously to remove that), until it becomes an RFC = (if approved), or it means =E2=80=9Cholding=E2=80=9D it =E2=80=A6 >=20 > Of course, if there is no opposition in the WG, this may be approved = and go to the last call quicker than the RFC7084-bis, so not being an = issue. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Fred Baker = > Responder a: > Fecha: s=C3=A1bado, 17 de junio de 2017, 23:21 > Para: IPv6 Operations > Asunto: Re: [v6ops] New Version Notification for = draft-baker-v6ops-cpe-autoconfigure-00.txt >=20 > In discussion with John Brzozowski, he expressed a concern that = CPEs don't come "out of the box preconfigured for IPv6" as they often do = for IPv4. I had a recent experience with a new router at my home that = made the point in my mind; IPv6 was an "advanced configuration", and the = difference between "auto-configure" and "auto-detect" was a little lost = on me.=20 >=20 > So I have a question. Do we need to spell this out for CPE vendors? = I have spliced together a draft on the topic. I'd welcome comments that = might improve it, especially if I have something egregiously wrong. = Second, I'm curious whether the working group thinks we need this. >=20 > Your thoughts? >=20 >=20 >> On Jun 17, 2017, at 2:14 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >>=20 >> Name: draft-baker-v6ops-cpe-autoconfigure >> Revision: 00 >> Title: Requirements for a Zero-Configuration IPv6 CPE >> Document date: 2017-06-17 >> Group: Individual Submission >> Pages: 6 >> URL: = https://www.ietf.org/internet-drafts/draft-baker-v6ops-cpe-autoconfigure-0= 0.txt >> Status: = https://datatracker.ietf.org/doc/draft-baker-v6ops-cpe-autoconfigure/ >> Htmlized: = https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoconfigure-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-baker-v6ops-cpe-autoconfigure-= 00 >>=20 >>=20 >> Abstract: >> This note is a breif exploration of what is required for a CPE to be >> auto-configurable from the perspective on an ISP or other upstream >> network. It assumes that the CPE may also be IPv4-capable (probably >> using NAPT), but that the requirements for that are well understood >> and need no further specification. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jun 18 00:18:27 2017 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 88D9B1294A1 for ; Sun, 18 Jun 2017 00:18:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ordnance-co.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaqlLxfft3Sl for ; Sun, 18 Jun 2017 00:18:24 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042B712944F for ; Sun, 18 Jun 2017 00:18:23 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m47so52496811iti.1 for ; Sun, 18 Jun 2017 00:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ordnance-co.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:content-language:content-transfer-encoding :mime-version; bh=nrHeY2XX014QC0Bgf5NAMIluI5EP7dru16rzv0ucBvE=; b=txzsbgeZDFPMRR91TVe9ZmXdUuh1HnI24i4rwHogOsFNLd70b1MLi+yZfN+DZvrRhj IQ7Z7ST3TI260cnlqrWA4fderazZs0gncvGFa6CYKtleajisSRM9MWlifYvKwsTxHuco Y0K8Yl1wJcnWRpPpsNi6B7UfG59oBpVQZj1Het+3pw8Ny+JZRwOh7ZKMB4qDTBnDWRHR Fj+GSSXRns89LWZ4H7x2LCAMwve4uT/pZCI/ocGR2U+FYFOxdLsZ8Jgn2F4GSJos7t67 QurP0ndAg5OXVqA7wWQRk6FCRxGFXpayxaHASxKQ0l0MIWZl2PYy7fol9MRF/8zxJGoG XX/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:content-language :content-transfer-encoding:mime-version; bh=nrHeY2XX014QC0Bgf5NAMIluI5EP7dru16rzv0ucBvE=; b=ambnTTjKzxuLFqGfGKiE54Z1WsHRV1vJiTqeSUX954F/VmwFxCDFsKHgl/72EfbIzR qqy4D+ZhrbJxKRcueJo3EnmduRf+0BedB/LACqGtqow0dJlIp8h6WHne6A5ixF9LoBfR ONMsIdj+KLdq1RzUn6OnTu2DeyagfccgcWy2qvqBrNoM3+1mC09tG9icgmppzmam8l0M 1q1budU1pe5ormrfEXUouf3gieiII2raCqAQCKCQI3rxTaIi19LVbuzozAqMALOskcZ8 Gga0RVLmQSji2NOOXJkQ1+5CMZoY/9UKX5+jsBLYXEmPSbgAlR/w+Q4+jDeZ3O7e2tBy wBsg== X-Gm-Message-State: AKS2vOwVHHYUPrtLkHgp0ITo1XqewUem9/pP9ze8lYKP7HKKEcYN9QKF qM/qVFk7p3DVPOzjWeWH0mx4IKFvUtVuMgIxXa6rDmIlWSYVkwPwx6vkmRU1dQXcopI23S86BVq DRZ802g/nAtvWeL5Wlp48ycVeLA/Ml9ryPVGWWF0y6dwpNTmJXfl+wA== X-Received: by 10.36.46.210 with SMTP id i201mr17173408ita.77.1497770303094; Sun, 18 Jun 2017 00:18:23 -0700 (PDT) Received: from PS1PR03MB1467.apcprd03.prod.outlook.com ([40.96.2.253]) by smtp.gmail.com with ESMTPSA id 73sm3935073ior.3.2017.06.18.00.18.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Jun 2017 00:18:17 -0700 (PDT) From: David Hooton To: IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt Thread-Index: AXIuMzIyLoRQhB8Sn1Zd4sJS05CkhDQ5RDQ2NDk1NDO+MAvinA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 18 Jun 2017 07:18:12 +0000 Message-ID: References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> In-Reply-To: <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 07:18:25 -0000 On 18/6/17, 7:21 am, "v6ops on behalf of Fred Baker" wrote: In discussion with John Brzozowski, he expressed a concern that CPEs do= n't come "out of the box preconfigured for IPv6" as they often do for IPv4.= I had a recent experience with a new router at my home that made the point= in my mind; IPv6 was an "advanced configuration", and the difference betwe= en "auto-configure" and "auto-detect" was a little lost on me.=20 You=92re not the only one. =20 So I have a question. Do we need to spell this out for CPE vendors?=20 Yes. It needs to happen.=20 On 18/6/17, 7:53 am, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: I just read the document and I think is something needed. Agreed. From nobody Sun Jun 18 02:33:55 2017 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 5000A129AA4 for ; Sun, 18 Jun 2017 02:33:54 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS4lmgl13r1Y for ; Sun, 18 Jun 2017 02:33:52 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CE1127867 for ; Sun, 18 Jun 2017 02:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497778429; x=1498383229; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=mwJ4uuzbyQVPQvB4Ld7FLJlJQ y17ya/dWLxHOlKVc+A=; b=tZDzaEnubYbpIgYkfukFwiKz8r5DgIWeI16FLtjkQ icm+qWq0l4q0Yq9UoYqdjDHitJKdX/OF7dqW9XVqREDheQImXJcnt9UWgpaqCzQw KcVdRVAlnkqY+dIhAEpvQEh+twNlQLdAmv89zsGlRLeWNR4IoPaG1ZF8wzETlmIZ H0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=p0oWnvYMYOBKl9hrVbvL04KC7oukwnsddJo6dDMGRPr70ch79xQ9plr9i7UZ DLlan0BUBZD3uQ8CAW/gfAmFX5E7L03OUK3Y6g729n5ryakngoo/tieEa yFSbCpV229dsQf+DUMzwi2qA5SdycLSKkC79zLddnVw4zIXQmPNnDM=; X-MDAV-Processed: mail.consulintel.es, Sun, 18 Jun 2017 11:33:49 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 18 Jun 2017 11:33:48 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452900.msg for ; Sun, 18 Jun 2017 11:33:47 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170618:md50005452900::v8YLMUuJPzspsd5x:0000NCW0 X-Return-Path: prvs=1342757a7a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 18 Jun 2017 11:33:47 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <32FAC760-ABAD-4315-AB62-27EF684C5663@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <549B57F3-A07B-4964-895E-C9AD962A5AD4@consulintel.es> <9D6D2A35-769A-4CF4-8214-0401969DF8A0@gmail.com> In-Reply-To: <9D6D2A35-769A-4CF4-8214-0401969DF8A0@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 09:33:54 -0000 Some detailed comments: and allocate IPv6 /64 prefixes for each of its interior subnets using the IPv6 Prefix Options for DHCP [RFC3633]. I think it is needed to state something about a prefix shorter than /64 is = allocated to the =E2=80=9CLAN-side=E2=80=9D to ensure that the CPE, either = in an unmanaged way (maybe HNCP, not sure if something else may be consider= ed), or managed by the =E2=80=9Ccustomer=E2=80=9D, so than a /64 can be ass= igned to each possible subnet/VLAN/SSID/whatever, or even shorter prefixes = to downstream routers (for instance a /48 from the ISP broken in /56 inside= the network other routers and /64 for each LAN). Same question here: 4. Given an upstream interface and a delegation of pre= fixes to use downstream, it should * subdelegate a /64 prefix to each downstream interface It seems to only support /64 to downstream interfaces, unless you read =E2= =80=9CPrefix delegation=E2=80=9D, may be some alternative text may clarify = it at an earlier point. At =E2=80=9CExpected Behavior=E2=80=9D, maybe is worth to mention that in c= ase native IPv6 access is not available, and transition mechanisms are supp= orted, the CPE must try con configure one of them. Probably after =E2=80=9C= waking up=E2=80=9D each possible transition mechanism, the same =E2=80=9Clo= op=E2=80=9D as you described in the =E2=80=9CExpected Behavior=E2=80=9D sec= tion, must be tested to be able to get =E2=80=9CIPv6 up and running=E2=80= =9D. Finally, if the access is IPv6-only, it may be expected some =E2=80=9CIPv4 = as a service=E2=80=9D support, and then RFC8026 may be helpful to configure= it. I know you mention in the intro that IPv4 is specified somewhere else,= but in this case, is not =E2=80=9Cnative IPv4=E2=80=9D, but a =E2=80=9Cser= vice=E2=80=9D by means of and IPv6 network. Regards, Jordi =20 -----Mensaje original----- De: Fred Baker Responder a: Fecha: domingo, 18 de junio de 2017, 1:07 Para: JORDI PALET MARTINEZ CC: IPv6 Operations Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-auto= configure-00.txt In which case 7084-bis could refer to it. I tend to worry about having = a requirements document go into algorithms, which this does (I think it's a= n obvious algorithm that doesn't need spelled out, but nobody seems to have= realized that when they did their implementations). =20 And the draft is probably imperfect in some way. =20 > On Jun 17, 2017, at 2:53 PM, JORDI PALET MARTINEZ wrote: >=20 > Hi Fred, >=20 > I just read the document and I think is something needed. >=20 > In fact, it should be one requirement to be a should or must in the R= FC7084-bis. Not sure if others agree and if there is some way to =E2=80=9Cs= ync=E2=80=9D a reference in the RFC7084-bis with an individual I-D (I got a= n input previously to remove that), until it becomes an RFC (if approved), = or it means =E2=80=9Cholding=E2=80=9D it =E2=80=A6 >=20 > Of course, if there is no opposition in the WG, this may be approved = and go to the last call quicker than the RFC7084-bis, so not being an issue= . >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Fred Baker > Responder a: > Fecha: s=C3=A1bado, 17 de junio de 2017, 23:21 > Para: IPv6 Operations > Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cp= e-autoconfigure-00.txt >=20 > In discussion with John Brzozowski, he expressed a concern that CP= Es don't come "out of the box preconfigured for IPv6" as they often do for = IPv4. I had a recent experience with a new router at my home that made the = point in my mind; IPv6 was an "advanced configuration", and the difference = between "auto-configure" and "auto-detect" was a little lost on me.=20 >=20 > So I have a question. Do we need to spell this out for CPE vendors= ? I have spliced together a draft on the topic. I'd welcome comments that m= ight improve it, especially if I have something egregiously wrong. Second, = I'm curious whether the working group thinks we need this. >=20 > Your thoughts? >=20 >=20 >> On Jun 17, 2017, at 2:14 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >>=20 >> Name: draft-baker-v6ops-cpe-autoconfigure >> Revision: 00 >> Title: Requirements for a Zero-Configuration IPv6 CPE >> Document date: 2017-06-17 >> Group: Individual Submission >> Pages: 6 >> URL: https://www.ietf.org/internet-drafts/draft-baker-v6o= ps-cpe-autoconfigure-00.txt >> Status: https://datatracker.ietf.org/doc/draft-baker-v6ops-c= pe-autoconfigure/ >> Htmlized: https://tools.ietf.org/html/draft-baker-v6ops-cpe-au= toconfigure-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-baker-v6= ops-cpe-autoconfigure-00 >>=20 >>=20 >> Abstract: >> This note is a breif exploration of what is required for a CPE to b= e >> auto-configurable from the perspective on an ISP or other upstream >> network. It assumes that the CPE may also be IPv4-capable (probabl= y >> using NAPT), but that the requirements for that are well understood >> and need no further specification. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of su= bmission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Jun 18 03:57:46 2017 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 135B0129AB0 for ; Sun, 18 Jun 2017 03:57:45 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33bVN7V7HCQq for ; Sun, 18 Jun 2017 03:57:43 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA9D120724 for ; Sun, 18 Jun 2017 03:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1497783459; x=1498388259; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=0X030Ne1qJjrQiq48IXEa/itG aHD/+Z2Mc7wtGh4vXk=; b=f/Y0dLh+ohuiYswnEY6rMRS34GQGjDyX3DK1YAMUh oYIHO0VThluaHBOJ6NlcR0toVHCe+w4ziVYZYJb09NHMKQ03e3sl1ZK9mGhTndZI Y6zGUfPACEPPZoq4etVAQbhqJrVApwc/OdumweDq3EWwI8kpb1jT9vd0xi9CKQPi Cs= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=heBfzR0Cp2A5azUzPb/ScdjT+aNbEtWqQiUQGcRS+rnPxbaGmLmBpzTmYszR ldJdRJct+14qEdDyhO6PZRpSiRSNwgxX+ysuqTq3phfdmfRqq3ZQXx3TP COl2YZtHV98oAiC3/bR7MuekSXUMDjJyJ8i5SkwqTx29dj4UyAmggw=; X-MDAV-Processed: mail.consulintel.es, Sun, 18 Jun 2017 12:57:39 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 18 Jun 2017 12:57:38 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005452913.msg for ; Sun, 18 Jun 2017 12:57:38 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170618:md50005452913::F93HaEOqTlZsBFxZ:00001aHq X-Return-Path: prvs=1342757a7a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Sun, 18 Jun 2017 12:57:35 +0200 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 10:57:45 -0000 Hi David, Very good job! Some comments. Implementations MUST NOT wait for both families of answers to return before attempting connection establishment. If one query fails to return, or takes significantly longer to return, waiting for the second address family can significantly delay the connection establishment of the first one. Therefore, the client MUST treat DNS resolution as asynchronous. Note that if the platform does not offer an asynchronous DNS API, this behavior can be simulated by making two separate synchronous queries on different threads, one per address family. If the AAAA query returns first, the first IPv6 connection attempt MUST be immediately started. If the A query returns first, the client SHOULD wait for a short time for the AAAA response. This delay will be referred to as the "Resolution Delay". The RECOMMENDED value for the Resolution Delay is 50 milliseconds. [Jordi] I=E2=80=99m not sure to fully understand this text, as somehow seem= s to me contradictory. =E2=80=9Cwaiting for the second address family can s= ignificantly delay the connection=E2=80=9D, but then you mention 50 millise= conds as recommended. I think it will be nice to clarify it. Also, I think = the Resolution Delay should be a parameter, somehow configurable in the OS = or apps. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use o= f HE (by increasing the delay to an exaggerated value), without necessarily= removing the code neither breaking apps that rely on it, when we decide th= at IPv6 is widely spread so any IPv6 failures should be noticed by end-user= s in order to pass the message to the ISP, etc. (note that this is not referring to the sending of AAAA or A queries, but rather the address of the DNS server itself) [Jordi] To make it clear, maybe you want to say something such as =E2=80=9C= =E2=80=A6 but rather the protocol used for the DNS transport=E2=80=9D This delay is referred to as the "Connection Attempt Delay". One recommended value for this delay is 250 milliseconds. [Jordi] Similar comments about the =E2=80=9CConnection Attempt Delay=E2=80= =9D as earlier: should be a parameter, somehow configurable in the OS or ap= ps. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use of HE = (by increasing the delay to an exaggerated value), without necessarily remo= ving the code neither breaking apps that rely on it, when we decide that IP= v6 is widely spread so any IPv6 failures should be noticed by end-users in = order to pass the message to the ISP, etc. 464XLAT has the advantage of not requiring changes to user space software, however it requires per-packet translation and does not encourage client application =E2=80= =A6 [Jordi] I think this text will make it more accurate: =E2=80=9C464XLAT has the advantage of not requiring changes to user space software, however it requires per-packet translation in case the application is using IPv4 literals (o= r similar situations as older socket APIs) and does not encourage client ap= plication =E2=80=A6 [Jordi] One question here. Should section 7.1 also consider not just litera= ls but old socket APIs? 7.2 Host Names with Broken AAAA Records [Jordi] I think you could add in this section (or a new section), the case = for broken PMTUD. We have today many situations were on purpose or as a con= sequence of bad implementation of load-balancing, ECMP, etc. You can try it= with any web site from 1&1 (for example diskmakerx.com) =E2=80=A6 just for= ce a reduction on your MTU I you will find that the website is not only non= -accessible with IPv6, but also doesn=E2=80=99t work with IPv4, because act= ual HE implementations aren=E2=80=99t able to detect this problem. I think = it will be possible and of course, it will mean removing or having a differ= ent text for =E2=80=9C9.1. Path Maximum Transmission Unit Discovery=E2=80= =9D. I agree that because the nature of HE, active only at the initial stag= e, we need to somehow extend the HE algorithm to test that, but I think thi= s is the perfect opportunity to make it, because HE is successfully impleme= nted everywhere, so I guess it will be successfully updated. Making it a = =E2=80=9Cdifferent=E2=80=9D RFC/protocol, may not have the same impact. [Jordi] Of course, I think is a major ISP/date center issue, but they aren= =E2=80=99t resolving it (tried for two years in this specific case), but th= ere are many others, worldwide, and if we believe HE is the right solution = for =E2=80=9CISPs not doing correctly their job=E2=80=9D, then we should al= so support this =E2=80=9Cfailure=E2=80=9D. Again, using parameters, to make= sure that when IPv6 is more globally spread we can =E2=80=9Cdeprecate=E2= =80=9D HE and make sure to pass the ball again to those =E2=80=9Cbad guys i= n the sense that they don=E2=80=99t do a good job, or don=E2=80=99t make su= re that they test correctly their deployments from the perspective of all k= ind of users=E2=80=9D. 8. Summary of Configurable Values [Jordi] Looking at this section, you=E2=80=99re saying somehow what I was e= xpressing earlier, so maybe we can make it clearer and is the right place t= o include a must to have all those parameters as OS configurable ones (by a= pps, users, network management, etc.). Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de David Schinazi Responder a: Fecha: martes, 6 de junio de 2017, 2:10 Para: IPv6 Ops WG Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 Hi v6ops, We have updated draft-ietf-v6ops-rfc6555bis to version 01. https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 =20 This version incorporates feedback we received on the previous version, and adds a new section on "Supporting IPv6-only Networks with NAT64 and= DNS64" as these technologies require changes in the Happy Eyeballs stack on devices that do not support 464XLAT. =20 Please let us know what you think! =20 Thanks, David Schinazi =20 =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations of the IETF. =20 Title : Happy Eyeballs Version 2: Better Connectivity= Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-01.txt Pages : 13 Date : 2017-06-05 =20 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, client= s that attempt multiple connections in parallel have a higher chance o= f establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis-01 =20 =20 =20 =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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Jun 19 02:43:37 2017 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 3F164124E15 for ; Mon, 19 Jun 2017 02:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWZzc6utUK1e for ; Mon, 19 Jun 2017 02:43:33 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB22126DED for ; Mon, 19 Jun 2017 02:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497865410; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=hdhy/pKUOr9uNVbmpMLCYBr8utDiMnGzRLFhuES9Vik=; b=XmhcJjAmS+vZap66B6MpNOGXaJ57QLRuG/QHbLyTkLRJrBf8jcORc4uC1aeT4HVIOyJ0O3mQZMTmsSsK60chzQObaJ5RcceK+XZTiIDwUzHCuS8I0ax448I/pf28IHtzLkcY/OGWUVQTGaN6YaI43TgiVFohBqZxjJIr8wVerW0= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-65-L7jFh1N9MWWBgmI5AcBXjA-1; Mon, 19 Jun 2017 10:43:24 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Mon, 19 Jun 2017 09:43:22 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd%14]) with mapi id 15.01.1199.007; Mon, 19 Jun 2017 09:43:22 +0000 From: Tim Chown To: Fred Baker CC: IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt Thread-Index: AQHS56+2wt4mzGA7yUeFvbr0tMKFnKIr8ZqA Date: Mon, 19 Jun 2017 09:43:22 +0000 Message-ID: <555ACC46-7A71-4CA7-82AA-BDB8B02233F1@jisc.ac.uk> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:d525:b649:6674:a33c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:xQoN6Tq+S4cwj5IvKooxl+Ldts1z+zLfzuEr5OY3/96J6xyf2gVkTypRedSFAwp4Daj49tBnVSPXwBD7P6CEc8JVTKzDwHzz86j/4AP50OIfxc6CR9pcTpElJwH9sui7A9yoi1aF9uNZcl196F8JHoTyjZkDUe2CmbK9p6KPACw= x-ms-office365-filtering-correlation-id: ba4a3ed0-38fe-4ccd-5360-08d4b6f7a032 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; x-ms-traffictypediagnostic: AM3PR07MB1137: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(377424004)(377454003)(57704003)(24454002)(36756003)(6512007)(6916009)(2950100002)(42882006)(5660300001)(86362001)(6506006)(50986999)(76176999)(99286003)(6436002)(6306002)(38730400002)(74482002)(966005)(14454004)(53936002)(478600001)(2900100001)(305945005)(72206003)(7736002)(6246003)(110136004)(230783001)(57306001)(3660700001)(8676002)(50226002)(2906002)(25786009)(53546009)(81166006)(3280700002)(8936002)(81156014)(5250100002)(6486002)(82746002)(102836003)(189998001)(6116002)(83716003)(33656002)(4326008)(229853002)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 09:43:22.5818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: L7jFh1N9MWWBgmI5AcBXjA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 09:43:36 -0000 Hi, > On 17 Jun 2017, at 22:21, Fred Baker wrote: >=20 > In discussion with John Brzozowski, he expressed a concern that CPEs don'= t come "out of the box preconfigured for IPv6" as they often do for IPv4. I= had a recent experience with a new router at my home that made the point i= n my mind; IPv6 was an "advanced configuration", and the difference between= "auto-configure" and "auto-detect" was a little lost on me.=20 >=20 > So I have a question. Do we need to spell this out for CPE vendors? I hav= e spliced together a draft on the topic. I'd welcome comments that might im= prove it, especially if I have something egregiously wrong. Second, I'm cur= ious whether the working group thinks we need this. >=20 > Your thoughts? It would be great if a document like this were not needed, but anecdotal ev= idence suggests that it is.=20 Tim >> On Jun 17, 2017, at 2:14 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >>=20 >> Name:=09=09draft-baker-v6ops-cpe-autoconfigure >> Revision:=0900 >> Title:=09=09Requirements for a Zero-Configuration IPv6 CPE >> Document date:=092017-06-17 >> Group:=09=09Individual Submission >> Pages:=09=096 >> URL: https://www.ietf.org/internet-drafts/draft-baker-v6ops-c= pe-autoconfigure-00.txt >> Status: https://datatracker.ietf.org/doc/draft-baker-v6ops-cpe-a= utoconfigure/ >> Htmlized: https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoco= nfigure-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-baker-v6ops-= cpe-autoconfigure-00 >>=20 >>=20 >> Abstract: >> This note is a breif exploration of what is required for a CPE to be >> auto-configurable from the perspective on an ISP or other upstream >> network. It assumes that the CPE may also be IPv4-capable (probably >> using NAPT), but that the requirements for that are well understood >> and need no further specification. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Jun 19 07:34:53 2017 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 0180B1314F0 for ; Mon, 19 Jun 2017 07:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neo-co-tz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzLeqqE3uzRB for ; Mon, 19 Jun 2017 07:34:49 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F841314EB for ; Mon, 19 Jun 2017 07:34:48 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id y25so36533000wrd.2 for ; Mon, 19 Jun 2017 07:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neo-co-tz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K069d2LSr0ST05fElwHh301HJ8l15rjlYu/wXrGjkNE=; b=bJ/q+NOx3RNeThfyuc3ed89m7zkN77uCmoZ8Gh3F0bnFjo5PBzm+OxIZPsvKrx0OUH CqZ2acOHoGOeJ76cFHWA5H1Pd5I76SV7/8J2oXds78WQayNUiuqHV47MStE3wGIP7PYy LMx1SxQd91Sb50FmE8J3oKL/Med6XwM+bKD62JolUaH5Gi6y3/ejtyPPIVuxX/SDxEI+ HJSKZrdilcB40txBASwhHmklBVN/ARC+VDpHQ4YXuqW1Iynnho4dgZxkcK27Uy0Giumi K86jmZcE7GHjl06His0UEMwlV7mH4GNnSc1FFrg5KkoDavYQvU2fdkkJHv19ZBHKgxTV 5wrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K069d2LSr0ST05fElwHh301HJ8l15rjlYu/wXrGjkNE=; b=RDMuSrHyMfHlP8bs77xq05CPPecqdiPmkouwpcU6WBlZ/uQJfeR69LL9ebdtUfFLTR SUcGAz8F8QOWdnYdyvtilp+xMdX+oEHwLGjxvzBD+ZtSXOXfsfpS+DhW6Z446MtdkNMW QS/TYD153RVaETMRLMJ5d41dJWVYA9TiQ5tmsICBa5kQLz13j2QBPPbeqUQVfwCkR1Iw Bx7xjBAK1OMYuFalNHxO8+Fuw+iFkH0PqedMEmB/2wKMmI8x7xUO5a+uXRgna0rr40Os P/TTbXTC3/LQvciHcP4I5m0GCctoDZ7dnNEfIvNvjsDypbEm1AkQwoDF4CHCFcPqK0Qz HYVA== X-Gm-Message-State: AKS2vOzSNmlTda/istCy4/SKD5TFJzk4EPn15cAngWssIV0h95a8H+Lc 8R6zW7LXoDTIo10WSf55skBx//BvlD3hzmA= X-Received: by 10.223.176.133 with SMTP id i5mr16749128wra.53.1497882886640; Mon, 19 Jun 2017 07:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.168.132 with HTTP; Mon, 19 Jun 2017 07:34:45 -0700 (PDT) X-Originating-IP: [105.28.32.9] Received: by 10.28.168.132 with HTTP; Mon, 19 Jun 2017 07:34:45 -0700 (PDT) In-Reply-To: <8AACE37B-E760-47D2-B17F-A09AAADF8A9A@gmail.com> References: <1D8A289A-86C2-47C9-90E2-A36E3BB414D6@gmail.com> <8AACE37B-E760-47D2-B17F-A09AAADF8A9A@gmail.com> From: Noah Date: Mon, 19 Jun 2017 17:34:45 +0300 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a1141ae605fb24b05525109fb" Archived-At: Subject: Re: [v6ops] New drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:34:51 -0000 --001a1141ae605fb24b05525109fb Content-Type: text/plain; charset="UTF-8" Hi Fred On 17 Jun 2017 11:25 p.m., "Fred Baker" wrote: > On Jun 17, 2017, at 1:49 AM, Noah wrote: > > Hi Fred > > Thank you for sharing this drafts. > > Do we also have similar ones for end user devices ref: > > 1.Android with updates Linux Kernel > 2.MacOS/Windows > > Noah I'm not sure I understand your question. As Jordi points out, there is an update to IPv6 Node Requirements in 6man. This document is an important part of the basis for the IPv6 Ready Logo program, the US Government "Planning Guide/Roadmap Toward IPv6 Adoption", and RIPE 554. It is not specific to any given platform; it is intended to describe all platforms. If you're looking for something specific to Android, Linux, MacOS, Windows, or anything else (such as perhaps iOS or IoT MCU RTOS's), no, we don't have product-specific documents, and they are not part of our charter. What Jordi shared earlier is what I was looking for and got the answer in there. Does that address what you're looking for, or are you looking for something else? It does clarify and thank you for your feeback. Noah --001a1141ae605fb24b05525109fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fred

On 17 Jun 2017 11:25 p.m., "Fred Baker" <fredbaker.ietf@gmail.com> wr= ote:

> On Jun 17, 2017, at 1:49 AM, Noah <noah@neo.co.tz> wrote:
>
> Hi Fred
>
> Thank you for sharing this drafts.
>
> Do we also have similar ones for end user devices ref:
>
> 1.Android with updates Linux Kernel
> 2.MacOS/Windows
>
> Noah

I'm not sure I understand your question.

As Jordi points out, there is an update to IPv6 Node Requirements in 6man. = This document is an important part of the basis for the IPv6 Ready Logo pro= gram, the US Government "Planning Guide/Roadmap Toward IPv6 Adoption&q= uot;, and RIPE 554.=C2=A0 It is not specific to any given platform; it is i= ntended to describe all platforms. If you're looking for something spec= ific to Android, Linux, MacOS, Windows, or anything else (such as perhaps i= OS or IoT MCU RTOS's), no, we don't have product-specific documents= , and they are not part of our charter.
<= div dir=3D"auto">
What Jordi shared earlier is w= hat I was looking for and got the answer in there.
<= br>

Does that address what you're looking for, or are you looking for somet= hing else?

It doe= s clarify and thank you for your feeback.

=
Noah
--001a1141ae605fb24b05525109fb-- From nobody Mon Jun 19 07:59:41 2017 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 81BC113151A for ; Mon, 19 Jun 2017 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 i2mXAZojWlLV for ; Mon, 19 Jun 2017 07:59:34 -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 39FBB131516 for ; Mon, 19 Jun 2017 07:59:31 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5JDjUNx005510; Mon, 19 Jun 2017 09:47:44 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2b6bf9sst2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 09:47:44 -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 v5JDlg7i026723; Mon, 19 Jun 2017 09:47:42 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5JDlXGl026475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jun 2017 09:47:36 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 19 Jun 2017 13:47:27 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Mon, 19 Jun 2017 09:47:27 -0400 From: "STARK, BARBARA H" To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt Thread-Index: AQHS56+w6G39dmryMUGu+j6PZAaxUKIsJ3eQ Date: Mon, 19 Jun 2017 13:47:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.235.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_08:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190232 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:59:38 -0000 > Your thoughts? Here are a number of my thoughts. BBF described automated IPv6 configuration for telco-procured CE routers in= TR-124 (https://www.broadband-forum.org/technical/download/TR-124_Issue-5.= pdf) in Annex A. A.1 is for PPPoE and A.2 is for native IPv6. I don't see a= need for this draft wrt CE routers my company procures, because auto-confi= g advice already exists. The BBF flow has simultaneous RS and DHCPv6 solicitation. This is at odds w= ith what you suggest. Simultaneous and sequential are both allowed by RFC 7= 084. I realize many cable providers have expressed a preference for sequent= ial RS and DHCPv6 solicit, but many telcos have expressed a preference for = simultaneous. But both models work in cable and telco environments. The BBF flow mandates requesting IA_PD, while you propose it as a very weak= MAY. Note that RFC 7084 mandates support for IA_PD. If you really want aut= o config of a CE router, this is the only way I know of to do it. I don't s= ee that a MAY IA_PD requirement would ever result in auto configuration. On= ly a MUST will. BBF also supports auto-configuration via the unnumbered model where the RA = does not include an Autonomous prefix and there is no offered IA_NA. RFC 70= 84 allows for the unnumbered model. You make no mention of the unnumbered m= odel. I don't know how prevalent the unnumbered model is, though. Sub-delegating into a home network with many subnets (which means the topol= ogy is likely to be unpredictable and arbitrary) really needs HNCP and not = IA_PD. In the absence of HNCP, any algorithm to try to calculate the correc= t number of needed prefixes doesn't make sense to me. In other words, I wou= ldn't trust a calculation that resulted in a need for 17 prefixes, in the a= bsence of HNCP. As a final note, I have a pet peeve wrt "CPE". CPE =3D *all* Customer Premi= ses Equipment, including set-top boxes, home automation gateways, VoIP ATAs= , etc. Unless this doc is for auto-config of STBs and the rest, could I con= vince you to use "CE Router"? "CER" can be used as an abbreviated form. Barbara From nobody Mon Jun 19 12:07:32 2017 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 62219131689; Mon, 19 Jun 2017 12:07:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, Fred Baker , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149789924339.10707.17736967865508385069.idtracker@ietfa.amsl.com> Date: Mon, 19 Jun 2017 12:07:23 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-v4v6-xlat-prefix-01: (with DISCUSS) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 19:07:23 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-v4v6-xlat-prefix-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 4.2. I found the explanation to be useful but the prefix that was not selected seems to be wrong (a prefix with non-zero bits past the prefix length does not really make sense). The prefix that is adjacent to 64:ff9b::/96 is actually 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the document. This means that most of the text that follows is incorrect. i.e. The range will be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - 64:ff9b::ffff:ffff P.S.: I thought hard about whether this should be a DISCUSS or a COMMENT but I decided to go with a DISCUSS because I think it really needs to be fixed From nobody Mon Jun 19 13:44:36 2017 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 14D20126C89 for ; Mon, 19 Jun 2017 13:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kCGO4Syf1vOX for ; Mon, 19 Jun 2017 13:44:32 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC80126C22 for ; Mon, 19 Jun 2017 13:44:31 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id p187so3308615oif.3 for ; Mon, 19 Jun 2017 13:44:31 -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=U5+EOGnBcNxx/x+KmMz7rcM6hnMbj2vR/SY/5nw9MU4=; b=BqimIWf3vsyJuGO87BbUA0JzBX4uyGuX6moz7bb7IvqMxbbGZ32oryKGs+yMgNUaxa FEZ8mPP8cfY3er2svUu6ISI6aBlkhXhlEq6619vMi9zRyu6TLCP1mtz7WsgSuLyTPaY8 +F0OgVDSnb2uASqK1ugnQcEeU98fYKpV3rCZLPuPVZoOG6vfjN4VL1BM47BRM3BANCm2 nkLSscEB1FF8XXv6hgHBwsHdYCP1uDYc7IELbOWf41xPbXaT0Ocp/pdF3Dmun58XlZ9o jxeI2tLSF23R2MCUfqJnSgtuiVBw31jJOOYdDA8/O8wzIKRDTiAECX8pFDVWR/h4aNJK J9xA== 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=U5+EOGnBcNxx/x+KmMz7rcM6hnMbj2vR/SY/5nw9MU4=; b=DjX/93nksZ0SXrGYRAtRtPNl9ZArtKP4Xs2NKJDjuMKBA9XuL8miU1MkevWaNyikSy YHkQLhtiTZktFWxVQND9heBUa6bVxSmBCkyzst+U1GtKvEijvYUrIvm3yeAUtefju2qH sHWUcL+DLLsZY8zDfSvJzDmpu3I1tMf07pmP0w3QzSGDsxmd2D4RDDPdwNmuaW1mLwYm HCIdYhYOlb/ZJdl4ivdn6O5IiRdE1DMRxgEF/Bi2YmgZff8XSufD62fGawSTE5OP4nva PDgpnZ3lU4Exsq/U8zgiBBn8BRLlaci955uoxNk2HJdv+sQzUECvwtyagCBS/1+B/FVY bQEA== X-Gm-Message-State: AKS2vOyXTFA30IOrEMjIadNxOWlsbX4vK5QTAUz4n8uMLFDtkq5e8iAD Vyi0C5YNfrMz1w== X-Received: by 10.202.52.194 with SMTP id b185mr12380393oia.8.1497905071333; Mon, 19 Jun 2017 13:44:31 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1180? ([2600:8802:5600:1e::1180]) by smtp.gmail.com with ESMTPSA id l92sm6192177otc.13.2017.06.19.13.44.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jun 2017 13:44:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Mon, 19 Jun 2017 13:44:29 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <0A5C360E-0038-4CA0-AC3E-E8B75FD770FE@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 20:44:34 -0000 On Jun 19, 2017, at 6:47 AM, STARK, BARBARA H wrote: > BBF described automated IPv6 configuration for telco-procured CE = routers in TR-124 = (https://www.broadband-forum.org/technical/download/TR-124_Issue-5.pdf) = in Annex A. A.1 is for PPPoE and A.2 is for native IPv6. I don't see a = need for this draft wrt CE routers my company procures, because = auto-config advice already exists. Thanks. TR-124, of course, applies to DSL routers procured by companies = and used in managed router services. It doesn't apply to Cable Modem = routers, nor to routers used in open source networks such as Jordi = discusses in his 7084-bis. Are you objecting to the draft, or simply stating that it covers = material already covered for DSL routers used in ISP managed service?= From nobody Mon Jun 19 15:40:22 2017 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 CAB181294F4 for ; Mon, 19 Jun 2017 15:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 Rid6ndUuXRja for ; Mon, 19 Jun 2017 15:40:19 -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 246A4129526 for ; Mon, 19 Jun 2017 15:40:19 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5JMa7d8014907; Mon, 19 Jun 2017 18:40:16 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2b6pm29efu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 18:40:16 -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 v5JMeEpd016536; Mon, 19 Jun 2017 18:40:15 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5JMe8Fb016399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jun 2017 18:40:10 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 19 Jun 2017 22:39:53 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Mon, 19 Jun 2017 18:39:53 -0400 From: "STARK, BARBARA H" To: Fred Baker CC: IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt Thread-Index: AQHS56+w6G39dmryMUGu+j6PZAaxUKIsJ3eQgADF6YD//9hWsA== Date: Mon, 19 Jun 2017 22:39:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB9AFD6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> <0A5C360E-0038-4CA0-AC3E-E8B75FD770FE@gmail.com> In-Reply-To: <0A5C360E-0038-4CA0-AC3E-E8B75FD770FE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.253.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_12:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190374 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:40:21 -0000 > Thanks. TR-124, of course, applies to DSL routers procured by companies a= nd > used in managed router services. It doesn't apply to Cable Modem routers, > nor to routers used in open source networks such as Jordi discusses in hi= s > 7084-bis. >=20 > Are you objecting to the draft, or simply stating that it covers material= already > covered for DSL routers used in ISP managed service? TR-124 is used by telco ISPs for a variety of procured CE routers, includin= g those with and without a DSL modem or G.fast or PON ONT interface. Some j= ust have Ethernet WAN. It is not limited to DSL WAN interface. Note that th= e Annex A procedures assume nothing more than Ethernet MAC to the WAN. I would object to anything that suggested the auto-configuration processes = that may be used by cable providers are somehow superior, better, preferred= , or recommended over auto-config procedures used by non-cable providers. There are numerous "correct" ways to do IPv6 auto-config. Describing just o= ne, and then making it normative in a 7084-bis would not be something I wou= ld favor. If cable providers want to get together and say "FYI, here is a w= ay some cable operators like to do auto-config", I would not object. Or if = v6ops wanted to do a draft of "here are several possible and valid ways to = do auto-config that would be RFC7084-compliant -- pick any one of them beca= use the only requirement for interoperability is RFC7084", I would be happy= to participate. Barbara From nobody Tue Jun 20 01:55:01 2017 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 A15CD1293F5; Tue, 20 Jun 2017 01:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 7FiHGfeS72Kr; Tue, 20 Jun 2017 01:54:50 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 784F6128B91; Tue, 20 Jun 2017 01:54:47 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=55244 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dNEvs-0001mt-Tr; Tue, 20 Jun 2017 08:54:44 +0000 Date: Tue, 20 Jun 2017 10:54:44 +0200 From: Tore Anderson To: Suresh Krishnan Cc: "The IESG" , v6ops@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Message-ID: <20170620105444.4d6e0330@echo.ms.redpill-linpro.com> In-Reply-To: <149789924339.10707.17736967865508385069.idtracker@ietfa.amsl.com> References: <149789924339.10707.17736967865508385069.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-v4v6-xlat-prefix-01: (with DISCUSS) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 08:54:53 -0000 * Suresh Krishnan > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > * Section 4.2. > > I found the explanation to be useful but the prefix that was not selected seems > to be wrong (a prefix with non-zero bits past the prefix length does not really > make sense). The prefix that is adjacent to 64:ff9b::/96 is actually > 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the document. > This means that most of the text that follows is incorrect. i.e. The range will > be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - > 64:ff9b::ffff:ffff > > P.S.: I thought hard about whether this should be a DISCUSS or a COMMENT but I > decided to go with a DISCUSS because I think it really needs to be fixed Hi Suresh, Good catch - thanks! I've prepared an update. I'd appreciate it if you could confirm that it resolves your concern fully before I post it to the data tracker though. RFC diff here: https://tools.ietf.org//rfcdiff?url1=draft-ietf-v6ops-v4v6-xlat-prefix-01&url2=https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt Full new draft: https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt Tore From nobody Tue Jun 20 10:38:08 2017 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 BAAB6131584; Tue, 20 Jun 2017 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRocTZdIiVij; Tue, 20 Jun 2017 10:38:04 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC0713155E; Tue, 20 Jun 2017 10:38:04 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d14so63405044qkb.1; Tue, 20 Jun 2017 10:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9ejHD8QTNyIfL5FpkcsZ6ivLHAlhZQlltuIAmfsf6D4=; b=A1gQJ9zt7FCvsRVnfZwwvHcxDFpn2FWtTPhBnJfyKnKrUaXgUFTVprpb/2ROFDHmr8 vrpH5sEhOQ1LNvT/Nkif79lHeBO8VdMofSdR2HNqCBKpgWkJqfzywJnCOCfgNZPOUuHF G7gnyGR3cInelsEBp2HCfv9AzBRETYCdQtFE/oS7KgzcPWU2Nq9gpIdh/vh+OJmGANsW xHvAr+JULfQ9dof251y7VRJwMEJCSqD1OQ+a/z9HFFW/bw9FFZ6PjwRqbQPN8mlEjnnw ac32O//+WWEajzA4xri+Wa3KIRXLTs8mDJz4dqNVsrNuBWHLVeCnYXrp2UFYWpclKaLD IdLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9ejHD8QTNyIfL5FpkcsZ6ivLHAlhZQlltuIAmfsf6D4=; b=nGu6gXeYQy/JNvpyx5krB0xZcaQqwYKhhrTXGNHNDjX2jPUsiLkzRwhOa4BLK8ymLr Ai1HmhOynHkog23F8Z+oZHBgY0DgAyakd+DnGzlpApHqXGakePYgpPpv75D8tyaEgW8P 0+h9Jy4DDq0d17ka6iKuBiJ2dU9tnb+7LX4Wgkvk61HD8NfrEtWaEublT415JOn2W56q swbmyBUUNC6WcWT4obivBdFS8eO/JX+KSGP0Iry1SJjbUMxdiu95AEPCp9UVLU3B0zOl s/tLdeMlhTScD7GpmrFeEo0lknxQvEAL7dFg8dSl1FDbxCfPK2SQ5Y+9nyWdknlUInJh 6OSA== X-Gm-Message-State: AKS2vOymeffK76a1lfUtllHz4lwmw/dSFLjBm2ymJZnoS55zvMs9B8pD M0eDUPXCUBOLZ/QsU+aeSzGBv+j5AQ== X-Received: by 10.55.197.136 with SMTP id k8mr26082998qkl.211.1497980283373; Tue, 20 Jun 2017 10:38:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.159.211 with HTTP; Tue, 20 Jun 2017 10:38:02 -0700 (PDT) Received: by 10.55.159.211 with HTTP; Tue, 20 Jun 2017 10:38:02 -0700 (PDT) In-Reply-To: <20170620105444.4d6e0330@echo.ms.redpill-linpro.com> References: <149789924339.10707.17736967865508385069.idtracker@ietfa.amsl.com> <20170620105444.4d6e0330@echo.ms.redpill-linpro.com> From: Suresh Krishnan Date: Tue, 20 Jun 2017 13:38:02 -0400 Message-ID: To: Tore Anderson Cc: V6ops Chairs , IESG , IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Content-Type: multipart/alternative; boundary="001a1149db8cabcfe8055267b6ee" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-v4v6-xlat-prefix-01: (with DISCUSS) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:38:07 -0000 --001a1149db8cabcfe8055267b6ee Content-Type: text/plain; charset="UTF-8" Hi Tore, Thanks for taking care of this quickly. I have looked at the diff and it nicely addresses my concerns. Regards Suresh On Jun 20, 2017 2:24 PM, "Tore Anderson" wrote: > * Suresh Krishnan > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > * Section 4.2. > > > > I found the explanation to be useful but the prefix that was not > selected seems > > to be wrong (a prefix with non-zero bits past the prefix length does not > really > > make sense). The prefix that is adjacent to 64:ff9b::/96 is actually > > 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the > document. > > This means that most of the text that follows is incorrect. i.e. The > range will > > be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - > > 64:ff9b::ffff:ffff > > > > P.S.: I thought hard about whether this should be a DISCUSS or a COMMENT > but I > > decided to go with a DISCUSS because I think it really needs to be fixed > > Hi Suresh, > > Good catch - thanks! > > I've prepared an update. I'd appreciate it if you could confirm that it > resolves your concern fully before I post it to the data tracker > though. RFC diff here: > > https://tools.ietf.org//rfcdiff?url1=draft-ietf-v6ops- > v4v6-xlat-prefix-01&url2=https://fud.no/draft-ietf- > v6ops-v4v6-xlat-prefix-02.txt > > Full new draft: https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt > > Tore > --001a1149db8cabcfe8055267b6ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tore,=C2=A0
=C2=A0 Thanks for taking = care of this quickly. I have looked at the diff and it nicely addresses my = concerns.=C2=A0

Regards= =C2=A0
Suresh=C2=A0

On Jun 20, 2017 2:24 PM, "Tore An= derson" <tore@fud.no> wrote:<= br type=3D"attribution">
* Suresh Krishnan &l= t;suresh.krishnan@gmail.com>

> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> * Section 4.2.
>
> I found the explanation to be useful but the prefix that was not selec= ted seems
> to be wrong (a prefix with non-zero bits past the prefix length does n= ot really
> make sense). The prefix that is adjacent to 64:ff9b::/96 is actually > 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the d= ocument.
> This means that most of the text that follows is incorrect. i.e. The r= ange will
> be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - > 64:ff9b::ffff:ffff
>
> P.S.: I thought hard about whether this should be a DISCUSS or a COMME= NT but I
> decided to go with a DISCUSS because I think it really needs to be fix= ed

Hi Suresh,

Good catch - thanks!

I've prepared an update. I'd appreciate it if you could confirm tha= t it
resolves your concern fully before I post it to the data tracker
though. RFC diff here:

https://tools.ietf.org//rfcd= iff?url1=3Ddraft-ietf-v6ops-v4v6-xlat-prefix-01&url2=3Dhttps:= //fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt

Full new draft: https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt

Tore
--001a1149db8cabcfe8055267b6ee-- From nobody Tue Jun 20 10:51:15 2017 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 90CB3129496 for ; Tue, 20 Jun 2017 10:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjU01Z-jhmJK for ; Tue, 20 Jun 2017 10:50:47 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837E5124D85 for ; Tue, 20 Jun 2017 10:50:46 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id g184so18868113ita.0 for ; Tue, 20 Jun 2017 10:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sN/OA4chaaDmfDQQ/de8PBSJYyc1n/UqfOa/mtGzYPQ=; b=k8xgB2rj9miiCNB5Nw8g9dOq02nVqGdi8PNDVh3URIFZcPgzSerujD+oYMoo/ed9WV gY3w5Q0rF1OPqqXh1AW8oKA8j7Skpuk7Tu7SdrgO5zE7dtzFumV5tmNPNqXw47M/JG+P taLq5e44aywTTiCgSpEwGvehqqIT0A/W9MTGVGIvwdxLKqOKcdlgPTcSKrGp1XkEaDCy A28JcciW2AkMTz69+ZaX/Hf5kJiJ/Mcrv+yS4UfmM8QdaZm/XMgictzZUDYAoYfUD/Ur w+U5od0Tjcup8+wnAnum8QCHAsCCkaUAMbLS6+7dZ4VAJPCpBUkfKCE6Xg8VYGKL5nk6 OLXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sN/OA4chaaDmfDQQ/de8PBSJYyc1n/UqfOa/mtGzYPQ=; b=oKQ/0gS/TlgdQgtE17k/qW8AzKRP2P+/G4SyY39tB0UVO750WSSdp8qd93fs8eZB2E W9LBtA43MsFZ87YM6UnT8ZtrHc81MVPr/YC0Iu14zAWtDETEk9h7na5+HWAI8mPpVMSs C5uUWcb69srpDo2fTdvGaekQRbIhkGJAqMiNkiTK+ljKhDVB43vRQH5kj7jTAs3akfRl sevnHLBipSdqxkz+swg69I6JgLsVj7qp1CYG90yo2DXGSz2yR2Qlug1k+4FgVCNNiIki uLpipQ5iZGinQPP74zTzXsyZ8sKzUfZnYRC3LBEIYgGE+q/IRbeLjsD8n1JSfYHGSNRw NCWA== X-Gm-Message-State: AKS2vOyLHc7l7Klo+rt/rFHuFvNM1vrV4CJfKm/A3p4bjCHqfoi3vY34 0jnOCAqeUMOmrvPIIqGg8zscpTUxxQ== X-Received: by 10.36.29.147 with SMTP id 141mr4631290itj.83.1497981045852; Tue, 20 Jun 2017 10:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.131 with HTTP; Tue, 20 Jun 2017 10:50:05 -0700 (PDT) In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> From: "Mukom Akong T." Date: Tue, 20 Jun 2017 21:50:05 +0400 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a1143db6a1e76fd055267e483" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:50:53 -0000 X-List-Received-Date: Tue, 20 Jun 2017 17:50:53 -0000 --001a1143db6a1e76fd055267e483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 June 2017 at 01:21, Fred Baker wrote: > IPv6 was an "advanced configuration", and the difference between > "auto-configure" and "auto-detect" was a little lost on me. > Agree and sometimes the options offered in the config screens as just bizare (e.g. Native and 6to4 as IPv6 connection types) > > So I have a question. Do we need to spell this out for CPE vendors? I hav= e > spliced together a draft on the topic. I'd welcome comments that might > improve it, especially if I have something egregiously wrong. Second, I'm > curious whether the working group thinks we need this. > > Your thoughts? > >From the document, [snip] It may offer a DNS service using a provider such as OpenDNS, Google Public DNS, Amazon Route 53, or some other such service, or relay the address of an ISP-provided DNS server. [/snip] In the context of a home, I=E2=80=99d think DNS service should be a MUST an= d here=E2=80=99s why - the typical home user is not sophisticated enough to configure anything once the provider has installed it - they currently don=E2=80=99t have to configure anything in IPv4 - making them have to configure resolvers for IPv6 puts IPv6 on a different, harder path than IPv4 and they wouldn=E2=80=99t even know whe= re to start - This is particularly important in IPv6 only where there wouldn=E2=80= =99t even be an IPv4 DNS resolver to use [snip] Similarly, the stated goal requires that upstream, the CPE must presume that it will be required to solicit and observe a Router Advertisement [RFC4861], and o learn an upstream DHCPv6 server address, o either autoconfigure [RFC4862] its upstream address or derive one using DHCPv6 [RFC3315], o potentially learn an DNS server address from an RDNSS [RFC4339] or from DHCPv6, o and allocate IPv6 /64 prefixes for each of its interior subnets using the IPv6 Prefix Options for DHCP [RFC3633]. Given that, it is in a position to offer IPv6 services in the residential/SOHO network depending on the upstream IPv6 capabilities. [/snip] What if we replace the first two bullet points with - configure its WAN interface with one or more GUA addresses using whatever mechanism it negotiates with the ISP=E2=80=99s 'serving' device= / In EXPECTED behavior, I=E2=80=99d favour a MUST for IA_PD because it presen= ts the only option for provisioning devices in the network if NAT is not an option Lastly, how is the CPE to know what to request ask =E2=80=9CLength for this= prefix in bits" with its IA-PD request? --=20 Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --001a1143db6a1e76fd055267e483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 18 June 2017 at 01:21, Fred Baker <fredbaker.ietf@gmail.com&= gt; wrote:
= IPv6 was an "advanced configuration", and the difference between = "auto-configure" and "auto-detect" was a little lost on= me.


Agree and som= etimes the options offered in the config screens as just bizare (e.g. Nativ= e and 6to4 as IPv6 connection types)

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

So I have a question. Do we need to spell this out for CPE vendors? I have = spliced together a draft on the topic. I'd welcome comments that might = improve it, especially if I have something egregiously wrong. Second, I'= ;m curious whether the working group thinks we need this.

Your thoughts?

From the d= ocument,=C2=A0

[snip]

It may offer a DNS service using a provider such as O= penDNS, Google

=C2=A0=C2=A0 Public DNS, Amazon Route 53, or some oth= er such service, or relay the

=C2=A0=C2=A0 address of an ISP-provided DNS server.

[/snip]


In the context of a home, I=E2=80=99d think DNS servi= ce should be a MUST and here=E2=80=99s why

  • the typical home user is not sophisticated enough t= o configure anything once the provider has installed it
  • they currently don=E2=80=99t have to configure anyt= hing in IPv4
  • making them have to configure resolvers for IPv6 pu= ts IPv6 on a different, harder path than IPv4 and they wouldn=E2=80=99t eve= n know where to start
  • This is particularly important in IPv6 only where t= here wouldn=E2=80=99t even be an IPv4 DNS resolver to use





[snip]

Similarly, the stated goal requires that upstream, th= e CPE must

=C2=A0=C2=A0 presume that it will be required to soli= cit and observe a Router

=C2=A0=C2=A0 Advertisement [RFC4861], and


=C2=A0=C2=A0 o=C2=A0 learn an upstream DHCPv6 server = address,

=C2=A0=C2=A0 o=C2=A0 either autoconfigure [RFC4862] i= ts upstream address or derive one

=C2=A0 =C2=A0 =C2=A0 using DHCPv6 [RFC3315],

=C2=A0=C2=A0 o=C2=A0 potentially learn an DNS server = address from an RDNSS [RFC4339] or

=C2=A0 =C2=A0 =C2=A0 from DHCPv6,

=C2=A0=C2=A0 o=C2=A0 and allocate IPv6 /64 prefixes f= or each of its interior subnets

=C2=A0 =C2=A0 =C2=A0 using the IPv6 Prefix Options fo= r DHCP [RFC3633].


=C2=A0=C2=A0 Given that, it is in a position to offer= IPv6 services in the

=C2=A0=C2=A0 residential/SOHO network depending on th= e upstream IPv6 capabilities.


[/snip]


What if we replace the first two bullet points with= =C2=A0

  • configure its WAN interface with one or more GUA ad= dresses using whatever mechanism it negotiates with the ISP=E2=80=99s '= serving' device/


In EXPECTED behavior, I=E2=80=99d favour a MUST for I= A_PD because it presents the only option for provisioning devices in the ne= twork if NAT is not an option

Lastly, how is the CPE to know what to request ask = =E2=80=9CLength for this prefix in bits" with its IA-PD request?




--

Mukom Akong T.

<= span style=3D"font-family:inherit;font-style:inherit;font-variant:inherit;l= ine-height:inherit;color:rgb(51,51,51);margin:0px;padding:0px;border:0px;ve= rtical-align:baseline">LinkedIn:Mukom=C2=A0=C2=A0| =C2=A0twitter: @perfexce= llent =C2=A0
    ----------------------------------------------= ---------------------------------------------------------------------------= -----------------
    =E2=80=9CWhen you work, you are the FLUTE through whos= e lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran--------------------------------------------------------------------------= -----------------------------------------------------------------
    =
    --001a1143db6a1e76fd055267e483-- From nobody Tue Jun 20 11:25:41 2017 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 E31F5127444 for ; Tue, 20 Jun 2017 11:25:39 -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, RP_MATCHES_RCVD=-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 7xIjDEerQR0H for ; Tue, 20 Jun 2017 11:25:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579781315D6 for ; Tue, 20 Jun 2017 11:25:18 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7936441B99 for ; Tue, 20 Jun 2017 20:25:16 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 50A0841B95; Tue, 20 Jun 2017 20:25:16 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 388DBAA0B; Tue, 20 Jun 2017 20:25:16 +0200 (CEST) Date: Tue, 20 Jun 2017 20:25:16 +0200 From: Gert Doering To: Fred Baker Cc: IPv6 Operations Message-ID: <20170620182516.GV45648@Space.Net> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:25:40 -0000 Hi, On Sat, Jun 17, 2017 at 02:21:09PM -0700, Fred Baker wrote: > So I have a question. Do we need to spell this out for CPE vendors? Yes. If it's not mandated by telcos that buy large numbers of CPE (or CERs), vendors will ship "what they think the market wants", and that currently seems to be "it will do IPv4 + NAT". German computer magazine C't tests every new router for "will it work with IPv6 on a dual-stack connection to Deutsche Telekom" - which is one of the dominant players in the market here - and half the devices fail. Today. Many years after DT started to turn on IPv6 by default on all new customer DSL lines. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jun 20 12:01:30 2017 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 42EBB131610 for ; Tue, 20 Jun 2017 12:01:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzDwwzuZLFrq for ; Tue, 20 Jun 2017 12:01:26 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D2B131629 for ; Tue, 20 Jun 2017 12:01:02 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id j53so77525173uaa.2 for ; Tue, 20 Jun 2017 12:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6p9HuzyVYU4LIKW+ofSTM5axpTQRtHaQ3zEwVbz/Sl8=; b=EN7DYzevFOZ0TC1rPwUw67Yr1YvXoSbPfjz4RQX40ho/UKqzVgm6gwj51nfixvUgvo fz35pJbKyYK9hYAIcQsk9jxJ4k6TgNnPasx+YyhPzqD/RjcFJsx4jfO+BIzrAkiOl6WX Tv6+e66k0vn6vXZMU8gD9r2be1kdi+f1gqk7SdDnoWBIvWQxxpEI1JPG2/DuxW7I3FpW vHjHaT4GpSSuwaq0vRxT8m+x7BY2KFnJL/HN6VUI2EbPIdpnx65BvDar4S2d18Lmkt5Y NJT6xGouWAbkCEBlnKT+IVB1WIgk8XXdOSkUBQEEHqfN66OQ5ZLib09lI0jsynvfnwon mf3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6p9HuzyVYU4LIKW+ofSTM5axpTQRtHaQ3zEwVbz/Sl8=; b=o08rWYOJkxJchzhb1AtMYdKLCn8yc4uVHrvLbEE4MhFBUhsweqkN3dQvSDm7IBHwvF 5tYKqMzGJQHC432HavU3ghV4HByU31VbylxK5bZhGWJsykJW5LOzhANTra/SoFBby5x2 nlfNEz4z4hQmMC09V+oI8dVN6EIOmrNukr8d7EnT6DLu2QNEoyHUQ0+ANrC21Ts3XZGn 1GhnIB/I4XBfc6Hj5QaJZJoEZKB7RSvcThhslzrJ4nWZEEu02GVS6I9FuTiYD9rQ6I7J IwLTYzyOctQjmFCMCIF0MLuupQphpF0yO1QTJZM1POB2Slgl0syssawkpJ+xjBh9qPcY XHxw== X-Gm-Message-State: AKS2vOzzXx7RJ/KyO0WTgI9d0xdcvNxr/egFdpXbD/VQa0Q1oOHf+g5C DBM2YLxb/B4aptjya/tQXmdh10RAhJzH X-Received: by 10.176.92.198 with SMTP id z6mr21344367uaf.27.1497985261482; Tue, 20 Jun 2017 12:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.165 with HTTP; Tue, 20 Jun 2017 12:00:20 -0700 (PDT) In-Reply-To: References: <149789924339.10707.17736967865508385069.idtracker@ietfa.amsl.com> <20170620105444.4d6e0330@echo.ms.redpill-linpro.com> From: Warren Kumari Date: Tue, 20 Jun 2017 15:00:20 -0400 Message-ID: To: Suresh Krishnan Cc: Tore Anderson , V6ops Chairs , IESG , IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-v4v6-xlat-prefix-01: (with DISCUSS) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:01:29 -0000 +1 on the good catch, Suresh. V6 addresses tend to be eye-charts :-) Tore, please post a new version when you get a chance. W On Tue, Jun 20, 2017 at 1:38 PM, Suresh Krishnan wrote: > Hi Tore, > Thanks for taking care of this quickly. I have looked at the diff and it > nicely addresses my concerns. > > Regards > Suresh > > On Jun 20, 2017 2:24 PM, "Tore Anderson" wrote: >> >> * Suresh Krishnan >> >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > * Section 4.2. >> > >> > I found the explanation to be useful but the prefix that was not >> > selected seems >> > to be wrong (a prefix with non-zero bits past the prefix length does not >> > really >> > make sense). The prefix that is adjacent to 64:ff9b::/96 is actually >> > 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the >> > document. >> > This means that most of the text that follows is incorrect. i.e. The >> > range will >> > be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - >> > 64:ff9b::ffff:ffff >> > >> > P.S.: I thought hard about whether this should be a DISCUSS or a COMMENT >> > but I >> > decided to go with a DISCUSS because I think it really needs to be fixed >> >> Hi Suresh, >> >> Good catch - thanks! >> >> I've prepared an update. I'd appreciate it if you could confirm that it >> resolves your concern fully before I post it to the data tracker >> though. RFC diff here: >> >> >> https://tools.ietf.org//rfcdiff?url1=draft-ietf-v6ops-v4v6-xlat-prefix-01&url2=https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt >> >> Full new draft: https://fud.no/draft-ietf-v6ops-v4v6-xlat-prefix-02.txt >> >> Tore -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jun 20 18:16:56 2017 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 BD2B0129504 for ; Tue, 20 Jun 2017 18:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 1GrV8Z6-XorN for ; Tue, 20 Jun 2017 18:16:53 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2161242EA for ; Tue, 20 Jun 2017 18:16:53 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m47so23912325iti.1 for ; Tue, 20 Jun 2017 18:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nLHufiKZmhLl0nTzRlOQ0esE7YYNdG2k0vWlmTouzUM=; b=Pg/Nn0dt70LRFgNMykuYP/pzooLnS9ldagshHam7T5NRtQA69z/txTEHt6nw6vrhCw pLKbh5eDPDKKC7SE0ld1GT26zQqeIm4CrH6X/GH5R0KKnKOhe7C2USwUn27OkoqVA8I1 G7Q6gt/5F31+weMgU1uJWwzrfoCEiIpJgNF1D36Z+5P9byXVXF0LqxHoYlx4TwyK/2FK SSCXmKgmriIOFkPhjSEkPwmYAogVHlNjFJzMahr9SyMMDwZ8DspinRBnOslZOAIAwvGt sa/ud5k/n4hrut9A+NIz6teRVAtwrYK5JYSmHVsk8eOFGkqRnd7jTc4M3d25wE5x4Z5N eI9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nLHufiKZmhLl0nTzRlOQ0esE7YYNdG2k0vWlmTouzUM=; b=GDQGWpW7ek5A1MOJVtCz8nsuV4N8OW8CEkBGwlIStcrwx5v5YQ0VzYWAuCLzP/IsDH N6ZcpAEfzT6/axGiYi7MCFKrB74yYIwJvJnKjT86lqnRx1xCgZ2me739JzWUsSypb7z4 va4EWRwIgDk8HB2f5lXSer+/WXBBdSQL7NQSLBDHNqn7wXNaN+H4uDxsDj31iZa5JPtR WEYGfFDl4AL8Mox9svQYaRhbUOci+fKMZOwQyRCPS/ltE+/crpXhnv9wuLsnkLpLW+Zz 47ZJ4Crl/k/TMtZN3/SbmohINCe7rzE2lAF+x7mEPa4JizDbYmrAr2UsnFv+PGHzfQWw 8zFw== X-Gm-Message-State: AKS2vOxg/INOH3X8h2wBAK9m5TaZ1qwsdxpMGH/cfHhgCbsVddNgHfhq lOLqIYT3thp3IEzWsetox+amfByJ7Qpd X-Received: by 10.36.28.75 with SMTP id c72mr6420501itc.26.1498007812946; Tue, 20 Jun 2017 18:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.131 with HTTP; Tue, 20 Jun 2017 18:16:12 -0700 (PDT) In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> From: "Mukom Akong T." Date: Wed, 21 Jun 2017 05:16:12 +0400 Message-ID: To: IPv6 Operations Content-Type: multipart/alternative; boundary="001a1140573c8fe99105526e1fe5" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 01:16:56 -0000 --001a1140573c8fe99105526e1fe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 June 2017 at 01:21, Fred Baker wrote: > IPv6 was an "advanced configuration", I think this is a result of the mentality (which you and John correctly identify) that "this IPv6 thing won't work out of the box like IPv4 + NAT", so let's put it under some "Advanced" menu where we can keep it disabled (or crippled) by default unless a geeker user goes in there to configure it= . If we end up with a document that makes IPV6 work out of the box, that mentality will go away and we can just have similar configuration tabs (or dialog box sections) - one for IPv4 and another nearly identical one for IPv6 --=20 Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --001a1140573c8fe99105526e1fe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    = On 18 June 2017 at 01:21, Fred Baker <fredbaker.ietf@gmail.com&= gt; wrote:
    IPv6 was an "adva= nced configuration",


    I think this is a resul= t of the mentality (which you and John correctly identify) that "this = IPv6 thing won't work out of the box like IPv4 + NAT", so let'= s put it under some "Advanced" menu where we can keep it disabled= (or crippled) by default unless a geeker user goes in there to configure i= t.

    If = we end up with a document that makes IPV6 work out of the box, that mentali= ty will go away and we can just have similar configuration tabs (or dialog = box sections) - one for IPv4 and another nearly identical one for IPv6
    <= br clear=3D"all">

    --

    Mukom Akong T.
    <= br>LinkedIn:Mukom=C2=A0=C2=A0| =C2=A0twitter: @perf= excellent =C2=A0
      --------------------------= ---------------------------------------------------------------------------= -------------------------------------
      =E2=80=9CWhen you work, you are th= e FLUTE through whose lungs the whispering of the hours turns to MUSIC"= ; - Kahlil Gibran
      ------------------------------------------------------= ---------------------------------------------------------------------------= ----------
      --001a1140573c8fe99105526e1fe5-- From nobody Tue Jun 20 22:03:32 2017 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 5BABB127136; Tue, 20 Jun 2017 22:03:24 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149802140433.15752.6030328453561847937@ietfa.amsl.com> Date: Tue, 20 Jun 2017 22:03:24 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-v4v6-xlat-prefix-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 05:03:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Local-use IPv4/IPv6 Translation Prefix Author : Tore Anderson Filename : draft-ietf-v6ops-v4v6-xlat-prefix-02.txt Pages : 7 Date : 2017-06-20 Abstract: This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-v4v6-xlat-prefix-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-v4v6-xlat-prefix-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-v4v6-xlat-prefix-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 05:52:04 2017 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 01B92129AB5; Wed, 21 Jun 2017 05:51:56 -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, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=fXAM1SxC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=adnxrsY2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juW1r8_3Gi5e; Wed, 21 Jun 2017 05:51:53 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52784129AC6; Wed, 21 Jun 2017 05:51:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B52EC20A91; Wed, 21 Jun 2017 08:51:50 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 21 Jun 2017 08:51:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=qXSd2qnOjzhTye/FZN l5dRANF6tafuFqhFjlK8fobBU=; b=fXAM1SxCv/t3N6gOOmrZktIlQ5/cNVLYZ8 i9sia5s2cJKtMxa2c0lVrQ+6gYY2xwiOGvOoFpN5+ezfuurgI3UdrGul5tfHp4u1 xwuZAHM7Rjmuv+KqVfrRzZ4K+EBBV1boqFjRDxkahL3UUr1DSDV4PIXUqUxV6nyo lOL2UpGrGH5u08wf/rluYzG4lBUgJzRfdp172V3iTB7ENK14EoJcOLdtaRWK4SaZ u/e8qagFy/qGkXjcs5ljkfE5lRjJ8grgsveeDwhkbxrdTT/TO/26mwlM93IfqZ8j yvoXNrjqvR5r8YkdB8tpCPOwfpXmRFDh9aVHDZ1yif6Q3agROe+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=qXSd2qnOjzhTye/FZNl5dRANF6tafuFqhFjlK8fobBU=; b=adnxrsY2 QiFkyL+/OnKIPImYXQplAWmq4GgGYtTLqXuBE6hGU7U8QOqJFgZoPggGhl45zbsG fEwxyMb7ZJ2EMeY1vBH6hUT92jn8TdRIdgjp5hB4lajYMSBjha0kLS//ibkv+MFT AzT5gGN9u76svL9JnUYer60a/lKxA68I5CIMXCnd7/rR9AA8EBjLO1VvlPBfIP8j TIFghQ9HEQBkIBu+nY6rrsHL3I6NYaKsPvS3DGuxH8JZdsOzHvijy1a3/3lg3KMz RK3p5FgIPsaBwn5BklUTHY0AB+nwk+38Q2oMfdpPyCEKolEpWOhW/mAKKioGLh4/ 51W7feFfTMeutA== X-ME-Sender: X-Sasl-enc: cbkgdLWq+5JtODnkjY2r6poZBU9D1ETBORxxwu4fXtsV 1498049510 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id AA3CC24631; Wed, 21 Jun 2017 08:51:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149595419894.24426.7074020393438812680@ietfa.amsl.com> Date: Wed, 21 Jun 2017 08:51:47 -0400 Cc: "gen-art >> General area reviewing team" , v6ops@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <324F5E7F-61C4-4373-97AD-CF8C04D02CE8@cooperw.in> References: <149595419894.24426.7074020393438812680@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [v6ops] [Gen-art] Genart last call review of draft-ietf-v6ops-v4v6-xlat-prefix-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 12:51:56 -0000 Roni, thanks for your review. I have entered a No Objection ballot = position on this document. Alissa > On May 28, 2017, at 2:49 AM, Roni Even wrote: >=20 > Reviewer: Roni Even > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-v6ops-v4v6-xlat-prefix-?? > Reviewer: Roni Even > Review Date: 2017-05-27 > IETF LC End Date: 2017-06-05 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > The document is ready with issues for publication as standard track > RFC > Major issues: >=20 > Minor issues: > I was wondering why this document does not update RFC6052. My > reasoning is that RFC7915 section 6 says "The translator MUST support > the stateless address mapping algorithm defined in [RFC6052], which is > the default behavior." This document suggests that the mapping in > this document can be used. >=20 > Nits/editorial comments:=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jun 21 08:53:52 2017 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 83E9412EBAB for ; Wed, 21 Jun 2017 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_3c1PjoJY8U for ; Wed, 21 Jun 2017 08:53:48 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964BB12EB6C for ; Wed, 21 Jun 2017 08:53:01 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id z22so21972871uah.1 for ; Wed, 21 Jun 2017 08:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HSpHxS9HxMPwizk2PbUZ9i4fV+CkgQ3WuI/sbkE/okc=; b=ZAerxIMvEKyYuSFU6qP2IxA1y4z6lw45c8kqIF83sMhbt0u+ZG/KdqATTFgL2oXNvh Em1CFCVMbCGtPubPy4kpX2EIUkD3+KRHQQoSaKMsmeOjvSFDxTfVi0W9nmtNLHK4IPGr 9bYkGJqVbrX1qveBFUu4BhFwy5aHWS6FJ//WBaxzRguXd2BjV+prDT9IH/CI7xAaZlz6 w6+F/2JqXazAJomIAC/GDg9ejwajkHdCPuzYcEFsoEa279khwlancj1ia8N/P4lZ3CKp 485LMeESEtkQR1/JKNsP3RKnP7l67JDF/L0xJJlIh4crrTYS8RcZKVZe1YGzOdY9UY1K 1+BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HSpHxS9HxMPwizk2PbUZ9i4fV+CkgQ3WuI/sbkE/okc=; b=dd/u9TGh8t8VWv67aNynqKdFbMe5P52h/h6B7TN4lba/ZGTA43UZbaW25V9vCCi0rs uA/ss+Q7J/HIvDEVslPwUUOQXz5kHeY2cBS0J8Ac3pFnR0gBJucSjdEjPLFUInoxDIXN IWyZMd9fJuLMi/POTRU9PqcbyJtPv2M6MxIVEea2SOE2NfwExRMEwxf1jNtslnTbuXDo YkVPhAmSrdNj1TZMfYB3caIRSEfD/YcorMYmO12u+6c1ozHQbRcQQrNWhjQe3ouvZO5p pY0z2eyF7RtvvIr35nzUg6QkLIpEYdtlDH7gNXvNw6a/cSIybF5I7aE7uRGTBPrs8RP6 0CCg== X-Gm-Message-State: AKS2vOxK/6FDmbQZcEeaNLWhZ/Vn45HIwO48L+KQbqgEWNTcKUeIMo3+ X6qcLxKApYlknPAATXgEdbbjbqGGxCrBfvY= X-Received: by 10.176.83.16 with SMTP id x16mr26435284uax.11.1498060380520; Wed, 21 Jun 2017 08:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Wed, 21 Jun 2017 08:52:39 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Thu, 22 Jun 2017 00:52:39 +0900 Message-ID: To: "STARK, BARBARA H" Cc: Fred Baker , IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c18f1acd67d7905527a5c78" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:53:50 -0000 --94eb2c18f1acd67d7905527a5c78 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 10:47 PM, STARK, BARBARA H wrote: > The BBF flow has simultaneous RS and DHCPv6 solicitation. This is at odds > with what you suggest. Simultaneous and sequential are both allowed by RFC > 7084. I realize many cable providers have expressed a preference for > sequential RS and DHCPv6 solicit, but many telcos have expressed a > preference for simultaneous. IIRC the preference for simultaneous was for telco environments where the device had to emit a packet before the network would see it. The concern was that because the device only sent three RSes on startup, if those three RSes were dropped then it would never get an RA. That concern is largely mitigated by resilient RS, which is now available on fairly recent versions of Linux (and was backported to Android kernels all the way back to 3.10, so CPE vendors can use it on older kernels too). > The BBF flow mandates requesting IA_PD, while you propose it as a very > weak MAY. Note that RFC 7084 mandates support for IA_PD. If you really want > auto config of a CE router, this is the only way I know of to do it. I > don't see that a MAY IA_PD requirement would ever result in auto > configuration. Only a MUST will. +1. An IPv6 CE router MUST do IA_PD otherwise it's not an IPv6 CE router. It does not need to do DHCPv6 address assignment on the WAN interface unless the ISP requires that for management purposes. > BBF also supports auto-configuration via the unnumbered model where the RA > does not include an Autonomous prefix and there is no offered IA_NA. RFC > 7084 allows for the unnumbered model. You make no mention of the unnumbered > model. I don't know how prevalent the unnumbered model is, though. > As a data point, I think most of the FTTH deployments here in Japan use the unnumbered model. --94eb2c18f1acd67d7905527a5c78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      On M= on, Jun 19, 2017 at 10:47 PM, STARK, BARBARA H <bs7652@att.com>= wrote:
      The BBF flow has simultaneous RS = and DHCPv6 solicitation. This is at odds with what you suggest. Simultaneou= s and sequential are both allowed by RFC 7084. I realize many cable provide= rs have expressed a preference for sequential RS and DHCPv6 solicit, but ma= ny telcos have expressed a preference for simultaneous.
      IIRC the preference for simultaneous was for telco environment= s where the device had to emit a packet before the network would see it. Th= e concern was that because the device only sent three RSes on startup, if t= hose three RSes were dropped then it would never get an RA.
      <= br>That concern is largely mitigated by resilient RS, which is now availabl= e on fairly recent versions of Linux (and was backported to Android kernels= all the way back to 3.10, so CPE vendors can use it on older kernels too).=
      =C2=A0
      The BBF flow mandates= requesting IA_PD, while you propose it as a very weak MAY. Note that RFC 7= 084 mandates support for IA_PD. If you really want auto config of a CE rout= er, this is the only way I know of to do it. I don't see that a MAY IA_= PD requirement would ever result in auto configuration. Only a MUST will.

      +1. An IPv6 CE router MUST do IA_PD otherwis= e it's not an IPv6 CE router. It does not need to do DHCPv6 address ass= ignment on the WAN interface unless the ISP requires that for management pu= rposes.
      =C2=A0
      BBF also suppo= rts auto-configuration via the unnumbered model where the RA does not inclu= de an Autonomous prefix and there is no offered IA_NA. RFC 7084 allows for = the unnumbered model. You make no mention of the unnumbered model. I don= 9;t know how prevalent the unnumbered model is, though.

      As a data point, I think most of the FTTH deployments here= in Japan use the unnumbered model.
      --94eb2c18f1acd67d7905527a5c78-- From nobody Wed Jun 21 09:06:42 2017 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 2748412EB7A for ; Wed, 21 Jun 2017 09:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qi3LkvCUwxj for ; Wed, 21 Jun 2017 09:06:39 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12693126C2F for ; Wed, 21 Jun 2017 09:06:39 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 70so51946669uau.0 for ; Wed, 21 Jun 2017 09:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YP0wRsnH/JcDQ/nZ2gm2KCbWsZk0MC6hNg7rtnOVf+o=; b=QvJLqQNeoMG+HrV4mSZtVYW74emotKorIOGbe6I4XTegx3633tqX/LpJSYdoh9/KHv wU+78XuekoHSP7AgYEIPB+1pAjGvbPJ84XLlloQm6MlyghWl5VyP8Fi1CnohxJ87kjSi SEmILrefxcHJTwqhQq+x78zdLG5mU+VPMmgsiKlvvzr+HL1X8SbjtEQMHzLYx0rhva+P 0Gomnmcq0LGqEesIv50JoKkIKqb+dJHcWKo75M8QDWYnWcgV0U/abTA3y2y6zbLEg94X pQOWFbQO5OdX/xEgrvrFIh07hNmdSZ1X8T7f0zSiXk1o2OmAfvG3vH05k0VugHTkO9+D AUzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YP0wRsnH/JcDQ/nZ2gm2KCbWsZk0MC6hNg7rtnOVf+o=; b=bygN+7liyg+zrWtE1rwwuiJEbX3BGIXmIzGho8lsvFf6bj636jCc2xhoda/WcDkStD 8gYi7kw3Qc+fg46rp+eQC5D715nrqT6Y72nMqpBCNB5qCVz5eV/vMBkULm6hc4/9qfTO IJfMTPO4lafugGEnJHbm5IB+okEnlE5BOp5gDGM73pIPSuULguAXdPaEHl7HBeRt7p91 H0GX5tWhBWOUth5E874173paBfrtlmwq0DTZroda1RZZ9AQK7/BrQAiPogDBmo0j59Rd XPTxznmnM+f4OlVc9HFC0kgswd9g+kORqhLRqysM5NwUQy0CQySpTuWXKfI9A7Y9939U /JAQ== X-Gm-Message-State: AKS2vOxT07J9zgSjbcihmolychy1V8rlTRXb2M+GPujC3jX0In7IWWuu pxxgGYZZ6rMydn9GZFv34mMlfIQf7gTZ X-Received: by 10.159.40.136 with SMTP id d8mr25952047uad.48.1498061197885; Wed, 21 Jun 2017 09:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Wed, 21 Jun 2017 09:06:17 -0700 (PDT) In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> From: Lorenzo Colitti Date: Thu, 22 Jun 2017 01:06:17 +0900 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c1247148e16bd05527a8d33" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:06:41 -0000 --94eb2c1247148e16bd05527a8d33 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 18, 2017 at 6:21 AM, Fred Baker wrote: > In discussion with John Brzozowski, he expressed a concern that CPEs don't > come "out of the box preconfigured for IPv6" as they often do for IPv4. I > had a recent experience with a new router at my home that made the point in > my mind; IPv6 was an "advanced configuration", and the difference between > "auto-configure" and "auto-detect" was a little lost on me. > > So I have a question. Do we need to spell this out for CPE vendors? I have > spliced together a draft on the topic. I'd welcome comments that might > improve it, especially if I have something egregiously wrong. Second, I'm > curious whether the working group thinks we need this. We have already spelled it out in RFC 7084, which contains more detail than this draft. I don't think this document is a good idea because it oversimplifies what an IPv6 router needs to do. Critical things that will result in outages and broken connectivity are missing, and if an implementer just read this document and built a product, it would be a broken product. Here are some examples of things that need to be done in order to provide reliable connectivity. 1. The downstream RA MUST report an MTU that's <= the MTU of the WAN interface 2. When the WAN default route is lost, the router MUST send out zero-lifetime RAs on the LAN 3. A multi-subnet router MUST send out RIOs if cross-subnet traffic is desired. 4. When the WAN is renumbered, the changes MUST be reflected in the LAN RAs. Based on very recent personal experience, these things are not only important, completely non-obvious to developers who have build an IPv4-only product (even an upmarket one), and also very hard to implement in the typical "just bolt together dnsmasq and dhcpcd" style of implementation that many of these CE routers use. The open-source ecosystem just isn't there yet. Example: dnsmasq can't do #1, #2 and #3 at all. The best advice that we can give to CE router manufacturers is: 1. Please implement IPv6. 2. Follow RFC 7084. 3. Send your box to UNH IOL (or any IPv6-ready logo test lab) repeatedly until it passes. I'm not even sure that #1 is good advice until more people have done #3 and the open source ecosystem has caught up - unless the plan is to have the routers occasionally provide broken connectivity and wallpaper over the problem with happy eyeballs (aka, kick the can down the road until such time as we need to take away IPv4). --94eb2c1247148e16bd05527a8d33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      On S= un, Jun 18, 2017 at 6:21 AM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
      In discussion with J= ohn Brzozowski, he expressed a concern that CPEs don't come "out o= f the box preconfigured for IPv6" as they often do for IPv4. I had a r= ecent experience with a new router at my home that made the point in my min= d; IPv6 was an "advanced configuration", and the difference betwe= en "auto-configure" and "auto-detect" was a little lost= on me.

      So I have a question. Do we need to spell this out for CPE vendors? I have = spliced together a draft on the topic. I'd welcome comments that might = improve it, especially if I have something egregiously wrong. Second, I'= ;m curious whether the working group thinks we need this.
      =
      We have already spelled it out in RFC 7084, which contains m= ore detail than this draft.

      I don't think this= document is a good idea because it oversimplifies what an IPv6 router need= s to do. Critical things that will result in outages and broken connectivit= y are missing, and if an implementer just read this document and built a pr= oduct, it would be a broken product. Here are some examples of things that = need to be done in order to provide reliable connectivity.
        The downstream RA MUST report an MTU that's <=3D the MTU of the WA= N interface
      1. When the WAN default route is lost, the router MUST= send out zero-lifetime RAs on the LAN
      2. A multi-subnet router MUST s= end out RIOs if cross-subnet traffic is desired.
      3. When the WAN is re= numbered, the changes MUST be reflected in the LAN RAs.
      Based= on very recent personal experience, these things are not only important, c= ompletely non-obvious to developers who have build an IPv4-only product (ev= en an upmarket one), and also very hard to implement in the typical "j= ust bolt together dnsmasq and dhcpcd" style of implementation that man= y of these CE routers use. The open-source ecosystem just isn't there y= et. Example: dnsmasq can't do #1, #2 and #3 at all.
      The best advice that we can give to CE router manufacturers is:=
      1. Please implement IPv6.
      2. Follow RFC 7084.
      3. = Send your box to UNH IOL (or any IPv6-ready logo test lab) repeatedly until= it passes.
      I'm not even sure that #1 is good advice unti= l more people have done #3 and the open source ecosystem has caught up - un= less the plan is to have the routers occasionally provide broken connectivi= ty and wallpaper over the problem with happy eyeballs (aka, kick the can do= wn the road until such time as we need to take away IPv4).
      --94eb2c1247148e16bd05527a8d33-- From nobody Wed Jun 21 10:04:34 2017 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 22E58127977 for ; Wed, 21 Jun 2017 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dMiNuxZ7Hndl for ; Wed, 21 Jun 2017 10:04:30 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54E6127876 for ; Wed, 21 Jun 2017 10:04:30 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id b6so94052698oia.1 for ; Wed, 21 Jun 2017 10:04:30 -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=4FjNz3KnoF2KQo7KyO89Y96riulWkQuPWBTQJ/WvAr4=; b=Lx0Kzecl3Z6yIK4CPdhM2hps6fDezvpKipkKaE9P6TjSzNVU7DmIcdR4vqXVHb66Sq bm871Z6klXU5zjGWy9JBbuYagUVZkhMQ0lhwVtqB79L+wn/wfiLFC6orZDSzY3+15Irk DNURtzwe3jfEYL7GV09sYEzL1qBcf3QWCyAzVX10hjfen6NLw/hR3zB+XPDESFLr161j X5SwDCJ70Y9iQoQR6XvU4b1thwi7LmEW8ehlQNKNPJnOoSqCEqWpGM2mQvE96tOZlRfn 21wjgSrPvUfMp3utQXvSpihjZQvpQ+VnWPzTDPN+eAViOiA2yGrclvYvR7XTj76FiftP Nrig== 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=4FjNz3KnoF2KQo7KyO89Y96riulWkQuPWBTQJ/WvAr4=; b=ncF+6ODONjEsY/FGh1oSovYM6Sa14T0ugXn4L7+Y3Pw8MXtD16+5buLB50rDBjKrxy AAJptB3LTG7dbKGm5AGNBJCcra21wkzS0gki+LJCTpV0Z2wCSkW5y1OYrl7oOYDEfRCs j74ShGv4w6JHw1x0WHG0+gYYPOZLYhq5gl9PyNcrgjZoTAHLGHDkfCtgmRe3rY2aGAgu IT669QULYz9MCpv1ZgzLFDLa6XTbsNrjdSr0LDz1ebt3El52Gm2dnQD2+ALAXdl8/HQ0 wnypvJm4jXUK6FQrh5TWdC3d51hPQDEnObRwUis1FQTU44/MY7+SdH+zp2D7pPxLYVft VVAA== X-Gm-Message-State: AKS2vOw/+0rVYnDaiLLO4yw+eq9fi+VPwXpU4bbLBg+NhzNrLj+JZ0hO poGG8qwKnUP4PmQXJHk= X-Received: by 10.202.191.69 with SMTP id p66mr14443881oif.38.1498064670147; Wed, 21 Jun 2017 10:04:30 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1a2e? ([2600:8802:5600:1e::1a2e]) by smtp.gmail.com with ESMTPSA id d27sm9586876ote.41.2017.06.21.10.04.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 10:04:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Wed, 21 Jun 2017 10:04:27 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <49F4588C-B142-4B63-96C1-66406020B191@gmail.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:04:33 -0000 > On Jun 21, 2017, at 9:06 AM, Lorenzo Colitti = wrote: >=20 > We have already spelled it out in RFC 7084, which contains more detail = than this draft. And there I disagree. I'm happy to add more to the draft; it's an = initial sketch. However, we have seen several comments to the effect = that 7084 and TR-124 are not resulting in product that works "out of the = box". In private email, Ole Troan suggests that I go implement something = that works "out of the box" in an open source product, perhaps OpenWRT, = and that's good. But I'll argue that before we do that, we should know = what algorithm to implement. What we have spelled out in RFC 7084, and BBF has spelled out in TR-124, = is that the product must implement a list of specifications. It does not = say that it has to work out of the box, and it doesn't say how to = accomplish that goal if it is a goal. I am starting to put together slides for IETF 99, and first making the = case. You may be interested to review them. You may find the file, in = its present state, at = https://www.dropbox.com/s/bczr0dvukxn92w5/CPE%20Router%20Auto-configuratio= n.pptx?dl=3D0. I don't want to call out a specific vendor in the case, = but it's hard to avoid the name on their screen shots, so in the slides = where I take screen shots of the configuration steps do us all a favor = and ignore the name of the vendor - it's not important. What is = important is what is required to actually turn basic IPv6 service on, in = the router in my home, which was fully IPv4+NAPT-capable when I came to = the first screen. It had to be, because it asked me to upgrade its = firmware over my existing IPv4 network, and I was logged into it using = IPv4. And what is VERY important is that the router is, as far as I can = determine, both RFC 7084 and TR-124 compliant. Being RFC 7084 and TR-124 = compliant doesn't result in it selecting correctly among SLAAC and DHCP = on the LAN and WAN interfaces when attached to a random upstream = network. Note that this note is specifically in response to a request from John = Brzozowski that the IETF make his IPv6 deployment in Comcast easier. My = comment to him on the call was that he could specify in his RFP the = things that would accomplish the role, and he wanted something in the = IETF. I have asked for his comments on this and he has not replied, so = I'm happy to be told I misunderstood him, but I understand him to be = saying that the difficulty of getting routers to actually work with his = network is something he wants to address. From nobody Wed Jun 21 10:31:25 2017 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 341BF1289B0 for ; Wed, 21 Jun 2017 10:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5CHX-VacKAAQ for ; Wed, 21 Jun 2017 10:31:21 -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 47B521201FA for ; Wed, 21 Jun 2017 10:31:21 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5LHPfT9009830; Wed, 21 Jun 2017 13:31:17 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2b7u3m5sp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 13:31:17 -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 v5LHVEAF014526; Wed, 21 Jun 2017 13:31:16 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5LHV6x4014355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 13:31:07 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 21 Jun 2017 17:30:48 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.134]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Wed, 21 Jun 2017 13:30:47 -0400 From: "STARK, BARBARA H" To: Lorenzo Colitti CC: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt Thread-Index: AQHS56+w6G39dmryMUGu+j6PZAaxUKIsJ3eQgAOZCYD//9PygA== Date: Wed, 21 Jun 2017 17:30:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DB9DF96@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DB9A42D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.238] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DB9DF96GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-21_04:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210294 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:31:23 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DB9DF96GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIEJCRiBmbG93IGhhcyBzaW11bHRhbmVvdXMgUlMgYW5kIERIQ1B2NiBzb2xpY2l0YXRpb24u IFRoaXMgaXMgYXQgb2RkcyB3aXRoIHdoYXQgeW91IHN1Z2dlc3QuIFNpbXVsdGFuZW91cyBhbmQg c2VxdWVudGlhbCBhcmUgYm90aCBhbGxvd2VkIGJ5IFJGQyA3MDg0LiBJIHJlYWxpemUgbWFueSBj YWJsZSBwcm92aWRlcnMgaGF2ZSBleHByZXNzZWQgYSBwcmVmZXJlbmNlIGZvciBzZXF1ZW50aWFs IFJTIGFuZCBESENQdjYgc29saWNpdCwgYnV0IG1hbnkgdGVsY29zIGhhdmUgZXhwcmVzc2VkIGEg cHJlZmVyZW5jZSBmb3Igc2ltdWx0YW5lb3VzLg0KDQpJSVJDIHRoZSBwcmVmZXJlbmNlIGZvciBz aW11bHRhbmVvdXMgd2FzIGZvciB0ZWxjbyBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIGRldmljZSBo YWQgdG8gZW1pdCBhIHBhY2tldCBiZWZvcmUgdGhlIG5ldHdvcmsgd291bGQgc2VlIGl0LiBUaGUg Y29uY2VybiB3YXMgdGhhdCBiZWNhdXNlIHRoZSBkZXZpY2Ugb25seSBzZW50IHRocmVlIFJTZXMg b24gc3RhcnR1cCwgaWYgdGhvc2UgdGhyZWUgUlNlcyB3ZXJlIGRyb3BwZWQgdGhlbiBpdCB3b3Vs ZCBuZXZlciBnZXQgYW4gUkEuDQoNClRoYXQgY29uY2VybiBpcyBsYXJnZWx5IG1pdGlnYXRlZCBi eSByZXNpbGllbnQgUlMsIHdoaWNoIGlzIG5vdyBhdmFpbGFibGUgb24gZmFpcmx5IHJlY2VudCB2 ZXJzaW9ucyBvZiBMaW51eCAoYW5kIHdhcyBiYWNrcG9ydGVkIHRvIEFuZHJvaWQga2VybmVscyBh bGwgdGhlIHdheSBiYWNrIHRvIDMuMTAsIHNvIENQRSB2ZW5kb3JzIGNhbiB1c2UgaXQgb24gb2xk ZXIga2VybmVscyB0b28pLg0KDQo8YmhzPiBJIHdhcyByZWNhbGxpbmcgdGhpcyBoYXBwZW5lZCBi ZWNhdXNlIGEgY2VydGFpbiBndXksIG5hbWVkIE9sZSBUcm9hbiwgY29udmluY2VkIHVzIGl0IHdh cyBtb3JlIGVmZmljaWVudCBhbmQgdGhlcmUgd2FzIG5vIHJlYXNvbiB0byB3YWl0LiBXaXRob3V0 IElBX1BELCB0aGUgY29ubmVjdGlvbiBpcyBmYWlybHkgdXNlbGVzcy4gSWYga25vdyB5b3UgbmVl ZCBpdCwgd2h5IHdhaXQuIEkgcmVjYWxsIG5vIGRpc2N1c3Npb24gb2YgdGhlIGFjY2VzcyBuZXR3 b3JrIGFyY2hpdGVjdHVyZSBwZW9wbGUgYXNraW5nIGZvciBpdCwgYW5kIGNhbuKAmXQgZmluZCB0 aGlzIG1lbnRpb25lZCBpbiBUUi0xNzcgb3IgVFItMTg3IChhY2Nlc3MgbmV0d29yayBhcmNoaXRl Y3R1cmUgSVB2NiBkb2NzKS4NCkJhcmJhcmENCg== --_000_2D09D61DDFA73D4C884805CC7865E6114DB9DF96GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEJCRiBmbG93IGhhcyBzaW11bHRhbmVvdXMgUlMgYW5k IERIQ1B2NiBzb2xpY2l0YXRpb24uIFRoaXMgaXMgYXQgb2RkcyB3aXRoIHdoYXQgeW91IHN1Z2dl c3QuIFNpbXVsdGFuZW91cyBhbmQgc2VxdWVudGlhbCBhcmUgYm90aCBhbGxvd2VkIGJ5IFJGQyA3 MDg0LiBJIHJlYWxpemUgbWFueSBjYWJsZSBwcm92aWRlcnMgaGF2ZSBleHByZXNzZWQgYSBwcmVm ZXJlbmNlIGZvciBzZXF1ZW50aWFsIFJTIGFuZA0KIERIQ1B2NiBzb2xpY2l0LCBidXQgbWFueSB0 ZWxjb3MgaGF2ZSBleHByZXNzZWQgYSBwcmVmZXJlbmNlIGZvciBzaW11bHRhbmVvdXMuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J SVJDIHRoZSBwcmVmZXJlbmNlIGZvciBzaW11bHRhbmVvdXMgd2FzIGZvciB0ZWxjbyBlbnZpcm9u bWVudHMgd2hlcmUgdGhlIGRldmljZSBoYWQgdG8gZW1pdCBhIHBhY2tldCBiZWZvcmUgdGhlIG5l dHdvcmsgd291bGQgc2VlIGl0LiBUaGUgY29uY2VybiB3YXMgdGhhdCBiZWNhdXNlIHRoZSBkZXZp Y2Ugb25seSBzZW50IHRocmVlIFJTZXMgb24gc3RhcnR1cCwgaWYgdGhvc2UgdGhyZWUgUlNlcyB3 ZXJlIGRyb3BwZWQNCiB0aGVuIGl0IHdvdWxkIG5ldmVyIGdldCBhbiBSQS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYXQgY29uY2Vy biBpcyBsYXJnZWx5IG1pdGlnYXRlZCBieSByZXNpbGllbnQgUlMsIHdoaWNoIGlzIG5vdyBhdmFp bGFibGUgb24gZmFpcmx5IHJlY2VudCB2ZXJzaW9ucyBvZiBMaW51eCAoYW5kIHdhcyBiYWNrcG9y dGVkIHRvIEFuZHJvaWQga2VybmVscyBhbGwgdGhlIHdheSBiYWNrIHRvIDMuMTAsIHNvIENQRSB2 ZW5kb3JzIGNhbiB1c2UgaXQgb24gb2xkZXIga2VybmVscyB0b28pLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7YmhzJmd0OyBJIHdhcyBy ZWNhbGxpbmcgdGhpcyBoYXBwZW5lZCBiZWNhdXNlIGEgY2VydGFpbiBndXksIG5hbWVkIE9sZSBU cm9hbiwgY29udmluY2VkIHVzIGl0IHdhcyBtb3JlIGVmZmljaWVudCBhbmQgdGhlcmUgd2FzIG5v IHJlYXNvbiB0byB3YWl0LiBXaXRob3V0IElBX1BELCB0aGUgY29ubmVjdGlvbiBpcyBmYWlybHkg dXNlbGVzcy4gSWYga25vdyB5b3UgbmVlZCBpdCwgd2h5IHdhaXQuIEkgcmVjYWxsIG5vDQogZGlz Y3Vzc2lvbiBvZiB0aGUgYWNjZXNzIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIHBlb3BsZSBhc2tpbmcg Zm9yIGl0LCBhbmQgY2Fu4oCZdCBmaW5kIHRoaXMgbWVudGlvbmVkIGluIFRSLTE3NyBvciBUUi0x ODcgKGFjY2VzcyBuZXR3b3JrIGFyY2hpdGVjdHVyZSBJUHY2IGRvY3MpLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJh cmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DB9DF96GAALPA1MSGUSRBF_-- From nobody Wed Jun 21 11:17:02 2017 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 7F1A412943B; Wed, 21 Jun 2017 11:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, Fred Baker , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149806901451.15829.1548266429495973724.idtracker@ietfa.amsl.com> Date: Wed, 21 Jun 2017 11:16:54 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-v4v6-xlat-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:16:55 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-v4v6-xlat-prefix-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for rapidly addressing my DISCUSS point. From nobody Wed Jun 21 15:17:41 2017 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 9FBFF128B37; Wed, 21 Jun 2017 15:17:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, Fred Baker , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149808345864.30641.6438936935007419889.idtracker@ietfa.amsl.com> Date: Wed, 21 Jun 2017 15:17:38 -0700 Archived-At: Subject: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-v4v6-xlat-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:17:38 -0000 Adam Roach has entered the following ballot position for draft-ietf-v6ops-v4v6-xlat-prefix-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like Suresh, I really appreciated the discussion of rationale in section 4. There is one possibility that I'm surprised is not discussed; namely, allocating 64::ff9b::/48 for this purpose, with the subset of addresses in 64::ff9b::/96 being *additionally* subject to the restrictions of RFC 6052. This would seem to have the advantages of: - Complete address adjacency without the disadvantages of using 64:ff9a:ffff::/48 - Sharing an even longer prefix (48 bits) than the 31-bit and 47-bit prefixes discussed in the document - Eliminating the caveat described in the final paragraph of section 5 entirely This is obvious enough that it had to be considered and rejected by the WG; including the rationale for rejecting it seems appropriate here. From nobody Fri Jun 23 17:13:13 2017 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 4A6A112EA8C; Fri, 23 Jun 2017 17:07:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: v6ops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283029.7840.10547505495366950632.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:10 -0700 Archived-At: Subject: [v6ops] v6ops - Requested sessions have been scheduled for IETF 99 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:11 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00:00) Tuesday, Morning Session I 0930-1200 Room Name: Congress Hall II size: 350 --------------------------------------------- v6ops Session 2 (2:00:00) Thursday, Afternoon Session I 1330-1530 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima isis Second Priority: bmwg opsec intarea mtgvenue sunset4 Third Priority: dnsop tsvwg People who must be present: Fred Baker Joel Jaeggli Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: Please meet on Monday-Wednesday --------------------------------------------------------- From nobody Mon Jun 26 05:12:25 2017 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 90481129B2F; Mon, 26 Jun 2017 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAPqtudy0M7N; Mon, 26 Jun 2017 05:12:15 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10121.outbound.protection.outlook.com [40.107.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311DD1294C8; Mon, 26 Jun 2017 05:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=036SGzGaKVQKSg0zb9KX2E+EVg4IImvuPqeHyuj52aI=; b=FkUTKR7YcNwFWgQVCJIpmorz1IbiIVTDbHr3luWYsTbrIssSeuJLRezI5769daggCz1dkiXXZkl2AWowb8oviWHbNlggwZMaVyj8ejtkkDvp5V6ZwsZO7p7LIi/MMCSOhPlmpU6fUdTDgifD368yUAF4bSNbMkBbYGk8yMsMzA4= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1649.eurprd07.prod.outlook.com (10.166.132.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Mon, 26 Jun 2017 12:12:12 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::d832:c9c1:9dfa:23af]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::d832:c9c1:9dfa:23af%13]) with mapi id 15.01.1220.009; Mon, 26 Jun 2017 12:12:12 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Brian E Carpenter , "ietf@ietf.org" CC: "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice Thread-Index: AQHS7nVwy1Lf3818YU+QsvEn2zlIIw== Date: Mon, 26 Jun 2017 12:12:12 +0000 Message-ID: <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com> References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [212.88.252.216] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1649; 7:iSAoG0FJQSnULe603OP03OxYOXyZxFCXzThcr5osjqFkXYkcwmnWg82rn/ZqLnwEp+SURyFJ+9In6QhlVDZlz/HW/bfYuobQUgKQxi8mJeUPHrowNBbfRz9IDfoUzIWzqd2lRfFT3Sq0otFWdWM5vYCnHtZBYZGiH/ppMBMoi7fqPakaWwFNtuz4x5nRtQD6KwIW3wg8iRgJpB+Q98eBNe2ZtbAmuNmKDmJqbA4QDLA27pyU57dbaRlqvjhPblUnEy9n0q7cp2nNdlHNqI0Z5QObUvsHj82iZMxvZAXzuc6umqAD7LOK4PPOHRM7LfxYPk4LQ+SNeYx0nMe7+EFHrRr2lZD+i47mbwA7pm3cGPwIJ+tXkFci8QRYyf45mCOATWoX4hk84fc5NxgchwacLlIcmUC1j4PSQ6aP7vKwOuoGkld4kB9KwgnB2MkoIYOKzWCiJFOQFyQzCgrPKUTZqKqPNR35L0gKlr9vj6nKjP1JcNZv8O0nFnkmhVUoEdGk8wu1Hwepg2+WBssp8e0Ntsp7QZ0aK86xbWQ2mSwCk3igWACZHbCklGYFx9nylLbbS/fELShIMFT3HwpPy/i+XO/EY6p0cqFJCHnQQaRGbdAvPA0MdxnCywz5TZEHRCJaaY4iQn3fF049qM6v0dw+0BC77S24n6nHNGP3g6teKF89eJN2mzpvWkfmPF1hltXGT14mNnuG/YuW0D8QClHMY4FzUvzKZyjedvcJbeLXlquI4407kGbP9CaGgfR5J2hnHNBWzTa0cvmls8ovu2A/sYle5TGcaX/GKa5Lu6kszjs= x-ms-office365-filtering-correlation-id: 597fb72f-1f6d-41b1-dc2b-08d4bc8c937b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:AM4PR07MB1649; x-ms-traffictypediagnostic: AM4PR07MB1649: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(120809045254105)(236129657087228); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1649; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1649; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39860400002)(39410400002)(39400400002)(24454002)(51914003)(230783001)(101416001)(86362001)(2906002)(33656002)(3280700002)(3660700001)(76176999)(50986999)(54356999)(2950100002)(14454004)(305945005)(39060400002)(38730400002)(53546010)(81166006)(8676002)(66066001)(25786009)(6116002)(102836003)(3846002)(5250100002)(2501003)(189998001)(36756003)(8936002)(6512007)(53936002)(966005)(6306002)(99286003)(54906002)(7736002)(478600001)(229853002)(2900100001)(4326008)(5660300001)(6246003)(83716003)(6436002)(6486002)(6506006)(82746002)(222643001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1649; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <349B792331A9624391F20B0EDB78CAAD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 12:12:12.0175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1649 Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 12:12:18 -0000 SGkgQnJpYW4sIA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuDQoNCkkgbW9kaWZpZWQgdGhlIHJl ZmVyZW5jZSB0byAvNjQgSVB2NiBwcmVmaXggbGVuZ3RoIGFuZCBzdWdnZXN0ZWQgaW5zdGVhZCAN CmNvbnNpc3RlbmN5IHdpdGggUkZDNzYwOCBhbmQgdGhhdCBjdXJyZW50bHkgdGhpcyBsaWtlbHkg bWVhbnMgYSAvNjQgaW4gdGhlIC0wNCB2ZXJzaW9uLg0KDQpBbGwgdGhlIGJlc3QsDQpHLw0KDQpP biAyNi8wNS8yMDE3LCAyMjoyNCwgIkJyaWFuIEUgQ2FycGVudGVyIiA8YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgc2hvdWxkIGhhdmUg bm90aWNlZCB0aGlzIGR1cmluZyB0aGUgdjZvcHMgZGlzY3Vzc2lvbnMsIGJ1dCBJIGRpZG4ndCwN CiAgICBzb3JyeS4NCiAgICANCiAgICBUaGlzIGRyYWZ0IGNpdGVzIFJGQzQ4NjIgKFNMQUFDKSBh bmQgbWVudGlvbnMgUm91dGVyIEFkdmVydGlzZW1lbnRzDQogICAgKHdpdGhvdXQgYWxzbyBjaXRp bmcgUkZDNDg2MSwgd2hpY2ggaXMgcG9zc2libHkgYSBtaXN0YWtlKS4gVGhvc2UNCiAgICBkb2N1 bWVudHMgZG8gbm90IHNwZWNpZnkgdGhlIHN1Ym5ldCBwcmVmaXggbGVuZ3RoLiBTbyB0aGUgZHJh ZnQNCiAgICBzaG91bGRuJ3QgYXNzdW1lIGEgcGFydGljdWxhciBwcmVmaXggbGVuZ3RoIGVpdGhl ci4gV2UgYWxsIGtub3cgdGhhdA0KICAgIGl0J3MgdXN1YWxseSA2NCB0b2RheSwgYnV0IHRoYXQg ZG9lc24ndCBhZmZlY3QgdGhlIGFyZ3VtZW50IG1hZGUgYnkNCiAgICB0aGUgZHJhZnQuIFdlIG5l ZWQgY29uc2lzdGVuY3kgd2l0aCBSRkMgNzYwOCAoQkNQIDE5OCkuDQogICAgDQogICAgUmVnYXJk cw0KICAgICAgIEJyaWFuIENhcnBlbnRlcg0KICAgIA0KICAgIE9uIDI0LzA1LzIwMTcgMDc6NDEs IFRoZSBJRVNHIHdyb3RlOg0KICAgID4gDQogICAgPiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSBy ZXF1ZXN0IGZyb20gdGhlIElQdjYgT3BlcmF0aW9ucyBXRyAodjZvcHMpDQogICAgPiB0byBjb25z aWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50OiAtICdVbmlxdWUgSVB2NiBQcmVmaXggUGVyIEhv c3QnIA0KICAgID4gPGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTAzLnR4dD4gYXMgQmVzdA0KICAgID4gQ3VycmVudCBQcmFjdGljZQ0KICAgID4gDQogICAgPiBU aGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBh bmQNCiAgICA+IHNvbGljaXRzIGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ug c2VuZCBzdWJzdGFudGl2ZQ0KICAgID4gY29tbWVudHMgdG8gdGhlIGlldGZAaWV0Zi5vcmcgbWFp bGluZyBsaXN0cyBieSAyMDE3LTA2LTA2Lg0KICAgID4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMg bWF5IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbg0KICAgID4gZWl0aGVyIGNh c2UsIHBsZWFzZSByZXRhaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFs bG93DQogICAgPiBhdXRvbWF0ZWQgc29ydGluZy4NCiAgICA+IA0KICAgID4gQWJzdHJhY3QNCiAg ICA+IA0KICAgID4gDQogICAgPiBJbiBzb21lIElQdjYgZW52aXJvbm1lbnRzLCB0aGUgbmVlZCBo YXMgYXJpc2VuIGZvciBob3N0cyB0byBiZSBhYmxlIA0KICAgID4gdG8gdXRpbGl6ZSBhIHVuaXF1 ZSBJUHY2IHByZWZpeCwgZXZlbiB0aG91Z2ggdGhlIGxpbmsgb3IgbWVkaWEgbWF5DQogICAgPiBi ZSBzaGFyZWQuICBUeXBpY2FsbHkgaG9zdHMgKHN1YnNjcmliZXJzKSBvbiBhIHNoYXJlZCBuZXR3 b3JrLA0KICAgID4gZWl0aGVyIHdpcmVkIG9yIHdpcmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBX aUZpLCBldGMuLCB3aWxsIGFjcXVpcmUNCiAgICA+IHVuaXF1ZSBJUHY2IGFkZHJlc3NlcyBmcm9t IGEgY29tbW9uIElQdjYgcHJlZml4IHRoYXQgaXMgYWxsb2NhdGVkIG9yIA0KICAgID4gYXNzaWdu ZWQgZm9yIHVzZSBvbiBhIHNwZWNpZmljIGxpbmsuDQogICAgPiANCiAgICA+IEluIG1vc3QgZGVw bG95bWVudHMgdG9kYXksIElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBzaW5nbGUNCiAg ICA+IElQdjYgcHJlZml4IG9uIGEgc2hhcmVkIG5ldHdvcmsgaXMgZG9uZSBieSBlaXRoZXIgdXNp bmcgSVB2Ng0KICAgID4gc3RhdGVsZXNzIGFkZHJlc3MgYXV0by1jb25maWd1cmF0aW9uIChTTEFB QykgYW5kL29yIHN0YXRlZnVsIERIQ1B2Ni4NCiAgICA+IFdoaWxlIHRoaXMgaXMgc3RpbGwgdmlh YmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCwgdGhlcmUgYXJlIHNvbWUNCiAgICA+IGxhcmdl IHNjYWxlIGVudmlyb25tZW50cyB3aGVyZSB0aGlzIGNvbmNlcHQgaW50cm9kdWNlcyBzaWduaWZp Y2FudCANCiAgICA+IHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywgc3Bl Y2lmaWNhbGx5IHJlbGF0ZWQgdG8NCiAgICA+IElQdjYgcm91dGVyIGFuZCBuZWlnaGJvciBkaXNj b3ZlcnkuDQogICAgPiANCiAgICA+IFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2gg dXRpbGlzaW5nIGV4aXN0aW5nIElQdjYgcHJvdG9jb2xzIA0KICAgID4gdG8gYWxsb3cgaG9zdHMg dG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXggKGluc3RlYWQgb2YgYSANCiAgICA+ IHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZCBJUHY2IHByZWZpeCkuICBCZW5lZml0 cyBvZiB1bmlxdWUgDQogICAgPiBJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIElQdjYgYWRkcmVz cyBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIA0KICAgID4gaW5jbHVkZSBpbXByb3ZlZCBzdWJz Y3JpYmVyIGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlciANCiAgICA+IG1hbmFnZW1l bnQuDQogICAgPiANCiAgICA+IA0KICAgID4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYSAN CiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Lw0KICAgID4NCiAgICA+ICBJRVNHIGRpc2N1c3Np b24gY2FuIGJlIHRyYWNrZWQgdmlhIA0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvYmFsbG90 Lw0KICAgID4NCiAgICA+IA0KICAgID4gDQogICAgPiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUg YmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQogICAgPiANCiAgICA+IA0KICAg ID4gVGhlIGRvY3VtZW50IGNvbnRhaW5zIHRoZXNlIG5vcm1hdGl2ZSBkb3dud2FyZCByZWZlcmVu Y2VzLiBTZWUgUkZDDQogICAgPiAzOTY3IGZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uOiByZmM2 MTA2OiBJUHY2IFJvdXRlciBBZHZlcnRpc2VtZW50DQogICAgPiBPcHRpb25zIGZvciBETlMgQ29u ZmlndXJhdGlvbiAoUHJvcG9zZWQgU3RhbmRhcmQgLSBJRVRGIHN0cmVhbSkgDQogICAgPiByZmM0 OTQxOiBQcml2YWN5IEV4dGVuc2lvbnMgZm9yIFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9jb25maWd1 cmF0aW9uDQogICAgPiBpbiBJUHY2IChEcmFmdCBTdGFuZGFyZCAtIElFVEYgc3RyZWFtKSByZmM0 ODYyOiBJUHY2IFN0YXRlbGVzcw0KICAgID4gQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiAoRHJh ZnQgU3RhbmRhcmQgLSBJRVRGIHN0cmVhbSkgcmZjMzMxNToNCiAgICA+IER5bmFtaWMgSG9zdCBD b25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IChESENQdjYpIChQcm9wb3NlZA0KICAgID4g U3RhbmRhcmQgLSBJRVRGIHN0cmVhbSkNCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxp bmcgbGlzdCANCiAgICA+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMgLg0KICAgID4gDQogICAgDQoNCg== From nobody Mon Jun 26 06:26:02 2017 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 C3ADD129B73; Mon, 26 Jun 2017 06:25:53 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149848355375.31706.3498880373111717374@ietfa.amsl.com> Date: Mon, 26 Jun 2017 06:25:53 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 13:25:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-04.txt Pages : 8 Date : 2017-06-26 Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 26 06:34:38 2017 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 ABEC0129B8D; Mon, 26 Jun 2017 06:34:30 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149848407068.31805.10927161382453492195@ietfa.amsl.com> Date: Mon, 26 Jun 2017 06:34:30 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 13:34:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt Pages : 8 Date : 2017-06-26 Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-05 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-05 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 Jun 26 06:37:55 2017 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 D4C95129BF0 for ; Mon, 26 Jun 2017 06:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6KP1-0t3_Dg for ; Mon, 26 Jun 2017 06:37:41 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 A4D1F129BA4 for ; Mon, 26 Jun 2017 06:37:35 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r126so881019vkg.0 for ; Mon, 26 Jun 2017 06:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uMmfDXX+GQRRHsSEilXlWx3l6NC3X6IIMG192ih7+vo=; b=UTwWPFdOr2o+Kh+qfSGZSm2CDP5VdgRMI4Jm1DUC7TYGmUU7QqxMvE9EA4G4Lr/uhj x5+NJHq90eJX+DAB8xSscbzc6GW+ds7CO1PWLMFmZLDOsIZkraZ5IJbMr/BjeBedQ4Y5 cD3KCBMk5QEXHaL2trEaj9qXM2uRAHR7JhMSxu8lvTg0hr2KyXKkHJ9KDI9dGeFdyOyp 5kc9iXzjEMefBWVdLu2Z+19xlcEvHk737dBYe8FUtLBdi5FXh3OCe4J1PWGknFbauYRY AhRChCbmIjU1Yt/3UPdZo0mIXN6mKdt6leWwFsTEqIfR/LkTz1/lBFSKRQzItHcQjgaJ OCgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uMmfDXX+GQRRHsSEilXlWx3l6NC3X6IIMG192ih7+vo=; b=B5/tV8GpEOm/Nzr0+pyfhW/px5XRwiR+1mmcuQmQ7DSkj5Wt9dymfmnkHLQ9iui9iG M5cDKy/axVhVYf91hQjpC+WjEUvCH9rLshESapP/dVvAkn6Hh6EL5rHA4z7XJ0D28t99 uD5zcSfk7tc8LFFOP5RzN3E4nrI+Cmtglcu/nxOjfGrQGoFV0JyUQMCG8jp+l9nJKnfu s632sr8fUWvqztxmh0HgCzd0ZbM6HGypunYhMuxqtJVtwFQVm3mMKyplEK1MTdBfE4/W OuvIUwpNpBZNFel7XqSN74HqxXco/thZWOVT8UR+9jDumKPth9yJXXPOTmxqv0kFWvlJ yVRg== X-Gm-Message-State: AKS2vOz6iD2SYMQst9AidCaFEvvOt2BuqWE7zlCcWj9UkmMB3YSeEtt7 2WaitdVv5Y6iun8eybgcc4qZ+EfVvCSk X-Received: by 10.31.170.22 with SMTP id t22mr132429vke.100.1498484254403; Mon, 26 Jun 2017 06:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Mon, 26 Jun 2017 06:37:13 -0700 (PDT) In-Reply-To: <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com> References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com> From: Lorenzo Colitti Date: Mon, 26 Jun 2017 22:37:13 +0900 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: Brian E Carpenter , "ietf@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a11415c3eaff5110552dd0d16" Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 13:37:50 -0000 --001a11415c3eaff5110552dd0d16 Content-Type: text/plain; charset="UTF-8" Please don't cite RFC 7608. It has nothing to do with IP addressing, only forwarding, and the topic here is host addressing. On Mon, Jun 26, 2017 at 9:12 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > Hi Brian, > > Thanks for the review. > > I modified the reference to /64 IPv6 prefix length and suggested instead > consistency with RFC7608 and that currently this likely means a /64 in the > -04 version. > > All the best, > G/ > > On 26/05/2017, 22:24, "Brian E Carpenter" > wrote: > > Hi, > > I should have noticed this during the v6ops discussions, but I didn't, > sorry. > > This draft cites RFC4862 (SLAAC) and mentions Router Advertisements > (without also citing RFC4861, which is possibly a mistake). Those > documents do not specify the subnet prefix length. So the draft > shouldn't assume a particular prefix length either. We all know that > it's usually 64 today, but that doesn't affect the argument made by > the draft. We need consistency with RFC 7608 (BCP 198). > > Regards > Brian Carpenter > > On 24/05/2017 07:41, The IESG wrote: > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > > to consider the following document: - 'Unique IPv6 Prefix Per Host' > > as Best > > Current Practice > > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send substantive > > comments to the ietf@ietf.org mailing lists by 2017-06-06. > > Exceptionally, comments may be sent to iesg@ietf.org instead. In > > either case, please retain the beginning of the Subject line to allow > > automated sorting. > > > > Abstract > > > > > > In some IPv6 environments, the need has arisen for hosts to be able > > to utilize a unique IPv6 prefix, even though the link or media may > > be shared. Typically hosts (subscribers) on a shared network, > > either wired or wireless, such as Ethernet, WiFi, etc., will acquire > > unique IPv6 addresses from a common IPv6 prefix that is allocated or > > assigned for use on a specific link. > > > > In most deployments today, IPv6 address assignment from a single > > IPv6 prefix on a shared network is done by either using IPv6 > > stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. > > While this is still viable and operates as designed, there are some > > large scale environments where this concept introduces significant > > performance challenges and implications, specifically related to > > IPv6 router and neighbor discovery. > > > > This document outlines an approach utilising existing IPv6 protocols > > to allow hosts to be assigned a unique IPv6 prefix (instead of a > > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > > IPv6 prefix over a unique IPv6 address from the service provider > > include improved subscriber isolation and enhanced subscriber > > management. > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv > 6-prefix-per-host/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv > 6-prefix-per-host/ballot/ > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > The document contains these normative downward references. See RFC > > 3967 for additional information: rfc6106: IPv6 Router Advertisement > > Options for DNS Configuration (Proposed Standard - IETF stream) > > rfc4941: Privacy Extensions for Stateless Address Autoconfiguration > > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless > > Address Autoconfiguration (Draft Standard - IETF stream) rfc3315: > > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed > > Standard - IETF stream) > > > > > > > > _______________________________________________ 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 > --001a11415c3eaff5110552dd0d16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Please don't cite RFC 7608. It has nothing to do with = IP addressing, only forwarding, and the topic here is host addressing.
      =

      On Mon, Jun 26, 2= 017 at 9:12 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) <gun= ter.van_de_velde@nokia.com> wrote:
      Hi Brian,

      Thanks for the review.

      I modified the reference to /64 IPv6 prefix length and suggested instead consistency with RFC7608 and that currently this likely means a /64 in the = -04 version.

      All the best,
      G/

      On 26/05/2017, 22:24, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

      =C2=A0 =C2=A0 Hi,

      =C2=A0 =C2=A0 I should have noticed this during the v6ops discussions, but = I didn't,
      =C2=A0 =C2=A0 sorry.

      =C2=A0 =C2=A0 This draft cites RFC4862 (SLAAC) and mentions Router Advertis= ements
      =C2=A0 =C2=A0 (without also citing RFC4861, which is possibly a mistake). T= hose
      =C2=A0 =C2=A0 documents do not specify the subnet prefix length. So the dra= ft
      =C2=A0 =C2=A0 shouldn't assume a particular prefix length either. We al= l know that
      =C2=A0 =C2=A0 it's usually 64 today, but that doesn't affect the ar= gument made by
      =C2=A0 =C2=A0 the draft. We need consistency with RFC 7608 (BCP 198).

      =C2=A0 =C2=A0 Regards
      =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian Carpenter

      =C2=A0 =C2=A0 On 24/05/2017 07:41, The IESG wrote:
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > The IESG has received a request from the IPv6 Operations= WG (v6ops)
      =C2=A0 =C2=A0 > to consider the following document: - 'Unique IPv6 P= refix Per Host'
      =C2=A0 =C2=A0 > <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03= .txt> as Best
      =C2=A0 =C2=A0 > Current Practice
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > The IESG plans to make a decision in the next few weeks,= and
      =C2=A0 =C2=A0 > solicits final comments on this action. Please send subs= tantive
      =C2=A0 =C2=A0 > comments to the       ietf@ietf.org mailing lists by 2017-06-06.
      =C2=A0 =C2=A0 > Exceptionally, comments may be sent to iesg@ietf.org instead. In
      =C2=A0 =C2=A0 > either case, please retain the beginning of the Subject = line to allow
      =C2=A0 =C2=A0 > automated sorting.
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > Abstract
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > In some IPv6 environments, the need has arisen for hosts= to be able
      =C2=A0 =C2=A0 > to utilize a unique IPv6 prefix, even though the link or= media may
      =C2=A0 =C2=A0 > be shared.=C2=A0 Typically hosts (subscribers) on a shar= ed network,
      =C2=A0 =C2=A0 > either wired or wireless, such as Ethernet, WiFi, etc., = will acquire
      =C2=A0 =C2=A0 > unique IPv6 addresses from a common IPv6 prefix that is = allocated or
      =C2=A0 =C2=A0 > assigned for use on a specific link.
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > In most deployments today, IPv6 address assignment from = a single
      =C2=A0 =C2=A0 > IPv6 prefix on a shared network is done by either using = IPv6
      =C2=A0 =C2=A0 > stateless address auto-configuration (SLAAC) and/or stat= eful DHCPv6.
      =C2=A0 =C2=A0 > While this is still viable and operates as designed, the= re are some
      =C2=A0 =C2=A0 > large scale environments where this concept introduces s= ignificant
      =C2=A0 =C2=A0 > performance challenges and implications, specifically re= lated to
      =C2=A0 =C2=A0 > IPv6 router and neighbor discovery.
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > This document outlines an approach utilising existing IP= v6 protocols
      =C2=A0 =C2=A0 > to allow hosts to be assigned a unique IPv6 prefix (inst= ead of a
      =C2=A0 =C2=A0 > unique IPv6 address from a shared IPv6 prefix).=C2=A0 Be= nefits of unique
      =C2=A0 =C2=A0 > IPv6 prefix over a unique IPv6 address from the service = provider
      =C2=A0 =C2=A0 > include improved subscriber isolation and enhanced subsc= riber
      =C2=A0 =C2=A0 > management.
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > The file can be obtained via
      =C2=A0 =C2=A0 > htt= ps://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix= -per-host/
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >=C2=A0 IESG discussion can be tracked via
      =C2=A0 =C2=A0 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6= -prefix-per-host/ballot/
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > No IPR declarations have been submitted directly on this= I-D.
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > The document contains these normative downward reference= s. See RFC
      =C2=A0 =C2=A0 > 3967 for additional information: rfc6106: IPv6 Router Ad= vertisement
      =C2=A0 =C2=A0 > Options for DNS Configuration (Proposed Standard - IETF = stream)
      =C2=A0 =C2=A0 > rfc4941: Privacy Extensions for Stateless Address Autoco= nfiguration
      =C2=A0 =C2=A0 > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Sta= teless
      =C2=A0 =C2=A0 > Address Autoconfiguration (Draft Standard - IETF stream)= rfc3315:
      =C2=A0 =C2=A0 > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (P= roposed
      =C2=A0 =C2=A0 > Standard - IETF stream)
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 >
      =C2=A0 =C2=A0 > _______________________________________________ v6o= ps mailing list
      =C2=A0 =C2=A0 > v6op= s@ietf.org https://www.ietf.org/mailman/listinf= o/v6ops .
      =C2=A0 =C2=A0 >


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

      --001a11415c3eaff5110552dd0d16-- From nobody Mon Jun 26 07:05:22 2017 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 395EB12EA67 for ; Mon, 26 Jun 2017 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvPaEvNWZox7 for ; Mon, 26 Jun 2017 07:05:17 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403D112EA64 for ; Mon, 26 Jun 2017 07:05:17 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 191so1227767vko.2 for ; Mon, 26 Jun 2017 07:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h8v6mZm7xMTSp5hlAJxnqOBkztIQRPCcQHCIIVm0d1c=; b=ucKNzoZc6mKmF2ZwBJeQ8K8tI5Ody658akh+Kw4OzJYmTjRhDQ0uepoewJ/PKMzHZe bg5HCmXvtVgnuVSEV9ZU+EdOtXieXPNSHufOjq40Swq/+7tg4i1Z1PecbBLk0nzSnT0o NWqmPFNeesSgr214RoucW7FvewQkheyP1b9+mhEcR0kwjpdl3ZmL4ULu58jqibODAqeB 4Wyb+Xgk3pdR+7nc3wQELb48Jq/QdqqQIIaA5Qbpzwm7itaRY4nA0ckGCKOii24zZhA4 eOZul0pXFczqFkcp0kUjrE6LTrmuJtxUBFpY2RnaKWV2C1yB8cfP6zhBKEy0DQGsjAKG KUHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h8v6mZm7xMTSp5hlAJxnqOBkztIQRPCcQHCIIVm0d1c=; b=myZyfy+MPV7Y2VEYEvNPZ7crCmZXnV6VPx38Ezl0B3tXDQOi7cBVZvKro2P0C0HPFi OUdY6q6JiPCVRJ9a2YsL7Nj1S5RReSi3os+9efUBGdYMWX6Rd57t7+IeEg0MPnzNCIuN 7lO509V7iiDzEyZ75kQxZfU9Er7z3gUGD/URkPPfDyKNakqMx6COglZeZFSTADmHICZu 40tcfd+J82D06miUvjPTmuKGxCREKZxNeWLAuU4xsLcpCdfJtEulBM6FYi6oWrr8HW7Z AUmgL7YLX/qpLfbEMHbe5ArscdbDvMt7GJQkLz8ZVk+lJKX1Aiawi1QOClV7ohw+ohl/ d13w== X-Gm-Message-State: AKS2vOy/EAdVJenlqsk20Woxfou3IAOYHOhMuIrvZppfMdJEGMmOqCZB 69YqSmx2iy0pq75u/DzY1/01iagFcwJC X-Received: by 10.31.210.1 with SMTP id j1mr187442vkg.144.1498485915813; Mon, 26 Jun 2017 07:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Mon, 26 Jun 2017 07:04:55 -0700 (PDT) In-Reply-To: <149848407068.31805.10927161382453492195@ietfa.amsl.com> References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 26 Jun 2017 23:04:55 +0900 Message-ID: To: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114bc9e2b73d740552dd70a2" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:05:20 -0000 --001a114bc9e2b73d740552dd70a2 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 26, 2017 at 10:34 PM, wrote: > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-p > refix-per-host-05.txt > Pages : 8 > Date : 2017-06-26 > Authors, here are some comments that I think should be addressed before publication: 1. The document text says it's a best current practice. ("The Best Current Practice documented in this note..."), but the header says the intended status is informational. 2. The suggested router advertisement interval of 300s causes almost double the number of RA recommendations for battery-powered hosts laid down in RFC 7772. This should be explained somehow (one example way be to say that the draft is not primarily intended to recommend practices for battery-powered hosts; another would be to say that it's a trade-off between battery life and some other desirable property). 3. The text "(1) a Unique IPv6 prefix (most likely a /64 prefix consistent with RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the behaviour of forwarding equipment, and this draft is about prefixes assigned to hosts. I'd just say "/64 prefix". If you need a justification for /64 (even though the document doesn't justify the other parameters either, such as 3600 for the prefix lifetime or 300 for the RA interval), then you can say that SLAAC is not defined for any other size, and per RFC 7421, prefixes longer than 64 bits are outside the current IPv6 specifications. 4. In section 4, the draft should say that the prefix should be global, since the document uses the terms "UE" "subscriber" and "WiFi hotspot" which strongly imply Internet access. 5. In section 4, the text should not use the terms "/128 unique address" or "assign itself a 128 bit IPv6 address". The whole point of assigning a /64 to a host is so that it can use as many addresses as it wants/needs without impacting the network. This is confusing because just a few lines down the draft says that the host needs to do DAD "for each address". Also a minor suggestion: in section 5, when discussing the inactivity timer, the draft could say that the inactivity timer is one approach, but the network could also use other signals to detect that a host has gone away, for example cues from link-layers such as 802.11 that have clear disconnection signals. Cheers, Lorenzo --001a114bc9e2b73d740552dd70a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      On M= on, Jun 26, 2017 at 10:34 PM, <internet-drafts@ietf.org> wrote:
      =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Unique IP= v6 Prefix Per Host
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: John= Jason Brzozowski
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Gunter Van De Velde
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-05.txt
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-26

      Authors,

      here are some comments that I think should be addressed before publi= cation:
      1. The document text says it's a best current pr= actice. ("The Best Current Practice documented in this note..."),= but the header says the intended status is informational.
      2. The sugg= ested router advertisement interval of 300s causes almost double the number= of RA recommendations for battery-powered hosts laid down in RFC 7772. Thi= s should be explained somehow (one example way be to say that the draft is = not primarily intended to recommend practices for battery-powered hosts; an= other would be to say that it's a trade-off between battery life and so= me other desirable property).
      3. The text "(1) a Unique IPv6 pref= ix (most likely a /64 prefix consistent with RFC7608 [RFC7608])" is a = non-sequitur. RFC 7608 specifies the behaviour of forwarding equipment, and= this draft is about prefixes assigned to hosts. I'd just say "/64= prefix". If you need a justification for /64 (even though the documen= t doesn't justify the other parameters either, such as 3600 for the pre= fix lifetime or 300 for the RA interval), then you can say that SLAAC is no= t defined for any other size, and per RFC 7421, prefixes longer than 64 bit= s are outside the current IPv6 specifications.
      4. In section 4, the dr= aft should say that the prefix should be global, since the document uses th= e terms "UE" "subscriber" and "WiFi hotspot" = which strongly imply Internet access.
      5. In section 4, the text sh= ould not use the terms "/128 unique address" or "assign itse= lf a 128 bit IPv6 address". The whole point of assigning a /64 to a ho= st is so that it can use as many addresses as it wants/needs without impact= ing the network. This is confusing because just a few lines down the draft = says that the host needs to do DAD "for each address".
        6. Also a minor suggestion: in section 5, when discussing the inactivi= ty timer, the draft could say that the inactivity timer is one approach, bu= t the network could also use other signals to detect that a host has gone a= way, for example cues from link-layers such as 802.11 that have clear disco= nnection signals.

      Cheers,
      Lorenzo<= /div>
      --001a114bc9e2b73d740552dd70a2-- From nobody Mon Jun 26 08:01:44 2017 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 CADE712EADB; Mon, 26 Jun 2017 08:01:43 -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 GvUKaFwKWeeU; Mon, 26 Jun 2017 08:01:42 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2332712EACE; Mon, 26 Jun 2017 08:01:42 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r30so3451431qtc.0; Mon, 26 Jun 2017 08:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pT8i+s2fExAohInwIDtoDM2HhJ2ZHPiH96w0dWYHOE8=; b=e7/0HJXuVOAC0KcQZ5hwS2UWxE0NYESyvl4tgKDdqmk8SIsQ5ASp+70d0g5bk3pl5Y Zs9Mu4PId+kxEPnbYXLghRJ/xJZHArJ1UWPab+ycNqMnyYchMbNZHWA64/oECP6WXuwT uwXD7fTyChIy+0qE1axUXdx4k7r3HMPmnxQEKrIV9hBt0MPZ1HdzShiwEsFQMjXEfPNM 4AAy+6qXr9G7/MS2XZ5zkInZCdl1mNJrzHXoofTX4guTld/3Pc9kWP9lzZTquAH7U3Q8 uhTsmL10mtkraH+bWYKjB3tFJBiostvxuYv5W0hAbgM60P2DH9wUzCDOLkX7dnuRO42M odIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pT8i+s2fExAohInwIDtoDM2HhJ2ZHPiH96w0dWYHOE8=; b=Ovlc6dzE3lrAC51KKBu1cC+qPh6AEtwL2S4dAmaci7HxidffHEmGyfKcQuduXLcFdO K9O2v41HZnjQbh6/KFkOVl+KtZh1N1Ws4EP58qjvAZHqE57FekpaxaDeOZMWQacj1D7E i9LCGH99RBgo34sI0La4DesY8q4TtMzO03pcYdYLa82eDYyO2UQ38Xhy0r36JZGswPt9 mtGple9KyhcDDms7ZgML/MbxS/TbJ/RCtWqyuxaoQVQvM/AJYgP530mXYZJjb54SsTmL YLEgSakJNzE0AS1hNadUfKs+cmXu7VeEcHj3mkGmqNtplGEVKBahjBWBqgdx1C7obWtI gI3w== X-Gm-Message-State: AKS2vOxAFQlkn7RBWYIKv2TkKLRrVTzhdkBf2gWNyekokt2ha5sX914b ZKsTvRD1FULodbTEKuhGyvBtXJZDwA== X-Received: by 10.200.37.1 with SMTP id 1mr831529qtm.216.1498489299482; Mon, 26 Jun 2017 08:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.135 with HTTP; Mon, 26 Jun 2017 08:01:19 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Richard Hartmann Date: Mon, 26 Jun 2017 17:01:19 +0200 Message-ID: To: Lorenzo Colitti Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:01:44 -0000 On Mon, Jun 26, 2017 at 4:04 PM, Lorenzo Colitti wrote: > The text "(1) a Unique IPv6 prefix (most likely a /64 prefix consistent with > RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the behaviour of > forwarding equipment, and this draft is about prefixes assigned to hosts. > I'd just say "/64 prefix". If you need a justification for /64 (even though > the document doesn't justify the other parameters either, such as 3600 for > the prefix lifetime or 300 for the RA interval), then you can say that SLAAC > is not defined for any other size, and per RFC 7421, prefixes longer than 64 > bits are outside the current IPv6 specifications. The text as-is anticipates possible future change without changing anything, preventing possibly perpetuating the /64 for cyclic reasons. Richard From nobody Mon Jun 26 08:18:51 2017 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 F0E2112EAEA for ; Mon, 26 Jun 2017 08:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeEXhi-aF_A6 for ; Mon, 26 Jun 2017 08:18:48 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1117F12EADB for ; Mon, 26 Jun 2017 08:18:48 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g40so2751837uaa.3 for ; Mon, 26 Jun 2017 08:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u9AuWyPfVqQMW2vfp8rNoPZmFRyaXAvpBkC6qDDGkrw=; b=hwx+gx55NQjTSBgvGNqddAnBFKmk9gFbGg3wmWM9WjUO755AwbAGHmGkePYfTKf5cX b83JJKfKiT/cJmFsHtJHQcBJqzjKebCPBXyLZLI4qD/n/QmLOiu6Opj0UBfHyv/yUfEg 1Ux1hPIu0DXyGXhf2AXILnU566RsqI6riSCTt6updANSvat7+6VUDakztx9m3c18258r qWzOD70sHX63wF8pIIvDXwRTNPqDteq9QMCA2vErZTJm6e8tA/+YXIFOGx6iZXVGJqeq TUwa+VL8Z3EpJrtFsrP0qBtQ1eKBPTz5iNL5RiMxl0InyQbd/yAY7HLGOx15oYJwE3+a qIIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u9AuWyPfVqQMW2vfp8rNoPZmFRyaXAvpBkC6qDDGkrw=; b=Fwstxl6NqHOXMuv82Sn85rQNFSZXNgbsTlivsJb3MUCgUuL8aiFcStwZ9LxZt1s6/C YMmSFzl9bYW6isdODzCGqQVUDZQr5Lgjbdxtk3hv0vZVxQAwoh/MZ7Aoek5fKsATCW6h d3axUEZ5vZx0GhUGNNcNzS0uUkw7v0tO0Bgp1r6SgCpUtI925uOFQ6N5QnaNX/vDfwnC 7iip0IoWTHJ0XkJkVa/Irw4nsLrnAcX7LZsmrJ/3InIM1wV/1kCQ7aLzQSGjhWg4Lg1l DEd4GTc9iy4LkkE9E30574zbSNDwwjei7CM6s3b/pePV5wilZEBVVtDWVzML3zFzQMe7 x6dw== X-Gm-Message-State: AKS2vOxWno8zGOp4lE9BF0AmmEPnDnaSB+urU6Uq2njOdAzz/SVk685d sZe+mWPRe8D27T0qzOtlIgitp1si/Uuk X-Received: by 10.159.40.136 with SMTP id d8mr433877uad.48.1498490326881; Mon, 26 Jun 2017 08:18:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Mon, 26 Jun 2017 08:18:26 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 27 Jun 2017 00:18:26 +0900 Message-ID: To: Richard Hartmann Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c124714a2922e0552de7784" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:18:50 -0000 --94eb2c124714a2922e0552de7784 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 27, 2017 at 12:01 AM, Richard Hartmann < richih.mailinglist@gmail.com> wrote: > > The text "(1) a Unique IPv6 prefix (most likely a /64 prefix consistent > with > > RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the behaviour > of > > forwarding equipment, and this draft is about prefixes assigned to hosts. > > I'd just say "/64 prefix". If you need a justification for /64 (even > though > > the document doesn't justify the other parameters either, such as 3600 > for > > the prefix lifetime or 300 for the RA interval), then you can say that > SLAAC > > is not defined for any other size, and per RFC 7421, prefixes longer > than 64 > > bits are outside the current IPv6 specifications. > > The text as-is anticipates possible future change without changing > anything, preventing possibly perpetuating the /64 for cyclic reasons. > The reference to 7608 is incorrect regardless. RFC 7608 is only about routers forwarding packets. It says so not just in the title ("IPv6 prefix length recommendation *for Forwarding*"), but also in the text: "it is fundamental not to link routing and forwarding to the IPv6 prefix/address semantics". On the other hand, this document is only about IPv6 addresses assigned to hosts. So it's just inappropriate to cite RFC 7608 here, period. As for why 64 bits: a document making operational recommendations should make recommendations that work. SLAAC with non-64-bit prefix lengths is not only disallowed by RFC 4291, it also won't work on any currently-defined link type. --94eb2c124714a2922e0552de7784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      On T= ue, Jun 27, 2017 at 12:01 AM, Richard Hartmann <richih.mailingl= ist@gmail.com> wrote:
      > The text "(1) a Unique IPv6 = prefix (most likely a /64 prefix consistent with
      > RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the beh= aviour of
      > forwarding equipment, and this draft is about prefixes assigned to hos= ts.
      > I'd just say "/64 prefix". If you need a justification f= or /64 (even though
      > the document doesn't justify the other parameters either, such as = 3600 for
      > the prefix lifetime or 300 for the RA interval), then you can say that= SLAAC
      > is not defined for any other size, and per RFC 7421, prefixes longer t= han 64
      > bits are outside the current IPv6 specifications.

      The text as-is anticipates possible future change without changing anything, preventing possibly perpetuating the /64 for cyclic reasons.
      <= /blockquote>

      The reference to 7608 is incorrect regardle= ss. RFC 7608 is only about routers forwarding packets. It says so not just = in the title ("IPv6 prefix length recommendation for Forwarding= "), but also in the text: "it is fundamental not to link routing = and forwarding to the IPv6 prefix/address semantics". On the other han= d, this document is only about IPv6 addresses assigned to hosts.=C2=A0So it= 's just inappropriate to cite RFC 7608 here, period.

      As for why 64 bits: a document making operational recommendations sh= ould make recommendations that work. SLAAC with non-64-bit prefix lengths i= s not only disallowed by RFC 4291, it also won't work on any currently-= defined link type.
      --94eb2c124714a2922e0552de7784-- From nobody Mon Jun 26 08:26:54 2017 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 E5A7D126D05; Mon, 26 Jun 2017 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlE-zGiCzikU; Mon, 26 Jun 2017 08:26:47 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A799C129B47; Mon, 26 Jun 2017 08:26:47 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id r62so4093956qkf.0; Mon, 26 Jun 2017 08:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5p9/MWqH9CbUaz2wGoOOVfxGxcy7/ZYVPgFu1kqUUm4=; b=p7Gbz0xWK+X3XMNu9B5AaLjrDE57d/z53ZiJHF7Io+Z3WJSAnIeg6OmVsPePAPqdS/ BoR/z0+3/c1Q0Gm/rDLCrwT/7m0YrVFSv+uIdWkhtetmOVjAiVXa46zD2QBqbUg2jD/W bNd8nYIa2QpADf6nENXlVvc6y1An6vyuV1Q5+9i7889DLRA+HD4NN5BZ57D0dMpFUfEx Hhnfi7sFS//C5gEGO477/oAjX1BmUOKgvXPpg/ZFfqJF8KMO5eqhCxt3FU7Lv4TCTaIS b1RUgLAE16cdwSuB6ZJ5R04WISzx+V5iI97WWuPPYn4vNsEIxvPoOb5qkxxphouFj0Je a6Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5p9/MWqH9CbUaz2wGoOOVfxGxcy7/ZYVPgFu1kqUUm4=; b=VuShrPrZI0bKyzy5zunSM54gRHyXvDIS72FsMLmwXKJmtkmBuksQJ+gtGXx5Ne8O6s kZp3/D9kepqZPMx1gAsPWcUuKcnkwLaF4hvVGOuXECV1QLuZCs6b1d1M2UXqJCmC8UYc ILGxjenWBXQEjc1qdkyBGluW9R8+IKo4PJZtRZ//5xL4K+O4KyJW5PRobNM4GdrzVUOW 5/0PDuJALGLhpj2KwVNauEIFupdKMgwnG59Q+EAqGmPDFSGPkrpCuF/DY9B/1eUNG8K2 GjER1Dxww97i0ouzpz/baE1Lf5k3RM1Q2/2eJvTXygx4ePBWVCYwmkX0VeUpw+lV7cot WApA== X-Gm-Message-State: AKS2vOwvUTmQHVTAwW8Cr2SUDKXfIopq1wzkQEDFIoG8RKuBEkkGUjZv VbI3D0kMYD+uprzViby0yWxhhvP48A== X-Received: by 10.55.20.156 with SMTP id 28mr904087qku.191.1498490806831; Mon, 26 Jun 2017 08:26:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.135 with HTTP; Mon, 26 Jun 2017 08:26:26 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Richard Hartmann Date: Mon, 26 Jun 2017 17:26:26 +0200 Message-ID: To: Lorenzo Colitti Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:26:53 -0000 On Mon, Jun 26, 2017 at 5:18 PM, Lorenzo Colitti wrote: > The reference to 7608 is incorrect regardless. RFC 7608 is only about > routers forwarding packets. It says so not just in the title ("IPv6 prefix > length recommendation for Forwarding"), but also in the text: "it is > fundamental not to link routing and forwarding to the IPv6 prefix/address > semantics". On the other hand, this document is only about IPv6 addresses > assigned to hosts. So it's just inappropriate to cite RFC 7608 here, period. If your point is that RFC 7608 should not be mentioned while maintaining the rest of the text, we agree. > As for why 64 bits: a document making operational recommendations should > make recommendations that work. SLAAC with non-64-bit prefix lengths is not > only disallowed by RFC 4291, it also won't work on any currently-defined > link type. There's no use in rehashing the arguments in recent threads. Everyone on this list is well aware of the current state, but anticipating possible change without enforcing it seems to be a prudent way to write IDs going forward. Richard From nobody Mon Jun 26 08:28:15 2017 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 7B7A012EAF8 for ; Mon, 26 Jun 2017 08:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkxLhJgfyw-d for ; Mon, 26 Jun 2017 08:28:11 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 6106E12EAEB for ; Mon, 26 Jun 2017 08:28:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v5QFS7ot013810 for ; Mon, 26 Jun 2017 17:28:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AAE95200CC6 for ; Mon, 26 Jun 2017 17:28:07 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A0C1E200B59 for ; Mon, 26 Jun 2017 17:28:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v5QFS7n2028398 for ; Mon, 26 Jun 2017 17:28:07 +0200 To: v6ops@ietf.org References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <2ef084a2-8c04-1999-f640-ac470a19d7ba@gmail.com> Date: Mon, 26 Jun 2017 17:28:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:28:13 -0000 Le 26/06/2017 à 17:18, Lorenzo Colitti a écrit : > On Tue, Jun 27, 2017 at 12:01 AM, Richard Hartmann > > wrote: > > > The text "(1) a Unique IPv6 prefix (most likely a /64 prefix consistent with > > RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the behaviour of > > forwarding equipment, and this draft is about prefixes assigned to hosts. > > I'd just say "/64 prefix". If you need a justification for /64 (even though > > the document doesn't justify the other parameters either, such as 3600 for > > the prefix lifetime or 300 for the RA interval), then you can say that SLAAC > > is not defined for any other size, and per RFC 7421, prefixes longer than 64 > > bits are outside the current IPv6 specifications. > > The text as-is anticipates possible future change without changing > anything, preventing possibly perpetuating the /64 for cyclic reasons. > > > The reference to 7608 is incorrect regardless. RFC 7608 is only about > routers forwarding packets. It says so not just in the title ("IPv6 > prefix length recommendation *for Forwarding*"), but also in the text: > "it is fundamental not to link routing and forwarding to the IPv6 > prefix/address semantics". Put that way it is out of context. In practice if one forwards a /65 to a SLAAC-/64 one obviously makes a misconfiguration. > On the other hand, this document is only > about IPv6 addresses assigned to hosts. So it's just inappropriate to > cite RFC 7608 here, period. If so, then one has to make it such 64 is actually a variable plen in Host Addressing. > As for why 64 bits: a document making operational recommendations should > make recommendations that work. SLAAC with non-64-bit prefix lengths is > not only disallowed by RFC 4291, it also won't work on any > currently-defined link type. I think we should update RFC 4291 to allow it. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 26 08:37:10 2017 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 6B87B127735 for ; Mon, 26 Jun 2017 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1JSTzy5Cn7n for ; Mon, 26 Jun 2017 08:37:06 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FC5127076 for ; Mon, 26 Jun 2017 08:37:06 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id 191so2674362vko.2 for ; Mon, 26 Jun 2017 08:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AtCj7b9d0dJTELfIjoGbZSE53o0VW0pOfHaR0ZgTmQg=; b=lYmbuX1cnHKDkeF3cXs4qMdpJrf0t6SYjOxYQqr7xp49/s02ThlBHnZzYQn+Yy8KzR vA2DQkyrdQGAMY6uPzGlhVmGh8MmBcBLVJW0poCLYeedyZSRB/zu+ECljkfO2WCMd7pA 4cKISaKAJLwh75dSc83+OG1Woxv5yCHN0xYjk/waXf/5gqSNXC+kzAtwY1NlwciD+Ef1 ZPcQX2KlfZQYFtXvhY+zzRFuvhj9eDdSTuRMYOEZwvtDNndWvgxebjn9q7Ah4nR/foEH oESfDg6B9VGgsyIdfEkr8I8bY2minx53hL64gWo/A1o0KXNvtmew6h8dfHH3Om6UvNAN zgDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AtCj7b9d0dJTELfIjoGbZSE53o0VW0pOfHaR0ZgTmQg=; b=gSHWW3zuu5Op8lYRo6ldnYdJY7qCUOhldB0GIMNDp0CNEtRsk4KkdkyMbe2L2ISlzI l3Cj6yDL5zkrHV/HzVO+lCWbbMVBuQK/WIXrpbeorStuIrAnAC5XEooP9vQoa65D/F6q 285bdxXXivAJkY/keKv15WN/o1wm1XqcMCs3osjJYSyMY4Herjhfn/o637AaCFKf8sxw 6MaeWiMN8Ss87Ysdou5J2frQJa9jU6533OBSwmrqPgbVlXiLNoz+WFPanZdxOc+EIrC0 VPoZL+G+EYl7PQzGg1XCEKEAkBNb4V91ZGa6NPHqpVHsRoerVuDUCIb3FHKVH7EXF/18 WUSQ== X-Gm-Message-State: AKS2vOzQGN/hfI6xsdEWC2aJPPm2Lcu3vzHdQM8a7r1Hu+7TMq2zFSLb mU5wvwvvchuGcoTmYiHUByYdWHYIfQF1 X-Received: by 10.31.210.1 with SMTP id j1mr398725vkg.144.1498491425591; Mon, 26 Jun 2017 08:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.167.150 with HTTP; Mon, 26 Jun 2017 08:36:44 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 27 Jun 2017 00:36:44 +0900 Message-ID: To: Richard Hartmann Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114bc9e21fb52e0552deb98a" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:37:08 -0000 --001a114bc9e21fb52e0552deb98a Content-Type: text/plain; charset="UTF-8" On Tue, Jun 27, 2017 at 12:26 AM, Richard Hartmann < richih.mailinglist@gmail.com> wrote: > > assigned to hosts. So it's just inappropriate to cite RFC 7608 here, > period. > > If your point is that RFC 7608 should not be mentioned while > maintaining the rest of the text, we agree. > Almost. There's still the problem that the words "likely a /64" are misleading. "Likely" is not the right word to use since currently anything other than 64 is not just disallowed but won't work at all. "(currently, a /64 prefix)" is more correct. --001a114bc9e21fb52e0552deb98a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      On T= ue, Jun 27, 2017 at 12:26 AM, Richard Hartmann <richih.mailingl= ist@gmail.com> wrote:
      > assigned to hosts. So it's just inappropriate to cite = RFC 7608 here, period.

      If your point is that RFC 7608 should not be mentioned while
      maintaining the rest of the text, we agree.

      =
      Almost. There's still the problem that the words "likely a /6= 4" are misleading. "Likely" is not the right word to use sin= ce currently anything other than 64 is not just disallowed but won't wo= rk at all. "(currently, a /64 prefix)" is more correct.
      --001a114bc9e21fb52e0552deb98a-- From nobody Mon Jun 26 13:44:28 2017 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 F414F12EB66 for ; Mon, 26 Jun 2017 13:44:26 -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 pDWoQ88kazRb for ; Mon, 26 Jun 2017 13:44:25 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 5D44012EB65 for ; Mon, 26 Jun 2017 13:44:25 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c73so5619931pfk.2 for ; Mon, 26 Jun 2017 13:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ITRJ5tAmSW4+ks/ChP4FBYZk+DQNn2KgN8rPwGwNyB4=; b=j54Wu4FSZdgs6guujSh17PVZRjFfxb7hb0TRoqmjBgcbgmljtQD1wMvqYBfflCpu5c IQ3uOZblQkGLVC01ZQajWNQEKtqWPGsSa4ZDAkzl2wlusG9x0GflrM+j2WRbEDLVKtkL vFToNI4PSZarPeQmkc6byxuibA37M+igGYjle85uRoj8prKEUAHzzPiJdWrBZps1SORy 18gxuKBqV1ppitHtwFM0E1/Kys8sydL5FgfvIZEx4dYboBwZRuMcNOZThmKL8/hi0lhb Rs8KIFTeVoVbGK/9FCXA2smu11hUqpwYKhVWaTDnYW4a/GXvUgRSh3ulWF+Kkig8JU2G eaSg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ITRJ5tAmSW4+ks/ChP4FBYZk+DQNn2KgN8rPwGwNyB4=; b=KngJYfWuJZ9E8S5CsaFWFvZGC7WiAyTHTyBgQvzcE2AkSXaDbZgu9/OWDxbZ2NHz0Z t6kuvuEkfL3Tv4MzoUEvsCbPp4oXa1LpAg2yz9Z1SBykOpt1Fvv2itOU2KgajE8/PDeJ 2ftajTHdFC8A8m1UcxLNHPwRTGBzhk1ReTfiXmGd1ettDHXmPkaoz9QGTT3w5HaYQe+N 8aeFMp1UUgzuQ4tT321bw7APYmdSzl0pfcCeoL/TeOfeE2a9bAJMXBooBtB6zkljZ4wh tw/0XZHXwOYjA/vE2uEEnveD4kOdw5wvhKIzAJ95y1Y9HXTqixNAw5VqzPAPrDbNjwdB tGSg== X-Gm-Message-State: AKS2vOwTFYWAJaA/MesWK4keUkYWNWuOuKFfxrbS0BsrhBzxf5vFYWBk rpown/n9fo4hskAi X-Received: by 10.99.127.78 with SMTP id p14mr1926246pgn.124.1498509864728; Mon, 26 Jun 2017 13:44:24 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id i27sm1802716pfk.1.2017.06.26.13.44.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 13:44:23 -0700 (PDT) To: IPv6 Operations References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> Date: Tue, 27 Jun 2017 08:44:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149848407068.31805.10927161382453492195@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:44:27 -0000 Hi, > o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) > > o L-flag = 0 (the prefix is not an on-link prefix, which means that > the UE/subscriber will NEVER assume destination addresses that > match the prefix are on-link and will ALWAYS send packets to those > addresses to its default gateway.) Hmm. Please check this assertion for a host that implements RFC8028 if the LAN is multihomed. At the very least, such a host has more than one "default" gateway - it has one per prefix. Regards Brian From nobody Mon Jun 26 13:52:34 2017 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 41C5112EB67; Mon, 26 Jun 2017 13:52:26 -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 Ghsr3G_akiiQ; Mon, 26 Jun 2017 13:52:23 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB60912EB73; Mon, 26 Jun 2017 13:52:23 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u62so5422842pgb.3; Mon, 26 Jun 2017 13:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cFv15AefSQef1cHUPzQVWCl7whrhKwIyXgaUawiMxPE=; b=ieGZ+RxKPXg55BW7AU9ambu6KMntRiLqwAR0EFw/L/nKvORShMU1Cj0d0WV5SEGQzX oTFvsZTTAxnmsyZ8AtGU/eLS24DfiCwaAKDoGAzXn4TeOjeUDU8uG05P9UiaFGLKKwvR Tiu2IdNlyl4CwmEhlsSixD3IXeX6fJfl3V+ZhwYUDNBZRObFFugLaPLe82JAsk2/NKw1 pdK8lIsdehqlpWy1qoAROFp7JPTb3NrjEIiWitlDJzRCxobXPT7SW84fodZeSGDxo54v E+KzCzNm47kzQryEk3ihuscGrVuULcV73lib3MRQxjXvfiLDtXCwUFfMg8R8D8h5s9io wfHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cFv15AefSQef1cHUPzQVWCl7whrhKwIyXgaUawiMxPE=; b=qU14JRyeJ+qLqtu1dZNcZEhZamF7CGGYvvh9cGz65eI5Qke8Gn2dsm6BIv4+ZUZTs/ 07G2ApssG1ipCX9OKFHLhzH67CdhFmPheWWSXNENVB8fPFfUpQSGJebCQh8gGoEKBHp6 kXBgB8oApMzGtrlLTqCsU/AIV4XIQ80pWucYiNigHqQbjQdFxkdz5r9tIfvWalaHxB00 FFjAwpKDDxvsJXY+CNzmO+d9tqvnMD+aRVwdugPSFNKPaKEpJlPappV3bGv+ls3URA5b OepadbNtkrh3f5PFKliUxVDsd0e9MxW8HL4h2G0/4/Vf9LdrxZDPEitmvvDmAf7cYZV8 aaZA== X-Gm-Message-State: AKS2vOysuealy6PgBlRkvzPcTOm9WJTk037cN0yT60BAKEU806Ieiw2s ez3fR8Ox4o/A38hL X-Received: by 10.84.129.111 with SMTP id 102mr2085781plb.221.1498510343294; Mon, 26 Jun 2017 13:52:23 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id 66sm1641797pgh.59.2017.06.26.13.52.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 13:52:22 -0700 (PDT) To: Lorenzo Colitti , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "ietf@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6c7cf450-d48e-94f4-f705-e24e83d52a44@gmail.com> Date: Tue, 27 Jun 2017 08:52:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.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] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:52:26 -0000 On 27/06/2017 01:37, Lorenzo Colitti wrote: > Please don't cite RFC 7608. It has nothing to do with IP addressing, only > forwarding, and the topic here is host addressing. True. I agree that simply stating that it's currently /64 is appropriate. The point is that /64 isn't an essential property of this solution; it's an externally determined parameter. Brian > > On Mon, Jun 26, 2017 at 9:12 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_velde@nokia.com> wrote: > >> Hi Brian, >> >> Thanks for the review. >> >> I modified the reference to /64 IPv6 prefix length and suggested instead >> consistency with RFC7608 and that currently this likely means a /64 in the >> -04 version. >> >> All the best, >> G/ >> >> On 26/05/2017, 22:24, "Brian E Carpenter" >> wrote: >> >> Hi, >> >> I should have noticed this during the v6ops discussions, but I didn't, >> sorry. >> >> This draft cites RFC4862 (SLAAC) and mentions Router Advertisements >> (without also citing RFC4861, which is possibly a mistake). Those >> documents do not specify the subnet prefix length. So the draft >> shouldn't assume a particular prefix length either. We all know that >> it's usually 64 today, but that doesn't affect the argument made by >> the draft. We need consistency with RFC 7608 (BCP 198). >> >> Regards >> Brian Carpenter >> >> On 24/05/2017 07:41, The IESG wrote: >> > >> > The IESG has received a request from the IPv6 Operations WG (v6ops) >> > to consider the following document: - 'Unique IPv6 Prefix Per Host' >> > as Best >> > Current Practice >> > >> > The IESG plans to make a decision in the next few weeks, and >> > solicits final comments on this action. Please send substantive >> > comments to the ietf@ietf.org mailing lists by 2017-06-06. >> > Exceptionally, comments may be sent to iesg@ietf.org instead. In >> > either case, please retain the beginning of the Subject line to allow >> > automated sorting. >> > >> > Abstract >> > >> > >> > In some IPv6 environments, the need has arisen for hosts to be able >> > to utilize a unique IPv6 prefix, even though the link or media may >> > be shared. Typically hosts (subscribers) on a shared network, >> > either wired or wireless, such as Ethernet, WiFi, etc., will acquire >> > unique IPv6 addresses from a common IPv6 prefix that is allocated or >> > assigned for use on a specific link. >> > >> > In most deployments today, IPv6 address assignment from a single >> > IPv6 prefix on a shared network is done by either using IPv6 >> > stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. >> > While this is still viable and operates as designed, there are some >> > large scale environments where this concept introduces significant >> > performance challenges and implications, specifically related to >> > IPv6 router and neighbor discovery. >> > >> > This document outlines an approach utilising existing IPv6 protocols >> > to allow hosts to be assigned a unique IPv6 prefix (instead of a >> > unique IPv6 address from a shared IPv6 prefix). Benefits of unique >> > IPv6 prefix over a unique IPv6 address from the service provider >> > include improved subscriber isolation and enhanced subscriber >> > management. >> > >> > >> > The file can be obtained via >> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >> 6-prefix-per-host/ >> > >> > IESG discussion can be tracked via >> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >> 6-prefix-per-host/ballot/ >> > >> > >> > >> > No IPR declarations have been submitted directly on this I-D. >> > >> > >> > The document contains these normative downward references. See RFC >> > 3967 for additional information: rfc6106: IPv6 Router Advertisement >> > Options for DNS Configuration (Proposed Standard - IETF stream) >> > rfc4941: Privacy Extensions for Stateless Address Autoconfiguration >> > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless >> > Address Autoconfiguration (Draft Standard - IETF stream) rfc3315: >> > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed >> > Standard - IETF stream) >> > >> > >> > >> > _______________________________________________ v6ops mailing list >> > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops . >> > >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Mon Jun 26 17:13:01 2017 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 DE8F51201F2; Mon, 26 Jun 2017 17:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zjMZ83jdxS; Mon, 26 Jun 2017 17:12:59 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8B012EB7C; Mon, 26 Jun 2017 17:12:58 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 191so8642221vko.2; Mon, 26 Jun 2017 17:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/2WowwiurS8CcCOM9GlN8jgIDQ4HSJ/nzpo/DEzr/Lw=; b=j42agOXPr/ctLGQrnzcMfyCGPneoMicEPesQfixtUrOnaeLLSW08JVtnYubH0fTHj8 dsFiRQ/x8L5FNBizXGqO9tkj/UX2nvo4rVb+jFSdWg0cKeCPTs1X0Twe3J1pfe2KMiK1 B1wcW2DCnnltNiFaKCGc2wwovHAwzxM0FwbrPLT+7ge32cM80lwfT/IRYJGEZzrvjc1L y5HgBkVhW0+Cp0nIyI7QqRPy35vH8lRtacxInbrrwSypOcLTF/kd+2NZxPOU825fZd3e v1iPNwaTiA3bH64hztgk8ycxd60REdUARUM3xtkYF/8ZFk15y/Dxh+LM0lPp7v6Svf5G jfzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/2WowwiurS8CcCOM9GlN8jgIDQ4HSJ/nzpo/DEzr/Lw=; b=OoimVw4oLahH6d7JJ3uw6XEiq5IfveEiwwSbjO87hoA9rgOTDII82INHzSoKMmztDV 0ecsZa6Y+QggRLhVV20bKzNzjn8onhV80u1KAE1LtJ9OxqcUMkU//tAu4r/obylozaNW dtEbINGjThYWiTRJMXh1WEqADt+tHK/on0sH3IIlQXBlxj0q4qz18EYcEHAoybeqI/v9 to1GvbHHWn7WWJJevYIyTukR7mrA+mPguWLjnllB2YrpU56l2+zS0bR/eH6L6UXuSKrr nFiYCoTrjZV+BvtdRNUpJWLqXWdWz/NDELQ4bHMVQiRIeagFzNm4RZsJbylPKvHfRb3p UztA== X-Gm-Message-State: AKS2vOxuayMu2XHVeZBn/2cjyEG/iUSa+hUXzFTTP33bDTlyhb4tS8d7 zK/Bb3Y5+Kz6Nrc/T76ykcMPYLFUXA== X-Received: by 10.31.175.194 with SMTP id y185mr506397vke.48.1498522377834; Mon, 26 Jun 2017 17:12:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Mon, 26 Jun 2017 17:12:27 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Mark Smith Date: Tue, 27 Jun 2017 10:12:27 +1000 Message-ID: To: Richard Hartmann Cc: Lorenzo Colitti , draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 00:13:01 -0000 On 27 June 2017 at 01:26, Richard Hartmann wrote: > On Mon, Jun 26, 2017 at 5:18 PM, Lorenzo Colitti wrote: > >> The reference to 7608 is incorrect regardless. RFC 7608 is only about >> routers forwarding packets. It says so not just in the title ("IPv6 prefix >> length recommendation for Forwarding"), but also in the text: "it is >> fundamental not to link routing and forwarding to the IPv6 prefix/address >> semantics". On the other hand, this document is only about IPv6 addresses >> assigned to hosts. So it's just inappropriate to cite RFC 7608 here, period. > > If your point is that RFC 7608 should not be mentioned while > maintaining the rest of the text, we agree. > > >> As for why 64 bits: a document making operational recommendations should >> make recommendations that work. SLAAC with non-64-bit prefix lengths is not >> only disallowed by RFC 4291, it also won't work on any currently-defined >> link type. > > There's no use in rehashing the arguments in recent threads. Everyone > on this list is well aware of the current state, but anticipating > possible change without enforcing it seems to be a prudent way to > write IDs going forward. > Possible change is anything possible. With enough changes, IPv6 could support 129 bit addresses, so they're possible too. I don't think consensus has been reached on relaxing /64, so it shouldn't be assumed to be probable. > > Richard > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 26 21:37:36 2017 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 20A79128B91 for ; Mon, 26 Jun 2017 21:37:35 -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 sWycPTY-HWbD for ; Mon, 26 Jun 2017 21:37:33 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2597A128B8F for ; Mon, 26 Jun 2017 21:37:33 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id k67so152606856wrc.2 for ; Mon, 26 Jun 2017 21:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=1LBf/PbT3aGAci5Uu1sm2OfBqURlB+zajORzocebggg=; b=Ynnk3CWbLCJmHNI9CPiaS2FJqPi8GVGNPOKKjfOlRrZu0g8+EoHzSu7lUQKP4CYmcl l27DlXe+yz4EMMdNtFIPH1FbojzX3R0cewLNWvw3v0722uWd256NAHOgLZgItGdW4hyX qbflilMDq9BU3+ZqSpILV8+Q4N99wyC5t9EaIJ9UU/kkC8nthr0yP0iYtU+MOSP/Iv5y VHiAGLCcDkOgyMjJfG7U5eeTq5Kxq3hD2MfkhfEDRb2z9LCY769rdAsatB95HcL8yiSI X4Ro7UZFYe3DB4OFgOzEKndjTHc9Cqy7eq4koR76nH6Y3e+iiD+UoJgq5g2l2HAV6duW MIcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=1LBf/PbT3aGAci5Uu1sm2OfBqURlB+zajORzocebggg=; b=TqDFpWHrDXUTmzszZSGOfWrMtiEpwSi/fIDKvEC6YjonarGCaDBEXkaGNQztFxKvv/ dKyNEkMkD9ysT7TyaEO/UYMm3zMuxG/rMQ6GmU7WS3mLSc+jo2IaJKsGZcvnycaZrUMb q6gEBpm+wI4kdy6WLAi/2fnTn7RMQELtOr1xttnXRqyK0477zQo72kRlsl/4mCU7fGu/ w3OIIAubDmqk7i3a35QxoF8GxhXvoCYfsLwPi0BJ1S+Ak0oPXuenF6ZO6IZJW2l/GxRJ o+0pYSQrLYpPXlaSr0PE9upowODFjnbu4PHB7+x0cnbWMNpdJZ9u0DYFnUQWFKOF9G9w pByQ== X-Gm-Message-State: AKS2vOy2OidHcwKygaBvumZnFe8dpgbn9w71SHjHbY+QRywT71KaEMbC v4TBzlLCon8ZysQy1eU= X-Received: by 10.223.175.37 with SMTP id z34mr16025610wrc.11.1498538251503; Mon, 26 Jun 2017 21:37:31 -0700 (PDT) Received: from rfc.private.address.invalid.query ([196.208.108.90]) by smtp.gmail.com with ESMTPSA id g137sm804192wmd.32.2017.06.26.21.37.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 21:37:30 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <43AE589D-9A2D-4586-AB5A-1E8881EA21DD@gmail.com> Date: Tue, 27 Jun 2017 06:37:28 +0200 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Agenda bashing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:37:35 -0000 I have posted a preliminary agenda at = https://datatracker.ietf.org/meeting/99/agenda/v6ops/. This covers our four working group drafts, three of which I would like = to believe we can bring to closure before IETF 100, and two of our = individual submissions. It also includes three invited talks, relevant = to "turning IPv4 off", "happy eyeballs", and industry deployment status. We can revisit it if people have comments, and especially if a new draft = is posted this week that the working group expresses interest in. The = draft cut-off is next Monday.= From nobody Tue Jun 27 12:54:08 2017 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 B246F12EAAA for ; Tue, 27 Jun 2017 12:54:06 -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, RP_MATCHES_RCVD=-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 mK_4xLCPDr7G for ; Tue, 27 Jun 2017 12:54:04 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1DF1270A7 for ; Tue, 27 Jun 2017 12:54:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e] (unknown [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 791381BC37 for ; Tue, 27 Jun 2017 19:53:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> Date: Tue, 27 Jun 2017 20:53:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82114BA3-4269-4056-838E-9815FA291053@thehobsons.co.uk> References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:54:07 -0000 Brian E Carpenter wrote: >> o A-flag =3D 1 (The UE/subscriber can configure itself using = SLAAC) >>=20 >> o L-flag =3D 0 (the prefix is not an on-link prefix, which means = that >> the UE/subscriber will NEVER assume destination addresses that >> match the prefix are on-link and will ALWAYS send packets to = those >> addresses to its default gateway.) >=20 > Hmm. Please check this assertion for a host that implements RFC8028 > if the LAN is multihomed. At the very least, such a host has more > than one "default" gateway - it has one per prefix. In a multi-homed host, all this is done per-link. An address may well be = on-link for one link, and off-link for another. So a host may well have the option of sending a packet to another host = either directly via one link, or via a default router on another link. I = don't think that invalidates any of the previous discussions - provided = you consider each link in it's own right. From nobody Tue Jun 27 17:44:14 2017 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 7A00D127241 for ; Tue, 27 Jun 2017 17:44:13 -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 7S9A6556pK90 for ; Tue, 27 Jun 2017 17:44:10 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73DE129B3C for ; Tue, 27 Jun 2017 17:44:10 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id q86so24506429pfl.3 for ; Tue, 27 Jun 2017 17:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6skbv5MaPowvb+CR8JON3pFPnBJoI2nvkDjcMFUfKTA=; b=rpombfmCclVKoHU0zX5/RFErdqAWMkdSNUjKl2POP6M4gXMHqhjJ8/lx/dbBti8Vcv GKXuccMgNr2hCWN4rgM/XJN+bSKrvHUHTtJBeR3VoZRQej9trDPb29esR68GsXgX7Ghx 1vESy1CWnMn/e+W6S4HV9+M4ICjwrn6K64/V5tkioE75bzcITCVeTjQM/WI0iRKQhiQO I4SO5+3duxEV30HkWIE8kWNipby8fqPqvz2JQ2hI/kJRunAcFPf2WhsnI7mTXQNZqxw4 dOt4Agu37Ps20O1wacnqBBnB3NaeA3E6CoJ9K1lUS7jDjca1Vkr+ZrDzIlW6q2IwsmhV BCgQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6skbv5MaPowvb+CR8JON3pFPnBJoI2nvkDjcMFUfKTA=; b=WCIt8w62DHW3D4GYd2mtM9x9seZP9cWANNBaoaSgWb/cmwLRpXpvAE04/8Jp0mHqcd JtAtlDEohCfwQNC2dTmkBhSvg3UEk3dkQRUYKi41A6eJjPzHLPOt8kkotZg0DvshIwJH 2unkoxn1iD7cTib7g5SQA9jIncA4eKrA5uCUzqJfTuLiBBVWMz9ZfkM3TIemU7nUkLVg nGUGoA2Js4OsCL5EyKLD/pOvai0jT5HqzgnsRyAcw0EgM+E1jek5Vti7xhofpqWBtPAG +XtVBOF4rR6UAPAxXI9FvQ6eSEvG6Gd0GMC9Th+ajZi902hJ6OLBmXQ1xZdjJhybc/05 iUtQ== X-Gm-Message-State: AKS2vOwQfwca+hkFkjJGEzizvC8+qMbWEFlW+hQIU5WG0MdSNw6P7YJ9 xjtWmI392LBbZV9H X-Received: by 10.84.196.1 with SMTP id k1mr8866994pld.149.1498610650047; Tue, 27 Jun 2017 17:44:10 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id s88sm775649pfk.16.2017.06.27.17.44.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 17:44:09 -0700 (PDT) To: v6ops@ietf.org References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> <82114BA3-4269-4056-838E-9815FA291053@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <69b6ba32-d14d-18b2-8e00-299661bb9d59@gmail.com> Date: Wed, 28 Jun 2017 12:44:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <82114BA3-4269-4056-838E-9815FA291053@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 00:44:13 -0000 On 28/06/2017 07:53, Simon Hobson wrote: > Brian E Carpenter wrote: > >>> o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) >>> >>> o L-flag = 0 (the prefix is not an on-link prefix, which means that >>> the UE/subscriber will NEVER assume destination addresses that >>> match the prefix are on-link and will ALWAYS send packets to those >>> addresses to its default gateway.) >> >> Hmm. Please check this assertion for a host that implements RFC8028 >> if the LAN is multihomed. At the very least, such a host has more >> than one "default" gateway - it has one per prefix. > > In a multi-homed host, all this is done per-link. An address may well be on-link for one link, and off-link for another. Yes. But the RFC8028 case is where the *LAN* is multihomed, so the host has a choice of first-hop routers on the same link. It does not have a unique default router. Brian > So a host may well have the option of sending a packet to another host either directly via one link, or via a default router on another link. I don't think that invalidates any of the previous discussions - provided you consider each link in it's own right. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jun 27 19:44:00 2017 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 21D54126CC4 for ; Tue, 27 Jun 2017 19:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez3ZRtR6EWyu for ; Tue, 27 Jun 2017 19:43:55 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 5ED8712717E for ; Tue, 27 Jun 2017 19:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498617834; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=i2a2hpFUoUxtQiiPFUJi4RCKjK762g3o1nQKxG+L3E4=; b=A6NoK9vyiiQnBNxYNQK4A+7yMJ/DdNvjJDHBnX52dt+uxvMfhVEf7yXVSvP7fQ8S bCLdn58MWAv/0LAqPieHZKDUGHdRUHi1oYq872ovnzj9xiVMatHrzEFDerfWCZzr BhIs8qIpORikHwMOylFurfSVxKi1EdcFB1KR5lkjlEsIZxkZkBK/0J2QDrYeN2hj XaU/Is6GGuV0LC6k81ab1OVr7E7LtlBHkN1kT6Zn72pxLeF1mLg2h00Svc3Jx+61 9qmqtWKnIhp2abuEgloF3e/tQiIH56SS7SS+aR+Y4x2cfqrD4eXtu00xIXcq2cKR SEoiCZAC/96KrdLXifNCnQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id F3.A2.05744.AE713595; Tue, 27 Jun 2017 19:43:54 -0700 (PDT) X-AuditID: 11ab0219-dacb19c000001670-69-595317ead134 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id 42.B6.05704.9E713595; Tue, 27 Jun 2017 19:43:54 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_D7nD5xDN6AARe33Z1/zsfw)" Received: from [100.122.139.66] (116.sub-70-213-23.myvzw.com [70.213.23.116]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS800KSRKX4MY30@kencur.apple.com>; Tue, 27 Jun 2017 19:43:53 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi X-Mailer: iPhone Mail (14G40) In-reply-to: Date: Tue, 27 Jun 2017 19:43:52 -0700 Cc: IPv6 Ops WG Message-id: <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> To: jordi.palet@consulintel.es X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FCYpvtKPDjSoOeJisXf45+ZLU4f28vs wOSxbn+Ax5IlP5kCmKK4bFJSczLLUov07RK4Mi7tbWEumHmbsWLS+z72BsbXuxi7GDk4JARM JLr/J3cxcnIICaxlkjh6nBHEBgnv3dnB3sXIBRRfwSjx7OJ3dpAEr4CgxI/J91hAbGaBMIk5 L9awQhTNYJJo6dsEViQsIC3RdeEuK4TtJvF3w0omkGVsAloSB9YYQeyVlfi4UgqkglPASWLX 0lNgFSwCqhKTl0ZCTFeQaHvXzgix1Ubi99c1TBCb1jFKLJ95kwkkISIgJ3F3RSsjSEJC4ACb xNmDZ5gmMArNQnLqLCSnzgLawSygLjFlSi5EWFviybsLrBC2msTC34uYkMUXMLKtYhTOTczM 0c3MMzLVSywoyEnVS87P3cQIioTVTJI7GL++NjzEKMDBqMTDu0IkOFKINbGsuDL3EKM0B4uS OO/UOYGRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhj3Nh9LefVbkf3FFaaJ7BtrbRgqFdh2 K0p+iT+1PojVdpe3+60DVR0Xp/uJ/5ZdItrRWN/BUajiL6O4XN71rLfQTvUJ+x90fJDiXPr4 1crm3vTL/jY7We9Ub+Uq184LZ9trL+CaWBZ09r3PIYvVMq/Du85OD+x5kBR38rrKvthJul9P 99ffV1FiKc5INNRiLipOBADj6F1nZQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OTfeVeHCkQVsTp8Xf45+ZLU4f28vs wOSxbn+Ax5IlP5kCmKK4bFJSczLLUov07RK4Mi7tbWEumHmbsWLS+z72BsbXuxi7GDk5JARM JPbu7GDvYuTiEBJYwSjx7OJ3dpAEr4CgxI/J91hAbGaBMIk5L9awQhTNYJJo6dsEViQsIC3R deEuK4TtJvF3w0qmLkYODjYBLYkDa4xATAkBWYmPK6VAKjgFnCR2LT0FVsEioCoxeWkkxHQF ibZ37YwQW20kfn9dwwSxaR2jxPKZN5lAEiICchJ3V7QyTmDkn4XkullIrpsFNJZZQF1iypRc iLC2xJN3F1ghbDWJhb8XMSGLL2BkW8UoUJSak1hpoZdYUJCTqpecn7uJERS6DYVpOxibllsd YhTgYFTi4V0hEhwpxJpYVlyZe4hRgoNZSYSXZXNQpBBvSmJlVWpRfnxRaU5q8SHGiYxAj01k lhJNzgdGVl5JvKGJiYGJsbGZsbG5iTkthZXEeWV6gC4SSE8sSc1OTS1ILYI5iomDU6qBcdqD L7e31Bob3MoTD+a3ePfNViNv7c+fB/2euJs0WjTONEzZdJ/pxJbLMkvkF944bJIQp+jV/bZW b7pN9s/Ptfc5i9K+M0cfco08vW3FvkmS8+Y8LJHTc1UtmifyYtHyLbyFTc7ebreSvCJ1fM9I xpXoLW0/uHxL08v2tPuf65RvB3jNj5jXrcRSnJFoqMVcVJwIAAZI1yLQAgAA Archived-At: Subject: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 02:43:59 -0000 --Boundary_(ID_D7nD5xDN6AARe33Z1/zsfw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Jordi, Thanks for the review! I applied your clarifications to our working copy. I don't think the document needs to mandate making constants configurable. M= odern operating systems receive periodic software updates that can change th= e values as we work our way towards deprecating Happy Eyeballs. Average smar= tphone users shouldn't be bothered with this (if you can't configure it you c= an't misconfigure it). As we discussed in Chicago, end users should never be made aware of IPv6 net= work failures as they are not their burden or responsibility to fix. Network= operators shouldn't expect their users to be the first ones to notice somet= hing's broken. In effect HE will be deprecated when ISPs stop routing IPv4. Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't currently h= elp with the issue so we marked it out of scope. Are you suggesting a remedy= ? Regarding section 7.1, old socket APIs are out of scope as HE is implemented= above or alongside sockets. Applications using sockets directly will not ge= t any of these benefits. Thanks, David Schinazi > On Jun 18, 2017, at 03:57, JORDI PALET MARTINEZ wrote: >=20 > Hi David, >=20 > Very good job! Some comments. >=20 > Implementations MUST NOT wait for both families of answers to return > before attempting connection establishment. If one query fails to > return, or takes significantly longer to return, waiting for the > second address family can significantly delay the connection > establishment of the first one. Therefore, the client MUST treat DNS > resolution as asynchronous. Note that if the platform does not offer > an asynchronous DNS API, this behavior can be simulated by making two > separate synchronous queries on different threads, one per address > family. If the AAAA query returns first, the first IPv6 connection > attempt MUST be immediately started. If the A query returns first, > the client SHOULD wait for a short time for the AAAA response. This > delay will be referred to as the "Resolution Delay". The RECOMMENDED > value for the Resolution Delay is 50 milliseconds. >=20 > [Jordi] I=E2=80=99m not sure to fully understand this text, as somehow see= ms to me contradictory. =E2=80=9Cwaiting for the second address family can s= ignificantly delay the connection=E2=80=9D, but then you mention 50 millisec= onds as recommended. I think it will be nice to clarify it. Also, I think th= e Resolution Delay should be a parameter, somehow configurable in the OS or a= pps. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use of HE (= by increasing the delay to an exaggerated value), without necessarily removi= ng the code neither breaking apps that rely on it, when we decide that IPv6 i= s widely spread so any IPv6 failures should be noticed by end-users in order= to pass the message to the ISP, etc. >=20 > (note that this is not > referring to the sending of AAAA or A queries, but rather the address > of the DNS server itself) >=20 > [Jordi] To make it clear, maybe you want to say something such as =E2=80=9C= =E2=80=A6 but rather the protocol used for the DNS transport=E2=80=9D >=20 > This delay is referred > to as the "Connection Attempt Delay". One recommended value for this > delay is 250 milliseconds. >=20 > [Jordi] Similar comments about the =E2=80=9CConnection Attempt Delay=E2=80= =9D as earlier: should be a parameter, somehow configurable in the OS or app= s. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use of HE (b= y increasing the delay to an exaggerated value), without necessarily removin= g the code neither breaking apps that rely on it, when we decide that IPv6 i= s widely spread so any IPv6 failures should be noticed by end-users in order= to pass the message to the ISP, etc. >=20 > 464XLAT has the advantage of > not requiring changes to user space software, however it requires > per-packet translation and does not encourage client application =E2=80=A6= >=20 > [Jordi] I think this text will make it more accurate: > =E2=80=9C464XLAT has the advantage of > not requiring changes to user space software, however it requires > per-packet translation in case the application is using IPv4 literals (o= r similar situations as older socket APIs) and does not encourage client app= lication =E2=80=A6 >=20 > [Jordi] One question here. Should section 7.1 also consider not just liter= als but old socket APIs? >=20 > 7.2 Host Names with Broken AAAA Records >=20 > [Jordi] I think you could add in this section (or a new section), the case= for broken PMTUD. We have today many situations were on purpose or as a con= sequence of bad implementation of load-balancing, ECMP, etc. You can try it w= ith any web site from 1&1 (for example diskmakerx.com) =E2=80=A6 just force a= reduction on your MTU I you will find that the website is not only non-acce= ssible with IPv6, but also doesn=E2=80=99t work with IPv4, because actual HE= implementations aren=E2=80=99t able to detect this problem. I think it will= be possible and of course, it will mean removing or having a different text= for =E2=80=9C9.1. Path Maximum Transmission Unit Discovery=E2=80=9D. I agr= ee that because the nature of HE, active only at the initial stage, we need t= o somehow extend the HE algorithm to test that, but I think this is the perf= ect opportunity to make it, because HE is successfully implemented everywher= e, so I guess it will be successfully updated. Making it a =E2=80=9Cdifferen= t=E2=80=9D RFC/protocol, may not have the same impact. >=20 > [Jordi] Of course, I think is a major ISP/date center issue, but they aren= =E2=80=99t resolving it (tried for two years in this specific case), but the= re are many others, worldwide, and if we believe HE is the right solution fo= r =E2=80=9CISPs not doing correctly their job=E2=80=9D, then we should also s= upport this =E2=80=9Cfailure=E2=80=9D. Again, using parameters, to make sure= that when IPv6 is more globally spread we can =E2=80=9Cdeprecate=E2=80=9D H= E and make sure to pass the ball again to those =E2=80=9Cbad guys in the sen= se that they don=E2=80=99t do a good job, or don=E2=80=99t make sure that th= ey test correctly their deployments from the perspective of all kind of user= s=E2=80=9D. >=20 > 8. Summary of Configurable Values >=20 > [Jordi] Looking at this section, you=E2=80=99re saying somehow what I was e= xpressing earlier, so maybe we can make it clearer and is the right place to= include a must to have all those parameters as OS configurable ones (by app= s, users, network management, etc.). >=20 >=20 >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de David Schinazi > Responder a: > Fecha: martes, 6 de junio de 2017, 2:10 > Para: IPv6 Ops WG > Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 >=20 > Hi v6ops, > We have updated draft-ietf-v6ops-rfc6555bis to version 01. > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 >=20 > This version incorporates feedback we received on the previous version,= > and adds a new section on "Supporting IPv6-only Networks with NAT64 and= DNS64" > as these technologies require changes in the Happy Eyeballs stack > on devices that do not support 464XLAT. >=20 > Please let us know what you think! >=20 > Thanks, > David Schinazi >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the IPv6 Operations of the IETF. >=20 > Title : Happy Eyeballs Version 2: Better Connectivity= Using Concurrency > Authors : David Schinazi > Tommy Pauly > Filename : draft-ietf-v6ops-rfc6555bis-01.txt > Pages : 13 > Date : 2017-06-05 >=20 > Abstract: > Many communication protocols operated over the modern Internet use > host names. These often resolve to multiple IP addresses, each of > which may have different performance and connectivity > characteristics. Since specific addresses or address families (IPv4= > or IPv6) may be blocked, broken, or sub-optimal on a network, client= s > that attempt multiple connections in parallel have a higher chance o= f > establishing a connection sooner. This document specifies > requirements for algorithms that reduce this user-visible delay and > provides an example algorithm. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis-01 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any disc= losure, copying, distribution or use of the contents of this information, in= cluding attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_D7nD5xDN6AARe33Z1/zsfw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

      Hi Jordi,


      Thanks for the review! I applied your clarifications to our working co= py.


      I don't think the document needs to mandate making constants configura= ble. Modern operating systems receive periodic software updates that can cha= nge the values as we work our way towards deprecating Happy Eyeballs. Averag= e smartphone users shouldn't be bothered with this (if you can't configure i= t you can't misconfigure it).


      As we discussed in Chicago, end users should never be made aware of IP= v6 network failures as they are not their burden or responsibility to fix. N= etwork operators shouldn't expect their users to be the first ones to notice= something's broken. In effect HE will be deprecated when ISPs stop routing I= Pv4.


      Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't curre= ntly help with the issue so we marked it out of scope. Are you suggesting a r= emedy?


      Regarding section 7.1, old socket APIs are out of scope as HE is imple= mented above or alongside sockets. Applications using sockets directly will n= ot get any of these benefits.


      Thanks,

      David Schinazi


      =

      On Jun 18, 2017, at 03:57, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote= :

      Hi David,

      Very good job! Some comments.

      = Implementations MUST NOT wait for both families of answers to return
        before attempting connection establishment. &nbs= p;If one query fails to
        return, or takes signif= icantly longer to return, waiting for the
        secon= d address family can significantly delay the connection
      &nb= sp; establishment of the first one.  Therefore, the client MUST tr= eat DNS
        resolution as asynchronous.  Note t= hat if the platform does not offer
        an asynchron= ous DNS API, this behavior can be simulated by making two
      &= nbsp; separate synchronous queries on different threads, one per addres= s
        family.  If the AAAA query returns first= , the first IPv6 connection
        attempt MUST be imm= ediately started.  If the A query returns first,
       = ; the client SHOULD wait for a short time for the AAAA response.  = This
        delay will be referred to as the "Resoluti= on Delay".  The RECOMMENDED
        value for the R= esolution Delay is 50 milliseconds.

      [Jordi]= I=E2=80=99m not sure to fully understand this text, as somehow seems to me c= ontradictory. =E2=80=9Cwaiting for the second address family can significant= ly delay the connection=E2=80=9D, but then you mention 50 milliseconds as re= commended. I think it will be nice to clarify it. Also, I think the Resoluti= on Delay should be a parameter, somehow configurable in the OS or apps. This= would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use of HE (by incre= asing the delay to an exaggerated value), without necessarily removing the c= ode neither breaking apps that rely on it, when we decide that IPv6 is widel= y spread so any IPv6 failures should be noticed by end-users in order to pas= s the message to the ISP, etc.

      (note that t= his is not
        referring to the sending of AAAA or A= queries, but rather the address
        of the DNS ser= ver itself)

      [Jordi] To make it clear, maybe= you want to say something such as =E2=80=9C=E2=80=A6 but rather the protoco= l used for the DNS transport=E2=80=9D

      This d= elay is referred
        to as the "Connection Attempt D= elay".  One recommended value for this
        del= ay is 250 milliseconds.

      [Jordi] Similar com= ments about the =E2=80=9CConnection Attempt Delay=E2=80=9D as earlier: shoul= d be a parameter, somehow configurable in the OS or apps. This would also fa= cilitate =E2=80=9Cdeprecating=E2=80=9D the use of HE (by increasing the dela= y to an exaggerated value), without necessarily removing the code neither br= eaking apps that rely on it, when we decide that IPv6 is widely spread so an= y IPv6 failures should be noticed by end-users in order to pass the message t= o the ISP, etc.

      464XLAT has the advantage o= f
        not requiring changes to user space software,= however it requires
        per-packet translation and= does not encourage client application =E2=80=A6

      = [Jordi] I think this text will make it more accurate:
      = =E2=80=9C464XLAT has the advantage of
        not requi= ring changes to user space software, however it requires
      &n= bsp; per-packet translation in case the application is using IPv4 liter= als (or similar situations as older socket APIs) and does not encourage clie= nt application =E2=80=A6

      [Jordi] One questi= on here. Should section 7.1 also consider not just literals but old socket A= PIs?

      7.2 Host Names with Broken AAAA Record= s

      [Jordi] I think you could add in this sec= tion (or a new section), the case for broken PMTUD. We have today many situa= tions were on purpose or as a consequence of bad implementation of load-bala= ncing, ECMP, etc. You can try it with any web site from 1&1 (for example= diskmakerx.com) =E2=80=A6 just force a= reduction on your MTU I you will find that the website is not only non-acce= ssible with IPv6, but also doesn=E2=80=99t work with IPv4, because actual HE= implementations aren=E2=80=99t able to detect this problem. I think it will= be possible and of course, it will mean removing or having a different text= for =E2=80=9C9.1.  Path Maximum Transmission Unit Discovery=E2=80=9D. I= agree that because the nature of HE, active only at the initial stage, we n= eed to somehow extend the HE algorithm to test that, but I think this is the= perfect opportunity to make it, because HE is successfully implemented ever= ywhere, so I guess it will be successfully updated. Making it a =E2=80=9Cdif= ferent=E2=80=9D RFC/protocol, may not have the same impact.
      =
      [Jordi] Of course, I think is a major ISP/date center issue= , but they aren=E2=80=99t resolving it (tried for two years in this specific= case), but there are many others, worldwide, and if we believe HE is the ri= ght solution for =E2=80=9CISPs not doing correctly their job=E2=80=9D, then w= e should also support this =E2=80=9Cfailure=E2=80=9D. Again, using parameter= s, to make sure that when IPv6 is more globally spread we can =E2=80=9Cdepre= cate=E2=80=9D HE and make sure to pass the ball again to those =E2=80=9Cbad g= uys in the sense that they don=E2=80=99t do a good job, or don=E2=80=99t mak= e sure that they test correctly their deployments from the perspective of al= l kind of users=E2=80=9D.

      8.  Summary o= f Configurable Values

      [Jordi] Looking at th= is section, you=E2=80=99re saying somehow what I was expressing earlier, so m= aybe we can make it clearer and is the right place to include a must to have= all those parameters as OS configurable ones (by apps, users, network manag= ement, etc.).



      <= span>Regards,
      Jordi

      =
      -----Mensaje original-----
      De: v6ops <v6ops-bounces@ietf.org> en nombre de D= avid Schinazi <dschinazi@apple.com= >
      Responder a: <dschinazi@apple.com>
      Fecha: martes, 6 de junio d= e 2017, 2:10
      Para: IPv6 Ops WG <v6ops@ietf.org>
      Asunto: [v6ops] Updated draf= t-ietf-v6ops-rfc6555bis to version 01

      &nbs= p;  Hi v6ops,
         We have updated d= raft-ietf-v6ops-rfc6555bis to version 01.
         = ;http= s://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01
      <= /span>
         This version incorporates feedback we rec= eived on the previous version,
         and adds a= new section on "Supporting IPv6-only Networks with NAT64 and DNS64"<= br>    as these technologies require changes in the Hap= py Eyeballs stack
         on devices that do not s= upport 464XLAT.

         Please l= et us know what you think!

        &nb= sp;Thanks,
         David Schinazi



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

         &nbs= p;       Title     &n= bsp;     : Happy Eyeballs Version 2: Better Connect= ivity Using Concurrency
            = ;     Authors       &= nbsp; : David Schinazi
           &= nbsp;            = ;           Tommy Pau= ly
             Filename   &nb= sp;    : draft-ietf-v6ops-rfc6555bis-01.txt
             Pages      &nb= sp;    : 13
            &= nbsp;Date            = : 2017-06-05

         Abstract:
            Many communication proto= cols operated over the modern Internet use
        &nbs= p;   host names.  These often resolve to multiple IP add= resses, each of
            which m= ay have different performance and connectivity
        =     characteristics.  Since specific addresses or a= ddress families (IPv4
            o= r IPv6) may be blocked, broken, or sub-optimal on a network, clients<= br>       that attempt multiple connecti= ons in parallel have a higher chance of
         &= nbsp;  establishing a connection sooner.  This document speci= fies
            requirements for a= lgorithms that reduce this user-visible delay and
       &nb= sp;    provides an example algorithm.


         The IETF datatracker stat= us page for this draft is:
         https://datatrac= ker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/
         There are also htmlized versions available at:
         https://tools.ietf.org/html/draft-ietf-v6ops-rfc6= 555bis-01
         https://datatracker.ie= tf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01
         A diff from the previous version is available at:=
         https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-v6ops-rfc6555bis-01





      =    _______________________________________________    v6ops mailing list
        &n= bsp;v6ops@ietf.org
      &n= bsp;  http= s://www.ietf.org/mailman/listinfo/v6ops




      ************************= **********************
      IPv4 is over
      Are you r= eady for the new Internet ?
      http://www.consulintel.es
      The IPv6 Company<= br>
      This electronic message contains information which= may be privileged or confidential. The information is intended to be for th= e use of the individual(s) named above. If you are not the intended recipien= t be aware that any disclosure, copying, distribution or use of the contents= of this information, including attached files, is prohibited.



      ______________________= _________________________
      v6ops mailing list
      v6ops@ietf.org
      https://www.ietf.org/mailm= an/listinfo/v6ops
      = --Boundary_(ID_D7nD5xDN6AARe33Z1/zsfw)-- From nobody Wed Jun 28 01:18:44 2017 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 91AA212EBF6 for ; Wed, 28 Jun 2017 01:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDBP8vqlg_q9 for ; Wed, 28 Jun 2017 01:18:39 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3206A12EBF5 for ; Wed, 28 Jun 2017 01:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1498637912; x=1499242712; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=ni6iAO6H6Nq5gPJ0raQRfHZSA ogsVMO+ttdI1rrq4Bw=; b=d2E1RyVrcYnG9CA3SUDSPRouPuhMvEg2wGdZkTfGO xdbY96PAJzPWn9Cpr4pv6BPYhsCAIXQM5rb+Uji4QQQqWgA+l5N0c7z0oaZ5vsTY 0ujASkwgMJ4vm59yAwbuC0/gCoyN/RAHnUo1MesbxLNXEVdolHsUdqSiursVzMi1 mw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cQnDsiUnt4Y2WYNKDJ1ANk0MfccgHP1fM8MOj/npViA1scIdCsmfW7GhWTqA aSH2GZjUITGT30//Pe4YgNUBO8VsJ+b/OIydD9wRWf99d9XBlTL+ANO34 sv2iWsBfOhoqdfCtRQbfYTFXFM931yvHcuht7QVjKQFL2yeTsFl73Y=; X-MDAV-Processed: mail.consulintel.es, Wed, 28 Jun 2017 10:18:32 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 28 Jun 2017 10:18:31 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005460645.msg for ; Wed, 28 Jun 2017 10:18:30 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170628:md50005460645::QeHPTzv/yAmBZ3c1:00000JDH X-Return-Path: prvs=1352ce0bdc=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 28 Jun 2017 10:18:26 +0200 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> Thread-Topic: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> In-Reply-To: <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:18:43 -0000 Hi David, Below in-line. =20 -----Mensaje original----- De: en nombre de David Schinazi Responder a: Fecha: mi=C3=A9rcoles, 28 de junio de 2017, 4:43 Para: CC: IPv6 Ops WG Asunto: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 Hi Jordi, =20 =20 Thanks for the review! I applied your clarifications to our working cop= y. =20 =20 I don't think the document needs to mandate making constants configurab= le. Modern operating systems receive periodic software updates that can cha= nge the values as we work our way towards deprecating Happy Eyeballs. Avera= ge smartphone users shouldn't be bothered with this (if you can't configure= it you can't misconfigure it). [Jordi] I understand that, however, having parameter in the OS, it means ot= her apps can change that if they need it, even before there is an OS update= . There are many users that don=E2=80=99t update the OS, so this is not a g= ood way to ensure a correct future behaviour. Remember recent wannacry, etc= ., because outdates OS? =20 =20 As we discussed in Chicago, end users should never be made aware of IPv= 6 network failures as they are not their burden or responsibility to fix. N= etwork operators shouldn't expect their users to be the first ones to notic= e something's broken. In effect HE will be deprecated when ISPs stop routin= g IPv4. [Jordi] Yes, and not. This is the intend of HE, but if HE only sort outs pa= rt of the possible issues, then one way or the other, the user notice it = =E2=80=A6 so this is related with the suggestion for PMTUD failures to be a= lso sorted out by HE =E2=80=A6 =20 Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't curren= tly help with the issue so we marked it out of scope. Are you suggesting a = remedy? =20 [Jordi] Exactly, what I=E2=80=99m suggesting is to improve a bit more HE a= nd be able to verify the PMTUD filtering, so if IPv6 is faster than IPv4, b= ut then PMTUD is filtered, then HE can also =E2=80=9Ctake=E2=80=9D the deci= sion to use IPv4. This way we got what you wanted: User not aware of IPv6 f= ailures! I don=E2=80=99t get then the =E2=80=9Cwarning=E2=80=9D to the ISP,= but we can find a different way for that problem of course =E2=80=A6 Regarding section 7.1, old socket APIs are out of scope as HE is implem= ented above or alongside sockets. Applications using sockets directly will = not get any of these benefits. =20 [Jordi] I understand that, and I=E2=80=99m somehow ignorant about how OS do= this internally, so just wondering if we can take also the opportunity to = also allow them to use HE. [Jordi] Final comment. Do you think we can further extend HE in order to pr= ovide a way to warn the ISP that HE is forcing IPv4, because IPv6 performan= ce is low? I think we can find several ways to do that, may be a common dns= name such as he-fail.isp.com or something similar, that IF the ISP want to= implement, gets info about those failures, but the ISP is free to implemen= t it or not. This is useful for those ISPs that really do a good job monito= ring their networks, of course, but I think is a perfect opportunity from H= E instead of something different. =20 Thanks, David Schinazi =20 =20 =20 On Jun 18, 2017, at 03:57, JORDI PALET MARTINEZ wrote: =20 =20 =20 Hi David, =20 Very good job! Some comments. =20 Implementations MUST NOT wait for both families of answers to return before attempting connection establishment. If one query fails to return, or takes significantly longer to return, waiting for the second address family can significantly delay the connection establishment of the first one. Therefore, the client MUST treat DN= S resolution as asynchronous. Note that if the platform does not offe= r an asynchronous DNS API, this behavior can be simulated by making tw= o separate synchronous queries on different threads, one per address family. If the AAAA query returns first, the first IPv6 connection attempt MUST be immediately started. If the A query returns first, the client SHOULD wait for a short time for the AAAA response. This delay will be referred to as the "Resolution Delay". The RECOMMENDE= D value for the Resolution Delay is 50 milliseconds. =20 [Jordi] I=E2=80=99m not sure to fully understand this text, as somehow = seems to me contradictory. =E2=80=9Cwaiting for the second address family c= an significantly delay the connection=E2=80=9D, but then you mention 50 mil= liseconds as recommended. I think it will be nice to clarify it. Also, I th= ink the Resolution Delay should be a parameter, somehow configurable in the= OS or apps. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the u= se of HE (by increasing the delay to an exaggerated value), without necessa= rily removing the code neither breaking apps that rely on it, when we decid= e that IPv6 is widely spread so any IPv6 failures should be noticed by end-= users in order to pass the message to the ISP, etc. =20 (note that this is not referring to the sending of AAAA or A queries, but rather the addres= s of the DNS server itself) =20 [Jordi] To make it clear, maybe you want to say something such as =E2= =80=9C=E2=80=A6 but rather the protocol used for the DNS transport=E2=80=9D =20 This delay is referred to as the "Connection Attempt Delay". One recommended value for thi= s delay is 250 milliseconds. =20 [Jordi] Similar comments about the =E2=80=9CConnection Attempt Delay=E2= =80=9D as earlier: should be a parameter, somehow configurable in the OS or= apps. This would also facilitate =E2=80=9Cdeprecating=E2=80=9D the use of = HE (by increasing the delay to an exaggerated value), without necessarily r= emoving the code neither breaking apps that rely on it, when we decide that= IPv6 is widely spread so any IPv6 failures should be noticed by end-users = in order to pass the message to the ISP, etc. =20 464XLAT has the advantage of not requiring changes to user space software, however it requires per-packet translation and does not encourage client application =E2= =80=A6 =20 [Jordi] I think this text will make it more accurate: =E2=80=9C464XLAT has the advantage of not requiring changes to user space software, however it requires per-packet translation in case the application is using IPv4 literal= s (or similar situations as older socket APIs) and does not encourage clien= t application =E2=80=A6 =20 [Jordi] One question here. Should section 7.1 also consider not just li= terals but old socket APIs? =20 7.2 Host Names with Broken AAAA Records =20 [Jordi] I think you could add in this section (or a new section), the c= ase for broken PMTUD. We have today many situations were on purpose or as a= consequence of bad implementation of load-balancing, ECMP, etc. You can tr= y it with any web site from 1&1 (for example diskmakerx.com ) =E2=80=A6 just force a reduction on your MTU I you will find that= the website is not only non-accessible with IPv6, but also doesn=E2=80=99t= work with IPv4, because actual HE implementations aren=E2=80=99t able to d= etect this problem. I think it will be possible and of course, it will mean= removing or having a different text for =E2=80=9C9.1. Path Maximum Transm= ission Unit Discovery=E2=80=9D. I agree that because the nature of HE, acti= ve only at the initial stage, we need to somehow extend the HE algorithm to= test that, but I think this is the perfect opportunity to make it, because= HE is successfully implemented everywhere, so I guess it will be successfu= lly updated. Making it a =E2=80=9Cdifferent=E2=80=9D RFC/protocol, may not = have the same impact. =20 [Jordi] Of course, I think is a major ISP/date center issue, but they a= ren=E2=80=99t resolving it (tried for two years in this specific case), but= there are many others, worldwide, and if we believe HE is the right soluti= on for =E2=80=9CISPs not doing correctly their job=E2=80=9D, then we should= also support this =E2=80=9Cfailure=E2=80=9D. Again, using parameters, to m= ake sure that when IPv6 is more globally spread we can =E2=80=9Cdeprecate= =E2=80=9D HE and make sure to pass the ball again to those =E2=80=9Cbad guy= s in the sense that they don=E2=80=99t do a good job, or don=E2=80=99t make= sure that they test correctly their deployments from the perspective of al= l kind of users=E2=80=9D. =20 8. Summary of Configurable Values =20 [Jordi] Looking at this section, you=E2=80=99re saying somehow what I w= as expressing earlier, so maybe we can make it clearer and is the right pla= ce to include a must to have all those parameters as OS configurable ones (= by apps, users, network management, etc.). =20 =20 =20 Regards, Jordi =20 =20 -----Mensaje original----- De: v6ops en nombre de David Schinazi Responder a: Fecha: martes, 6 de junio de 2017, 2:10 Para: IPv6 Ops WG Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 =20 Hi v6ops, We have updated draft-ietf-v6ops-rfc6555bis to version 01. https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 =20 This version incorporates feedback we received on the previous vers= ion, and adds a new section on "Supporting IPv6-only Networks with NAT64= and DNS64" as these technologies require changes in the Happy Eyeballs stack on devices that do not support 464XLAT. =20 Please let us know what you think! =20 Thanks, David Schinazi =20 =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations of the IETF. =20 Title : Happy Eyeballs Version 2: Better Connecti= vity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-01.txt Pages : 13 Date : 2017-06-05 =20 Abstract: Many communication protocols operated over the modern Internet u= se host names. These often resolve to multiple IP addresses, each = of which may have different performance and connectivity characteristics. Since specific addresses or address families (= IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, cl= ients that attempt multiple connections in parallel have a higher chan= ce of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay = and provides an example algorithm. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-0= 1 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis-01 =20 =20 =20 =20 =20 =20 _______________________________________________ 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.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 _______________________________________________ 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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Jun 28 01:57:09 2017 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 5467D129436 for ; Wed, 28 Jun 2017 01:57:08 -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, RP_MATCHES_RCVD=-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 0EiGXgCMq6LE for ; Wed, 28 Jun 2017 01:57:05 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85AE128C83 for ; Wed, 28 Jun 2017 01:57:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e] (unknown [IPv6:2001:470:1f09:baa:fa1e:dfff:fedd:15e]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id C9BD41BC37 for ; Wed, 28 Jun 2017 08:56:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <69b6ba32-d14d-18b2-8e00-299661bb9d59@gmail.com> Date: Wed, 28 Jun 2017 09:56:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28098FFE-6506-46EC-B677-AD9E8E88F288@thehobsons.co.uk> References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> <82114BA3-4269-4056-838E-9815FA291053@thehobsons.co.uk> <69b6ba32-d14d-18b2-8e00-299661bb9d59@gmail.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:57:08 -0000 On 28 Jun 2017, at 01:44, Brian E Carpenter = wrote: > On 28/06/2017 07:53, Simon Hobson wrote: >> Brian E Carpenter wrote: >>=20 >>>> o A-flag =3D 1 (The UE/subscriber can configure itself using = SLAAC) >>>>=20 >>>> o L-flag =3D 0 (the prefix is not an on-link prefix, which means = that >>>> the UE/subscriber will NEVER assume destination addresses that >>>> match the prefix are on-link and will ALWAYS send packets to = those >>>> addresses to its default gateway.) >>>=20 >>> Hmm. Please check this assertion for a host that implements RFC8028 >>> if the LAN is multihomed. At the very least, such a host has more >>> than one "default" gateway - it has one per prefix. >>=20 >> In a multi-homed host, all this is done per-link. An address may well = be on-link for one link, and off-link for another. >=20 > Yes. But the RFC8028 case is where the *LAN* is multihomed, so the = host has > a choice of first-hop routers on the same link. It does not have a = unique > default router. Ah, OK - that working works for a single router/advertised set of = prefixes, but could be argued to be incorrectly worked where multiple = routers/prefix sets are involved. I assume that where two routers advertise non-overlapping prefix sets, = the node is supposed to combine the lists of on-link prefixes - so as = long as one router has advertised a prefix as on-link then the node can = use that. I vaguely recall having read that's how it's supposed to work. So the bit you are picking on is "to it's default gateway" whereas is = should really be "to the appropriate gateway according to route = selection rules ..." (or something like that) ? From nobody Wed Jun 28 02:29:01 2017 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 41F4112EC02; Wed, 28 Jun 2017 02:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulXACy41o_gT; Wed, 28 Jun 2017 02:28:55 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0448F12942F; Wed, 28 Jun 2017 02:28:55 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d78so45690839qkb.1; Wed, 28 Jun 2017 02:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mQP8X+fH8PB+mxsemTUwcKGhhAHzMUysbdj9fuARjPo=; b=TWUzOhI4s77LftA1YLe/rfMViMA7W7nMq2Vp+a+j63MF3+YLeBh+kyrHZaa2VE3LMf jM8OdhKGZ6gfKQtkYFzNd0CaukBiibrGEF1xnsev8+tY3EkCAiBn2g33C7Ow4BKw1GrA TyYnYqeYxlMxB2gEFW/WFccat9TgDybVpuCt5pdnP5DihAnBL5M73/8R19rX0Mt9zKOt BYHoRo+0IOx8OqsY/+YzSQv3RWH7s1aeklYey0gT3BFlixZCbnbW/bT/5VBO96ZrKFfk TKZDvavznmPGTFWO0/FvnBYWyNrhieEtn/B2AhFgjLS1x7JPbrPhhHazsOL0A8Gj6gGY 19fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mQP8X+fH8PB+mxsemTUwcKGhhAHzMUysbdj9fuARjPo=; b=uV8Tl86bEzhwoHoGGrfylST6gfDzP9KOgTLmEk6nHr48wEy3PEOWvYy6rUIUnqPe4P l4vyJzn97LVpFq/3Rr9VVP0jfswlKTw92SvcBqWtAbYhFx/TlhAorP4dqE/zI+6DcdQh kAmSAgDBjwON5AzmgHgRK1YnTFGgdDN/vvOqP6ZeP8HzjGJCPt2FhlIquye9BW0B5y9o LXNL8XMpZNjt9LbDARfRIijHtuQDU9NLkxOHv1bxd5mHU7eX8xlY/zATLBdMvVcEpO9Q LsOS6ledxTyE9nFPexU/yVQ+jNaxWODZBJGqtW5EGCxripZNIb473Nm472Dq/LzvyDDc O9Xw== X-Gm-Message-State: AKS2vOwPTm4rxnhW7ApM4j+WKqafmvhHshD8Tw9UydMoMjZqRdAw6LWP 9WMf6gZx5xUXsr0Tz61U5v0stgJLew== X-Received: by 10.55.4.139 with SMTP id 133mr10877447qke.259.1498642134141; Wed, 28 Jun 2017 02:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.135 with HTTP; Wed, 28 Jun 2017 02:28:33 -0700 (PDT) In-Reply-To: References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> From: Richard Hartmann Date: Wed, 28 Jun 2017 11:28:33 +0200 Message-ID: To: Mark Smith Cc: Lorenzo Colitti , draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:29:00 -0000 On Tue, Jun 27, 2017 at 2:12 AM, Mark Smith wrote: > Possible change is anything possible. With enough changes, IPv6 could > support 129 bit addresses, so they're possible too. That statement seems to be deliberate hyperbole, and factually impossible. > I don't think consensus has been reached on relaxing /64, so it > shouldn't be assumed to be probable. Shifting by a few orders of magnitude in likelihood, assuming things to be probable is different from writing new documents in a flexible manner. Richard From nobody Wed Jun 28 08:33:31 2017 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 0A55E129B4B for ; Wed, 28 Jun 2017 08:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ypfqNkCRB_0C for ; Wed, 28 Jun 2017 08:33:30 -0700 (PDT) Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125]) (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 D9886129B33 for ; Wed, 28 Jun 2017 08:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498664007; bh=Tjiv7wSH+KiPM//dEgy+stWQ/5R58Bn0q4+MIrhUsIk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=EKPJgQQBE2Te8zTq9MxJ9fc4PXGHNdQiAAKMy9QQ5sTY1q5s3peO910Gqw5Lr+jg5TlBuirZL/TwpRCNW2KhKIqt1OEfPn14EpUDbdP+INc1bu7mzLBRr1ZcUvkADn/jh6SvqDrdPrkBESv6+4Fm5tRPmLaSHnA0poGRD1Oeu1laleoPfYsrAo/MLtlBHsfB9UVIvhw5RzUuesQtTtXz+Z5No2qJANwytAPLRLrF6eVjafZK2sJfo/htoc2lE4idl4BnSVqMNwbSmeuU+fRdpZM/015JxpU258afofjtl0X/g01hIM4p1WKtrY8Bf4C4dGGrF597Tl5Nq/sSGhq5Gw== X-YMail-OSG: qoU0a6AVM1kKaey82es6jfMNWQA7LTSFyKjT2KJKrxfJE_UdmRgbDi9GnzV43TP hDUl5F4zjwFb9Yts8MrEVcMKzoU41jAd7SVGskrCsajIwTHFeYA5tSsWuwLR1xwdXgn7VLNPGVJl InchN4XUJCEeWy9g6H20y0elqR26u7Jys3g.d0UH4sa6NP0z0OduvO8.L6UwdD5epbzxVSXc341n eIEoimQu_T_uyR2jr_y5oYv4SWMcvVq5uTtsJRg3zpMsOEijqWYKnhObh4quawHmjAWj4DsVjbI2 xGUtYsmNa.9DOasM5oPNPIw4R1jDhKX1quTTkczh5aOWkOAzgeOwloRpbJdAScGjc.AirbLsW4Mt rvi3jF5nwcxmqyXIOzD5NFBGkbSzV8SaqzVPZZn7.9qDhWZ80UQ5P5MMifJWVB00XkxKbQaxiul4 EIT7NkTf.q0RQdvgk11SKga0M1adbyzsDQa2MoAt5iB6eZTDvJVP8xQ9woyyaAyAgA0NxLKIcbEX rS9Rjv3pNkz4c7CE8w1URKxtNe66RwPsF8Z.pEw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Jun 2017 15:33:27 +0000 Date: Wed, 28 Jun 2017 15:33:21 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: IPv6 Ops WG , "dschinazi@apple.com" Message-ID: <738488839.469942.1498664001646@mail.yahoo.com> In-Reply-To: <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_469941_1928615782.1498664001645" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Archived-At: Subject: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:33:31 -0000 ------=_Part_469941_1928615782.1498664001645 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 se= ction, I find it useful. However I don't think the below sentence from this= section is accurate. I can't think of any changes that are needed on a cli= ent device to run NAT64/DNS64.=C2=A0 While many IPv6 transition protocols have been standardized and=C2=A0 =C2= =A0deployed, most are transparent to client devices. =C2=A0The combined use= =C2=A0 =C2=A0of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution t= hat is=C2=A0 =C2=A0being deployed and requires changes in client devices. Thanks, Stephan ------=_Part_469941_1928615782.1498664001645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Hi David,

      Thanks for ad= ding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I find= it useful. However I don't think the below sentence from this section is a= ccurate. I can't think of any changes that are needed on a client device to= run NAT64/DNS64. 
      <= br id=3D"yui_3_16_0_1_1498593041138_14086">
      While many IPv6 transition protocols have been standardi= zed and
         depl= oyed, most are transparent to client devices.  The combined use
      <= div id=3D"yui_3_16_0_1_1498593041138_14089">   of NAT64 [RFC6146]= and DNS64 [RFC6147] is a popular solution that is
         being deployed and requi= res changes in client devices.

      Thanks, Stephan


      ------=_Part_469941_1928615782.1498664001645-- From nobody Wed Jun 28 08:37:34 2017 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 4D227129B33 for ; Wed, 28 Jun 2017 08:37:32 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk9g8jiLi6VO for ; Wed, 28 Jun 2017 08:37:31 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 E9AB0129B62 for ; Wed, 28 Jun 2017 08:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498664250; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3qkMYRKdNHdPkv5RtxScMEZqk8TEwraOiyNeJrt9eL0=; b=xkYhbBheW5EbUqw12B+GPwewCulaR1UUrt4yCb126oM+uuyN0c+v2bLhmwh6htUg VpZz0xo50PZ219Ls7oIGHM9nUx/MHNp19eNAotJpFU7ARFeToL3ipVqvpg1wNCsN crxtrzs8fdThJakv3zxCo500OUlyT+2jK+BQ86PYxIhGrDlRpIl/cELAwdvogNtX zYUOLmz97Ch/qsPIQpMYr3QKm0Mercf63vX7KZOCQ3am0lX+L+W78nwymk9mDt6D EyyhDfBzAWUUArIRsT+LBoj4ulUbQy/jQ6kxb0qDgGh3hAEEcNDMRugkV7/AmRFI ow2B4EzIBlo7oS6g04PfgQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 0E.5D.07017.93DC3595; Wed, 28 Jun 2017 08:37:30 -0700 (PDT) X-AuditID: 11ab0215-43f899c000001b69-45-5953cd39d8dd Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay8.apple.com (Apple SCV relay) with SMTP id F4.B4.05704.93DC3595; Wed, 28 Jun 2017 08:37:29 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qtKTkVFnp+TLBalcMMrYwA)" Received: from [100.122.139.66] (116.sub-70-213-23.myvzw.com [70.213.23.116]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OS9007UAKQGND00@nwk-phonehomebzp-sz01.apple.com>; Wed, 28 Jun 2017 08:37:29 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi X-Mailer: iPhone Mail (14G40) In-reply-to: <738488839.469942.1498664001646@mail.yahoo.com> Date: Wed, 28 Jun 2017 08:37:28 -0700 Cc: IPv6 Ops WG Message-id: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> To: "stephan.lagerholm@yahoo.com" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FCYpmt1NjjSYNUZHov5Sz+yWJw+tpfZ gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4Mq4cOcQW8FnqYqpyyYzNTDeEO9i5OSQEDCR WPrjAksXIxeHkMBaJokNU76xwyRWTtsMlTjGKDH95kewBK+AoMSPyfdYQGxmgTCJ5Y/PskIU bWOSONS0lBUkISwgLdF14S6UnS3x5FYvcxcjBwebgJbEgTVGIKaEgKzEx5VSICangI3E0RZh kGIWAVWJJY/ns0JMV5Boe9fOCLHVRmLBu39gtpDAaSaJFyfqQWwRAXuJE+vuMYJcICGwgE3i 6rlpLBMYhWYhuXQWkkshbC2J749ageIcQLa8xMHzshBhTYln9z6xQ9jaEk/eXWBdwMi2ilE4 NzEzRzczz8hQL7GgICdVLzk/dxMjKBJWM4nuYJz/yvAQowAHoxIPL8Pa4Egh1sSy4srcQ4zS HCxK4rzT5wRGCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDkKX3Wpzsv9OH/N/tXXFLNtpy9 9WhomM1ZA4VGiT9vv5/ievY06vetO2vf7co274p5bG5rteOMat2eWrbYTv4Qc+kJix3Msv2i z3q/2LJu37Q7IU3R3xZuN44IVllgn5fnUrFWaHZWBte8i3P5ghzbrG4v29e8X/XmHjMpng26 8/caXHxQws+kxFKckWioxVxUnAgAH5Lt9GUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiON3OQdfybHCkwepGfYv5Sz+yWJw+tpfZ gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4Mq4cOcQW8FnqYqpyyYzNTDeEO9i5OSQEDCR WDltM0sXIxeHkMAxRonpNz+ygyR4BQQlfky+xwJiMwuESSx/fJYVomgbk8ShpqWsIAlhAWmJ rgt3oexsiSe3epm7GDk42AS0JA6sMQIxJQRkJT6ulAIxOQVsJI62CIMUswioSix5PJ8VYrqC RNu7dkaIrTYSC979A7OFBE4zSbw4UQ9iiwjYS5xYd49xAiP/LCTHzUJyHIStJfH9UStQnAPI lpc4eF4WIqwp8ezeJ3YIW1viybsLrAsY2VYxChSl5iRWWuglFhTkpOol5+duYgSFbUNh2g7G puVWhxgFOBiVeHhXrAqOFGJNLCuuzD3EKMHBrCTCy3sGKMSbklhZlVqUH19UmpNafIhRmoNF SZxXpicoUkggPbEkNTs1tSC1CCbLxMEp1cC4/dLMTZtX3i06Jvbh3JIj5zt4TjiueMafpshW nt7x+deUbwf3aNnwyq04XVl6cZ/uoqZFF07LHQt93BJ3/fcKTZtTtRcPTKk9/IknZnl7Kxvb zcwC1rguKYeLoRv0OqpLGsO7pzDnzPFQmiKpw5XPqX3d4OtihUt8axI/XlZ98evTo4DF9RuY lFiKMxINtZiLihMBEe946lcCAAA= Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:37:32 -0000 --Boundary_(ID_qtKTkVFnp+TLBalcMMrYwA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Stephan, Have you read the rest of that section that details the changes required on client devices? Thanks, David Schinazi > On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" wrote: > > Hi David, > > Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I find it useful. However I don't think the below sentence from this section is accurate. I can't think of any changes that are needed on a client device to run NAT64/DNS64. > > While many IPv6 transition protocols have been standardized and > deployed, most are transparent to client devices. The combined use > of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is > being deployed and requires changes in client devices. > > Thanks, Stephan > > --Boundary_(ID_qtKTkVFnp+TLBalcMMrYwA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
      Hi Stephan,

      Have you read the rest of= that section that details the changes required on client devices?

      Th= anks,
      David Schinazi


      On Jun 28, 2017, at 08:33, "<= a href=3D"mailto:stephan.lagerholm@yahoo.com">stephan.lagerholm@yahoo.com" <stephan.lagerholm@yaho= o.com> wrote:

      Hi David,

      Thanks for adding the Supporting IPv6-only Networks with= NAT64 and DNS64 section, I find it useful. However I don't think the below s= entence from this section is accurate. I can't think of any changes that are= needed on a client device to run NAT64/DNS64. 

      While many IPv6 transition pro= tocols have been standardized and
         deployed, most are transparent to client devices.  = ;The combined use
        &= nbsp;of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
         bei= ng deployed and requires changes in client devices.

      Thanks, Stephan


      = --Boundary_(ID_qtKTkVFnp+TLBalcMMrYwA)-- From nobody Wed Jun 28 08:54:11 2017 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 DDF69129B31 for ; Wed, 28 Jun 2017 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 dB4TUWgBY191 for ; Wed, 28 Jun 2017 08:54:07 -0700 (PDT) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (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 869B6127601 for ; Wed, 28 Jun 2017 08:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498665246; bh=T9YAGyL7foD3jlRkGL1FRrukzt7fY4PqaPSUOwqB93U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ZeoXdHO5YdRWrKsfoMpk5yF0i6OrxLZGFqCFEU5nxdmOKEsDG5z1r6XN0ZSuCfsI9y104+lChzFzXlUQwWKgN0L+1nI8YhAWUMKHW2h/TJbZ0bWtx0Ah1CkXOn3iGZj6Uh0JX9BDY7Uluob7vyvS9v5QQM74VClAd5nh2lCOnCNSea6KyZE2eTBIJHs6qNlDl3cHYOAkeVjGJwsZGrm+bZMoCXTtlFcjGqOP8pzGlupxXjxsunb3xD/490vV69049reazqpNbtzXcS03/0o44RlZI2AmFlgPde62nPDIOAef03i27n2IxP4hryfZKHvv8ogLyIX4Y2cqEGCikDqk5w== X-YMail-OSG: bgGj6oMVM1mPpPYjbIQs0yJODvIS_j5yymxCx5ZyN5KJ2x2.Mp5Ux01WRcK5zwZ XlkY3qzIQfJE5nnRffkAEx22BEiNRvKrV7PoXfQsEP.lC6gdSjTWz6pPPcfy4yMYL1ttBT1Hj4RY W3Njp2bhFPLRrV8WSiFFuFpCzgqIzw3.n2ymOTBNkIDmkgPwjfMWF2n7Jsbe6A1G80it_BqLU5hk Dpytb315M82gdICB5NPl1xT7yZIKj6yE8glp3bHa59mNMVlO7kj9e55CiNgAT4YAy4GKtR96h2vH 7wi0zQRA.G8NjG.TAXzBZqgZD.MbxKbU.NB27hThHemOpyLvVWRV6i_1HU86_QNPABlltzj3WfGO XO.GGwwsjQB3vfWpDfISoLDT_EvSmyVTv.85YT6BvcMhFapFxzE7Lsq6AeaiKgcz1.VO_xyyA0iB ORNsl3iVZbyO7XynMRgD7W0Q9VWgz.eMkweSIbrwe6GuWjCXaE6CkNcBphYCyOfedKZq_cPg1IuK Oazb4JWA1SGfKSAwnIfWUulLlwk29amY8scdcFJvpew-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 28 Jun 2017 15:54:06 +0000 Date: Wed, 28 Jun 2017 15:54:05 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: David Schinazi Cc: IPv6 Ops WG Message-ID: <546799735.505039.1498665245952@mail.yahoo.com> In-Reply-To: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_505038_1862551051.1498665245950" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:54:09 -0000 ------=_Part_505038_1862551051.1498665245950 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, Yes I have. 464XLAT or anything else is not required to be able to run DNS6= 4/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want= to.=C2=A0 /S From: David Schinazi To: "stephan.lagerholm@yahoo.com" =20 Cc: IPv6 Ops WG Sent: Wednesday, June 28, 2017 8:37 AM Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of= draft-ietf-v6ops-rfc6555bis-01 =20 Hi Stephan, Have you read the rest of that section that details the changes required on= client devices? Thanks, David Schinazi On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" wrote: Hi David, Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 se= ction, I find it useful. However I don't think the below sentence from this= section is accurate. I can't think of any changes that are needed on a cli= ent device to run NAT64/DNS64.=C2=A0 While many IPv6 transition protocols have been standardized and=C2=A0 =C2= =A0deployed, most are transparent to client devices. =C2=A0The combined use= =C2=A0 =C2=A0of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution t= hat is=C2=A0 =C2=A0being deployed and requires changes in client devices. Thanks, Stephan =20 ------=_Part_505038_1862551051.1498665245950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Hi David,

      Yes I have. 464XLAT or anything else is not = required to be able to run DNS64/NAT64. You can run DNS64/NAT64 in combinat= ion with Dual Stack if you want to. 

      /S


      From: David Schinazi <dschinazi@apple= .com>
      To: "stephan.= lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com>
      Cc: IPv6 Ops WG <v6ops@ietf.org> Sent: Wednesday, June 2= 8, 2017 8:37 AM
      Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-= ietf-v6ops-rfc6555bis-01

      Hi Stephan,

      Have you read the rest of that section that detail= s the changes required on client devices?

      Thanks,
      David Schin= azi

      Hi David,

      Tha= nks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 secti= on, I find it useful. However I don't think the below sentence from this se= ction is accurate. I can't think of any changes that are needed on a client= device to run NAT64/DNS64. 

      While many IPv6 transition protocols have been standardized and
         de= ployed, most are transparent to client devices.  The combined use
         of = NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
        &n= bsp;being deployed and requires changes in client devices.

      Thanks, Stephan




      ------=_Part_505038_1862551051.1498665245950-- From nobody Wed Jun 28 14:56:54 2017 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 257C4126CC4 for ; Wed, 28 Jun 2017 14:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Lh1aHpOnBw for ; Wed, 28 Jun 2017 14:56:49 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 64BAC129B31 for ; Wed, 28 Jun 2017 14:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498687009; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pWa18kVmUTqAr8FIXTtWjZVbTK5RiYfwR7weAVpujCY=; b=mP1rR7eSZ++hLxTnXgpKxduPHgoDoqyVPNDsV3uZ4hq0Ifxtd+AP1aiCNErOU9ez i8sbhMdFArnl3OpR9/6W97GfHMOancGxjTYNp+FXm0fKrzBRVzobfeQDtGZXmTDL C5F86mcFIo2FQfrE1+UnALn2w5Fm6mkRmmfsv8y2Ik6iJ1w2J3hxepOc1v2IWcZ0 5IRYqcCEF7bLVIlmCW4s/T+9rXVguF3G2j0gO+1eHx0m+ziS1fdXdcSuGNacGIA8 SeN+7OxgYchOr4G3iutqZ7HxegOUvui6Gcbfll6tt3fNErE0ORHg5+H4S/SjaxR2 UJj4cYvt7zHYWf94v8F3UA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 95.2A.06195.12624595; Wed, 28 Jun 2017 14:56:49 -0700 (PDT) X-AuditID: 11973e16-8b5f19c000001833-d9-59542621d04a Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id D6.15.09344.02624595; Wed, 28 Jun 2017 14:56:49 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_x3VnLSgneTYZxUtu5zbttQ)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA00HC12ANN740@jimbu.apple.com>; Wed, 28 Jun 2017 14:56:48 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <63B9D8C9-159F-4026-9CF8-75ABB1EF7885@apple.com> Date: Wed, 28 Jun 2017 14:56:47 -0700 In-reply-to: <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> Cc: IPv6 Ops WG To: jordi.palet@consulintel.es References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAYoauoFhJp8P8th8Xf45+ZLU4f28vs wOSxbn+Ax5IlP5kCmKK4bFJSczLLUov07RK4Mhof6xes8az4f/gUUwPjN5suRk4OCQETice9 P5i6GLk4hARWM0l8XjKbESZxadZNRojEMkaJhVc6wRK8AoISPybfYwGxmQXCJLrm9DKB2EIC c5kkrvaqgdjCAtISXRfusnYxcnCwCWhJHFhjBNFqI/Fw0mcmiBI3ib8bVoLZLAKqEjsaOlhB bE4BJ4kHnb/YIMYrSLS9awdbKyIgJ3F3RSvUPTOZJB40f4E6VFbi1uxLzCAJCYE9bBKdDVfY JjAKzUJy6ywkt84CuolZQF1iypRciLC2xJN3F1ghbDWJhb8XMSGLL2BkW8UolJuYmaObmWeu l1hQkJOql5yfu4kRFAfT7cR2MD5cZXWIUYCDUYmHd8Wq4Egh1sSy4srcQ4zSHCxK4rz5cwIj hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAqlT9ZJ3VommL8idqSbapvGC/99KtN6lYq3ztp V9GnrxJFU3PWrBdw/LFl+9/iqn/9j0SmhvSXTWX7eqk4cW3jiz9WH/ydJuyU8lS6dbD+p7uY 2xTzJTVT3og5v77KXliyr35jvO5/ZfYrM6xetuh88f6kfOlFzEepyY3PBM325zwQO2aQ2aWt xFKckWioxVxUnAgArY09t2QCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUiON1OVVdRLSTS4OkzFou/xz8zW5w+tpfZ gclj3f4AjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTQ+1i9Y41nx//AppgbGbzZdjJwcEgImEpdm 3WTsYuTiEBJYxiix8EonI0iCV0BQ4sfkeywgNrNAmETXnF4mEFtIYC6TxNVeNRBbWEBaouvC XdYuRg4ONgEtiQNrjCBabSQeTvrMBFHiJvF3w0owm0VAVWJHQwcriM0p4CTxoPMXG8R4BYm2 d+1ga0UE5CTurmiFumcmk8SD5i+MEIfKStyafYl5AiP/LCTnzUJy3iygM5gF1CWmTMmFCGtL PHl3gRXCVpNY+HsRE7L4Aka2VYwCRak5iZWmeokFBTmpesn5uZsYQWHbUBixg/H/MqtDjAIc jEo8vCtWBUcKsSaWFVfmHmKU4GBWEuGtOAsU4k1JrKxKLcqPLyrNSS0+xDiREejLicxSosn5 wKjKK4k3NDExMDE2NjM2Njcxp6WwkjjvittAFwmkJ5akZqemFqQWwRzFxMEp1cC4gbVvpYP/ cmbTRLFK1R26VpKvW8S6azaa5MZxt2oxnbPap3h8W59LrZ1BooFjGWPNOp+mIxtLD/hynv3B FKx+0Sn21PtJFhMY9Rdy6vjevJWjvdB+2csrrrb266ezyX6c/NfhY+42l+fX30y+lvDy4DbD hbemb+0MbjQqeFixX3fuhXtH9+UpsRRnJBpqMRcVJwIAvOGYjs4CAAA= Archived-At: Subject: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:56:52 -0000 --Boundary_(ID_x3VnLSgneTYZxUtu5zbttQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 28, 2017, at 01:18, JORDI PALET MARTINEZ = wrote: >=20 > I don't think the document needs to mandate making constants = configurable. Modern operating systems receive periodic software updates = that can change the values as we work our way towards deprecating Happy = Eyeballs. Average smartphone users shouldn't be bothered with this (if = you can't configure it you can't misconfigure it). >=20 > [Jordi] I understand that, however, having parameter in the OS, it = means other apps can change that if they need it, even before there is = an OS update. There are many users that don=E2=80=99t update the OS, so = this is not a good way to ensure a correct future behaviour. Remember = recent wannacry, etc., because outdates OS? [DS] I don't believe the benefit of increasing HE timers outweighs the = risk of misconfiguration. The section is titled "Summary of Configurable Values" which means OS = implementers can choose to make these configurable. Some implementers = will not. > As we discussed in Chicago, end users should never be made aware of = IPv6 network failures as they are not their burden or responsibility to = fix. Network operators shouldn't expect their users to be the first ones = to notice something's broken. In effect HE will be deprecated when ISPs = stop routing IPv4. >=20 > [Jordi] Yes, and not. This is the intend of HE, but if HE only sort = outs part of the possible issues, then one way or the other, the user = notice it =E2=80=A6 so this is related with the suggestion for PMTUD = failures to be also sorted out by HE =E2=80=A6 >=20 > Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't = currently help with the issue so we marked it out of scope. Are you = suggesting a remedy? >=20 > [Jordi] Exactly, what I=E2=80=99m suggesting is to improve a bit more = HE and be able to verify the PMTUD filtering, so if IPv6 is faster than = IPv4, but then PMTUD is filtered, then HE can also =E2=80=9Ctake=E2=80=9D = the decision to use IPv4. This way we got what you wanted: User not = aware of IPv6 failures! I don=E2=80=99t get then the =E2=80=9Cwarning=E2=80= =9D to the ISP, but we can find a different way for that problem of = course =E2=80=A6 [DS] Solving PMTUD issues is currently done inside the TCP stack not HE, = I'm not certain of the value of adding complexity to HE for this. > Regarding section 7.1, old socket APIs are out of scope as HE is = implemented above or alongside sockets. Applications using sockets = directly will not get any of these benefits. >=20 > [Jordi] I understand that, and I=E2=80=99m somehow ignorant about how = OS do this internally, so just wondering if we can take also the = opportunity to also allow them to use HE. [DS] That isn't possible with current architectures, but either way = we're moving away from sockets so I don't think there's much value in = solving this issue: https://tools.ietf.org/html/draft-trammell-taps-post-sockets = > [Jordi] Final comment. Do you think we can further extend HE in order = to provide a way to warn the ISP that HE is forcing IPv4, because IPv6 = performance is low? I think we can find several ways to do that, may be = a common dns name such as he-fail.isp.com or something similar, that IF = the ISP want to implement, gets info about those failures, but the ISP = is free to implement it or not. This is useful for those ISPs that = really do a good job monitoring their networks, of course, but I think = is a perfect opportunity from HE instead of something different. [DS] That sounds reasonable to me, I think it deserves its own draft = though (and will require a serious discussion about user privacy = implications). Thanks, David Schinazi= --Boundary_(ID_x3VnLSgneTYZxUtu5zbttQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
      On Jun 28, 2017, at 01:18, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

         I don't = think the document needs to mandate making constants configurable. = Modern operating systems receive periodic software updates that can = change the values as we work our way towards deprecating Happy Eyeballs. = Average smartphone users shouldn't be bothered with this (if you can't = configure it you can't misconfigure it).

      [Jordi] I understand that, however, having parameter in the = OS, it means other apps can change that if they need it, even before = there is an OS update. There are many users that don=E2=80=99t update = the OS, so this is not a good way to ensure a correct future behaviour. = Remember recent wannacry, etc., because outdates = OS?

      [DS] I don't = believe the benefit of increasing HE timers outweighs the risk of = misconfiguration.
      The section is titled "Summary of = Configurable Values" which means OS implementers can choose to make = these configurable. Some implementers will not.

         As we discussed in = Chicago, end users should never be made aware of IPv6 network failures = as they are not their burden or responsibility to fix. Network operators = shouldn't expect their users to be the first ones to notice something's = broken. In effect HE will be deprecated when ISPs stop routing IPv4.

      [Jordi] Yes, and not. This is the intend of = HE, but if HE only sort outs part of the possible issues, then one way = or the other, the user notice it =E2=80=A6 so this is related with the = suggestion for PMTUD failures to be also sorted out by HE =E2=80=A6

         Regarding PMTUD, I'm not = sure what you're suggesting. HE doesn't currently help with the issue so = we marked it out of scope. Are you suggesting a remedy?

      [Jordi]  Exactly, what I=E2=80=99m suggesting is to = improve a bit more HE and be able to verify the PMTUD filtering, so if = IPv6 is faster than IPv4, but then PMTUD is filtered, then HE can also = =E2=80=9Ctake=E2=80=9D the decision to use IPv4. This way we got what = you wanted: User not aware of IPv6 failures! I don=E2=80=99t get then = the =E2=80=9Cwarning=E2=80=9D to the ISP, but we can find a different = way for that problem of course =E2=80=A6

      [DS] = Solving PMTUD issues is currently done inside the TCP stack not HE, I'm = not certain of the value of adding complexity to HE for this.

         Regarding section 7.1, old socket APIs are = out of scope as HE is implemented above or alongside sockets. = Applications using sockets directly will not get any of these = benefits.

      [Jordi] I understand that, and = I=E2=80=99m somehow ignorant about how OS do this internally, so just = wondering if we can take also the opportunity to also allow them to use = HE.

      [DS] That isn't possible with current = architectures, but either way we're moving away from sockets so I don't = think there's much value in solving this issue:

      [Jordi] Final comment. Do you think we can = further extend HE in order to provide a way to warn the ISP that HE is = forcing IPv4, because IPv6 performance is low? I think we can find = several ways to do that, may be a common dns name such as he-fail.isp.com or = something similar, that IF the ISP want to implement, gets info about = those failures, but the ISP is free to implement it or not. This is = useful for those ISPs that really do a good job monitoring their = networks, of course, but I think is a perfect opportunity from HE = instead of something different.

      [DS] That = sounds reasonable to me, I think it deserves its own draft though (and = will require a serious discussion about user privacy = implications).

      Thanks,
      David= Schinazi
      = --Boundary_(ID_x3VnLSgneTYZxUtu5zbttQ)-- From nobody Wed Jun 28 15:00:17 2017 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 7199912EAAD for ; Wed, 28 Jun 2017 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMWo1bTHG_Hu for ; Wed, 28 Jun 2017 15:00:15 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 1ECF1128C81 for ; Wed, 28 Jun 2017 15:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498687214; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xnDR9v3nCj7YBmaXVIpElF96DLrWb7s/UwNgE6UN2d0=; b=kov4VsWvIRIpwwmwLr2Dyyhk6xPgGlf4Jg7/W1zmT/L0ixZFC6ZEHKVMHAMm9n4k If0sSPNNqAvaiMp8dCrHbsU01jB6Fj75GIX5wjZu9pxvmlJHj6qhk5EmzQbkca99 ONt6S0YDkld0qJ0EErjIbvpbIjv4WMvHqf0INI/YkRC9NsQnx4hB7G/qusQjzm4V 9juHbKvSRfSv1PAuPWBWqrghBYLozh0vDobkXlStlAvWTHWcwScF8r6SW74f7MDA LIZ9UTDwu5R3rCqkchR4H0DZHhq5U7eP0G0ykmk9t6UCSbDueckWuHyBpY/oPaD4 wEeYxGdPY7KDiF2t+eg52g==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 84.82.06802.EE624595; Wed, 28 Jun 2017 15:00:14 -0700 (PDT) X-AuditID: 11973e13-96bff70000001a92-02-595426eed770 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay4.apple.com (Apple SCV relay) with SMTP id 96.94.01343.EE624595; Wed, 28 Jun 2017 15:00:14 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UBLDtjwEu6d0WrtP/QKx/A)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA005WO2GEJU20@koseret.apple.com>; Wed, 28 Jun 2017 15:00:14 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Wed, 28 Jun 2017 15:00:13 -0700 In-reply-to: <546799735.505039.1498665245952@mail.yahoo.com> Cc: IPv6 Ops WG To: "stephan.lagerholm@yahoo.com" References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYrvtOLSTSoPuKmcX8pR9ZLE4f28vs wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGXsm/uVsaDDs6J3/T22Bsb3Dl2MnBwSAiYS M/9uYwOxhQRWM0nM/VIKE5/XP4mli5ELKL6KUeLb0U52kASvgKDEj8n3WEBsZoEwiWsbO1gh mhczScw76ARiCwtIS3RduAsU5+BgE9CSOLDGCKLVRmLnnzeMECXZEk9u9TKD2CwCqhL9E+4y gdicQDWvmrcxQYxXkGh71w5WLyJgL3Fi3T1GiHs2MEsc+fuYCeJQWYlbsy8xgyQkBBawSTz+ s5RpAqPQLCS3zkJyK4StJfH9UStQnAPIlpc4eF4WIqwp8ezeJ3YIW1viybsLrAsY2VYxCuUm ZuboZuaZ6iUWFOSk6iXn525iBEXCdDvhHYynV1kdYhTgYFTi4WVYGxwpxJpYVlyZe4hRmoNF SZw3f05gpJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGaOVmAT/JMHOpX/tW2ixdk9P9/kHM 2rMhCe1Sn/ZOEcvcev3B4Q3HZv4/+XbdEclGaUH/pLzCd5sMinxt84t/7qrQOFe5U/DYtjM7 2nQz/8jezm35VqordvXugoZPBULzN+zfk5d+Md318QnujUs4t8TGTX6yrrOCw3hStt2P66KH H9h9+rlUT4mlOCPRUIu5qDgRAEVb0eBlAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUiON1OXfedWkikwfI5Bhbzl35ksTh9bC+z A5PHkiU/mTxmzTrMFMAUxWWTkpqTWZZapG+XwJWxb+5XxoIOz4re9ffYGhjfO3QxcnJICJhI zOufxNLFyMUhJLCKUeLb0U52kASvgKDEj8n3WEBsZoEwiWsbO1hBbCGBxUwS8w46gdjCAtIS XRfuAsU5ONgEtCQOrDGCaLWR2PnnDSNESbbEk1u9zCA2i4CqRP+Eu0wgNidQzavmbUwQ4xUk 2t61g9WLCNhLnFh3jxHing3MEkf+PmaCOFRW4tbsS8wTGPlnITlvFpLzIGwtie+PWoHiHEC2 vMTB87IQYU2JZ/c+sUPY2hJP3l1gXcDItopRoCg1J7HSRC+xoCAnVS85P3cTIyh0GwrDdzD+ W2Z1iFGAg1GJh3fFquBIIdbEsuLK3EOMEhzMSiK8FWeBQrwpiZVVqUX58UWlOanFhxilOViU xHlX3AZKCaQnlqRmp6YWpBbBZJk4OKUaGJ03Se/gbvj72Lgi5fofe5ZTM58UbHUXX7amo4zX OVjhj4959F9zxicVUr/UZI4e+vqo6an5W56Gawt5tokX3J4WvrfaP9qe/7X1VT/9V7ekHN44 bt8ea6V1TsjXwVbw2DHtheZxbh/NLt3WFVzuq/3rzdWHc6ecuLg9YHbrd0H/q9c1XV/zfFFi Kc5INNRiLipOBADWi5AGWQIAAA== Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:00:16 -0000 --Boundary_(ID_UBLDtjwEu6d0WrtP/QKx/A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT This section is titled "Supporting IPv6-only Networks with NAT64 and DNS64", dual-stack is out of scope of this section. Am I missing something? Thanks, David Schinazi > On Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.com wrote: > > Hi David, > > Yes I have. 464XLAT or anything else is not required to be able to run DNS64/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want to. > > /S > > > From: David Schinazi > To: "stephan.lagerholm@yahoo.com" > Cc: IPv6 Ops WG > Sent: Wednesday, June 28, 2017 8:37 AM > Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 > > Hi Stephan, > > Have you read the rest of that section that details the changes required on client devices? > > Thanks, > David Schinazi > > > On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com " > wrote: > >> Hi David, >> >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I find it useful. However I don't think the below sentence from this section is accurate. I can't think of any changes that are needed on a client device to run NAT64/DNS64. >> >> While many IPv6 transition protocols have been standardized and >> deployed, most are transparent to client devices. The combined use >> of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is >> being deployed and requires changes in client devices. >> >> Thanks, Stephan >> >> > > --Boundary_(ID_UBLDtjwEu6d0WrtP/QKx/A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable This section is titled "Supporting IPv6-only Networks with = NAT64 and DNS64", dual-stack is out of scope of this section.

      Am I missing = something?

      Thanks,
      David Schinazi


      On = Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.com wrote:

      Hi David,

      Yes I have. 464XLAT or anything else is not required to be = able to run DNS64/NAT64. You can run DNS64/NAT64 in combination with = Dual Stack if you want to. 

      /S


      From: = David Schinazi <dschinazi@apple.com>
      To: "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com>
      Cc: = IPv6 Ops WG <v6ops@ietf.org>
      Sent: Wednesday, June = 28, 2017 8:37 AM
      Subject: Re: Supporting IPv6-only Networks = with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

      Hi = Stephan,

      Have you read the rest = of that section that details the changes required on client devices?

      Thanks,
      David Schinazi


      On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com> wrote:

      Hi = David,

      Thanks = for adding the Supporting IPv6-only Networks with NAT64 and DNS64 = section, I find it useful. However I don't think the below sentence from = this section is accurate. I can't think of any changes that are needed = on a client device to run NAT64/DNS64. 

      While many IPv6 transition protocols have been standardized = and
         deployed, most are transparent to client = devices.  The combined use
        =  of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that = is
        =  being deployed and requires changes in client devices.

      Thanks, = Stephan




      =
      = --Boundary_(ID_UBLDtjwEu6d0WrtP/QKx/A)-- From nobody Wed Jun 28 15:00:38 2017 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 C27A112EB39 for ; Wed, 28 Jun 2017 15:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 AY2UPU0r9VFG for ; Wed, 28 Jun 2017 15:00:35 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 6570612EB35 for ; Wed, 28 Jun 2017 15:00:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 7FB4E24AE18; Wed, 28 Jun 2017 22:00:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 11CA4160047; Wed, 28 Jun 2017 22:00:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0160F16006D; Wed, 28 Jun 2017 22:00:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C0RFaU21Sr-w; Wed, 28 Jun 2017 22:00:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B553A160047; Wed, 28 Jun 2017 22:00:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4FA447CB2073; Thu, 29 Jun 2017 08:00:25 +1000 (AEST) To: "stephan.lagerholm@yahoo.com" Cc: IPv6 Ops WG , "dschinazi@apple.com" From: Mark Andrews References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> In-reply-to: Your message of "Wed, 28 Jun 2017 15:33:21 +0000." <738488839.469942.1498664001646@mail.yahoo.com> Date: Thu, 29 Jun 2017 08:00:25 +1000 Message-Id: <20170628220025.4FA447CB2073@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:00:37 -0000 In message <738488839.469942.1498664001646@mail.yahoo.com>, "stephan.lagerholm@ yahoo.com" writes: > Hi David, > Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 > section, I find it useful. However I don't think the below sentence from > this section is accurate. I can't think of any changes that are needed on > a client device to run NAT64/DNS64.  Well you obviously don't have any devices doing DNSSEC validation. DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR NODATA to NOERROR DATA by synthesizing a AAAA RRset. This from the client's perspective is not different than forging a fake AAAA RRset that is trying to hijack the traffic stream. Now very few, if any, mobile phones perform DNSSEC but there are laptop and desktop machines that do. > While many IPv6 transition protocols have been standardized and    > deployed, most are transparent to client devices.  The combined use   of > NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is   being > deployed and requires changes in client devices. > Thanks, Stephan -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 28 16:01:32 2017 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 F07C2124C27 for ; Wed, 28 Jun 2017 16:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 Ci_fX6mJ6_oN for ; Wed, 28 Jun 2017 16:01:28 -0700 (PDT) Received: from sonic307-14.consmr.mail.ne1.yahoo.com (sonic307-14.consmr.mail.ne1.yahoo.com [66.163.190.37]) (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 AEADB1298BA for ; Wed, 28 Jun 2017 16:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498690887; bh=93hQVpoWPfkFhDf62Ma6vA3NRVOp8EOrFxiLSq4Dslo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=nUgUpAiVVG2RhWukekRM6/wsUW0WSuZTwrKgUBVMMJRWMifOjS3sYfs9nEIVbZusSGtHdKlBWGqHukjqhzZ/TVYi4gxADE5upsRJ/DTZwX9GJx+UmG1McgpzWJzyVavzyASvXFWKA/DT2H+30/URTzKe2T5eKjteyeV/R14N5LYOWspwk5MwwPMxvrfLMXibCysxguo+LGrlitW3d74Z2Wavb3qCvr5ylk/LwgkMV9ODEAk9qDVki7DJHtA2Ak2o0s9u/7QKt49VN8iDiRrFzGsI+nOlRA75Ze/K2UIOI53b2/g/7xsapyg8Vz0w/M/ie3BQdyxyGWi/JtAkPNSDBw== X-YMail-OSG: aARwFMkVM1l5BA7uWOvMeej28K1NeNw4qttfFQpNWFvKwO.8i0qe9aZkYuMxKof ry17pjPnP3jbyZ0gEQWOtANSmTZCCwVmBcVe60_c.QlpHer7zcHZCKSJO0yGOzkzutul6qPhgGZI FVMfUJe6J.RXn365r8h3cgxj4ExRojjxCvsuuRNqfUpgEvtrFFQkQkcszDgE1OQC9roHrG3iYXqK A8IYhs.Dh0YTqLRVdmSwYzN71h4FRiE4BsFGz7g9nG8Oaby_S5sAl8qivlrRQ29G_XHWOhX_SXIl tWlvh1Mrd8EXRq7.MAleLy7qSCNAOzGL9SlNQJFrkdcyPwYhv1n2TUm0jiH8k1W0JFHQucWeE3yk yAUTVBuhaYsnh9JOLzOJFtZWS5dfT68xW4jwbXk55dtDwJnYeW8SBxgtbA4OVDV.Xu9IGCVVcwQs zedyK.aKBS1uuL1DIrQk1AHnMr3Twy7sn5yafIKMpMPWBB0bGv.ula.tatFo5Cd4J65JQ84KqoDe ZmX8dBIXPgpI5APdc_QW6JfSRTRGTruexe1CqDQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 28 Jun 2017 23:01:27 +0000 Date: Wed, 28 Jun 2017 22:59:03 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: David Schinazi Cc: IPv6 Ops WG Message-ID: <222564725.789104.1498690743587@mail.yahoo.com> In-Reply-To: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_789103_799626798.1498690743582" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:01:30 -0000 ------=_Part_789103_799626798.1498690743582 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair enough, the Dual stack example is not applicable in this section.=C2= =A0I'm hung up that the draft says that it requires changes on in client de= vices because it contradicts RFC 6174 section 2 that says that current IPv6= nodes can use this mechanism without requiring any modifications.=C2=A0 The first option is to locate the DNS64 function in authoritative servers for a zone. In this case, the authoritative server provides synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server. Another option is to locate the DNS64 function in recursive name servers serving end hosts. In this case, when an IPv6-only host queries the name server for AAAA RRs for an IPv4-only host, the name server can perform the synthesis of AAAA RRs and pass them back to the IPv6-only initiator. The main advantage of this mode is that current IPv6 nodes can use this mechanism without requiring any modification. From: David Schinazi To: "stephan.lagerholm@yahoo.com" =20 Cc: IPv6 Ops WG Sent: Wednesday, June 28, 2017 3:00 PM Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of= draft-ietf-v6ops-rfc6555bis-01 =20 This section is titled "Supporting IPv6-only Networks with NAT64 and DNS64"= , dual-stack is out of scope of this section. Am I missing something? Thanks,David Schinazi On Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.com wrote: Hi David, Yes I have. 464XLAT or anything else is not required to be able to run DNS6= 4/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want= to.=C2=A0 /S From: David Schinazi To: "stephan.lagerholm@yahoo.com" =20 Cc: IPv6 Ops WG Sent: Wednesday, June 28, 2017 8:37 AM Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of= draft-ietf-v6ops-rfc6555bis-01 =20 Hi Stephan, Have you read the rest of that section that details the changes required on= client devices? Thanks, David Schinazi On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" wrote: Hi David, Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 se= ction, I find it useful. However I don't think the below sentence from this= section is accurate. I can't think of any changes that are needed on a cli= ent device to run NAT64/DNS64.=C2=A0 While many IPv6 transition protocols have been standardized and=C2=A0 =C2= =A0deployed, most are transparent to client devices. =C2=A0The combined use= =C2=A0 =C2=A0of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution t= hat is=C2=A0 =C2=A0being deployed and requires changes in client devices. Thanks, Stephan =20 =20 ------=_Part_789103_799626798.1498690743582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Fair enough, the Dual stack example= is not applicable in this section. I'm hung up that the draft = says that it requires changes on in client devices because it contradicts R= FC 6174 section 2 that says that current IPv6 nodes can use this mechanism = without requiring any modifications. 


      The first option is to locate the DNS64 function in autho=
ritative
   servers for a zone.  In this case, the authoritative server provides
   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
   type of DNS64 server.

         Another option is to locate the DNS64 function in recursive name
   servers serving end hosts.  In this case, when an IPv6-only host
   queries the name server for AAAA RRs for an IPv4-only host, the name
   server can perform the synthesis of AAAA RRs and pass them back to
   the IPv6-only initiator.  The main advantage of this mode is that
   current IPv6 nodes can use this mechanism without requiring any
   modification.


      From:= David Schinazi <dschinazi@apple.com>
      To: "stephan.lagerholm@yahoo.com" <stephan.lagerho= lm@yahoo.com>
      Cc:<= /b> IPv6 Ops WG <v6ops@ietf.org>
      Sent: Wednesday, June 28, 2017 3:00 PM
      Subject: Re: Supporting IPv6-on= ly Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01<= br>

      This section is titled "Supporting IPv6-only Networks with N= AT64 and DNS64", dual-stack is out of scope of this section.

      Am I missing something?

      Thanks,
      David Schinazi


      =
      On Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.co= m wrote:

      Hi David,

      =
      Yes I have. 464XLAT or anything els= e is not required to be able to run DNS64/NAT64. You can run DNS64/NAT64 in= combination with Dual Stack if you want to. 

      /S

      <= /font>
      From: David Schinazi <dsc= hinazi@apple.com>
      To: "stephan.lagerholm@yahoo.com" <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv5001675014" ymailto=3D"mailto= :stephan.lagerholm@yahoo.com" target=3D"_blank" href=3D"mailto:stephan.lage= rholm@yahoo.com">stephan.lagerholm@yahoo.com>
      Cc: IPv6 Ops WG <v6ops@ietf.org>= ;
      Sent: Wed= nesday, June 28, 2017 8:37 AM
      Subject: Re: Supporting IPv6-only Networks with NAT64 an= d DNS64 section of draft-ietf-v6ops-rfc6555bis-01

      Hi Stephan,

      Have you read the rest of that section that details the changes requ= ired on client devices?

      Thanks,
      David Sc= hinazi


      O= n Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com> wrote:

      Hi David,

      Thanks for adding the Supporting IPv6-only Networks wit= h NAT64 and DNS64 section, I find it useful. However I don't think the belo= w sentence from this section is accurate. I can't think of any changes that= are needed on a client device to run NAT64/DNS64. 

      While many IPv6 transition protocols have been = standardized and
         deployed, most are transparent to= client devices.  The combined use
         of NAT64 [= RFC6146] and DNS64 [RFC6147] is a popular solution that is
         being deployed and requires changes in client devices= .

      =
      Thanks, Stephan





      <= br>
      ------=_Part_789103_799626798.1498690743582-- From nobody Wed Jun 28 16:10:52 2017 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 3CCA8129B45 for ; Wed, 28 Jun 2017 16:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hadTjqIOUtpI for ; Wed, 28 Jun 2017 16:10:47 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 D6F7A124C27 for ; Wed, 28 Jun 2017 16:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498691447; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2xeu5J6rE2JFTWE83zIfqI/u4oAB+AjwPc1Z4G786Z4=; b=mtsCeMpWdd7aCP1CosnKtwfaF3ZNrRbX69hD5jt6/ZenSchruB3aNNpwxeEdaA30 QZz/Yt4uNodli29Zw/1zgmtgl66doCYMv0nOyeN9TTyOqMkb1r2v6QOlxLdGBAB5 BwMRZZeBBUdw+QxLlvhkVhsW1uw+WjY49ZACBuk+s7weVd89medqdrRPCgO6NASH S76XQCSKpQrQoiPHjbZNeJ/rvXpIp+m7AWG41NSGnuufKxop++0xO6HYTQxMI7p9 ikKdL0uf1WsYV4Kx8bCo+A6XuQ5eUHoAdU60qB30+NRsQ2/syX7oQhYb7fmw6jtv oOiv1lh9VNiv0qZHgTqyRA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 18.5E.07214.77734595; Wed, 28 Jun 2017 16:10:47 -0700 (PDT) X-AuditID: 11973e11-7d2f59c000001c2e-01-595437773286 Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay8.apple.com (Apple SCV relay) with SMTP id 2B.57.05704.77734595; Wed, 28 Jun 2017 16:10:47 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nlYOuHNE9aH5074Sng38Yg)" Received: from da0602a-dhcp207.apple.com (da0602a-dhcp207.apple.com [17.226.23.207]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OSA00HWX5PZN760@jimbu.apple.com>; Wed, 28 Jun 2017 16:10:47 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <86E168AC-48C3-4F18-A823-BFD45BF75156@apple.com> Date: Wed, 28 Jun 2017 16:10:46 -0700 In-reply-to: <222564725.789104.1498690743587@mail.yahoo.com> Cc: IPv6 Ops WG To: "stephan.lagerholm@yahoo.com" References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> <222564725.789104.1498690743587@mail.yahoo.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FCYpltuHhJp8P+KusX8pR9ZLE4f28vs wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGV0HlzOWvBxAmPFwnmmDYx3Ghi7GDk5JARM JNZt2MPWxcjFISSwhkliybVTTDCJWadbmSESyxglzj7pYgdJ8AoISvyYfI8FxGYWCJP4NuMW C0TRXCaJri9zwRLCAtISXRfusnYxcnCwCWhJHFhjBNFrIzHnxR9WiJJsiSe3eplBbBYBVYm7 i+6xgdicIDXzJjJBzFeQaHvXDnapiIC9xIl19xghdk1lkfg1YQUbxKWyErdmXwK7VEJgDpvE yW0/mScwCs1CcuwsJMdC2FoS3x+1AtkcQLa8xMHzshBhTYln9z6xQ9jaEk/eXWBdwMi2ilEo NzEzRzczz0gvsaAgJ1UvOT93EyMoHqbbCe5gPL7K6hCjAAejEg/vilXBkUKsiWXFlbmHGKU5 WJTEeb9rhUQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLy7q/mNcYrUdelyoYypLv0TnrAZ FlpuTrL6197edf3bId19R19Pn5RY8m2izsvPxy/vs/p0YYPbsycPriRHP84ol134IkKn6Uad za8XPDX/i4Tnssw+lm1mpHL9ANc+rVOWC3cLbG9Oe+ps19t5/+ck0cYW3hOtzAfl9ixbq7GV cdrJm9uucz9XYinOSDTUYi4qTgQAdIiyP2gCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUiON1OVbfcPCTS4MY0ZYv5Sz+yWJw+tpfZ gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4MroPLicteDjBMaKhfNMGxjvNDB2MXJySAiY SMw63crcxcjFISSwjFHi7JMudpAEr4CgxI/J91hAbGaBMIlvM26xQBTNZZLo+jIXLCEsIC3R deEuaxcjBwebgJbEgTVGEL02EnNe/GGFKMmWeHKrlxnEZhFQlbi76B4biM0JUjNvIhPEfAWJ tnftYAeJCNhLnFh3jxFi11QWiV8TVrBBXCorcWv2JeYJjPyzkNw3C8l9ELaWxPdHrUA2B5At L3HwvCxEWFPi2b1P7BC2tsSTdxdYFzCyrWIUKErNSay00EssKMhJ1UvOz93ECArfhsK0HYxN y60OMQpwMCrx8K5YFRwpxJpYVlyZe4hRgoNZSYS34ixQiDclsbIqtSg/vqg0J7X4EKM0B4uS OO+K20ApgfTEktTs1NSC1CKYLBMHp1QDI+OtnhPZKYF5V3fMtVrfz8MmVrSTlTXxVItlRLOL xc1HP/4c4pWYJrjIL7zSxfOHl2CP/eR/HbyN2c+/8ym2dViJrjfUPW/q9TwrKyw9yFPjZLek munPG4k7uwR8JfhiS5lXvOm8LDsn77j7t3V6acpLd63b2JS0yfyxX8S0jMT4ovYgJQ4lluKM REMt5qLiRADTS+twWwIAAA== Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:10:50 -0000 --Boundary_(ID_nlYOuHNE9aH5074Sng38Yg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Absolutely, the text in RFC 6147 did not consider the scenarios described here. I'll mark this document as updating RFC 6147 to reflect that. David Schinazi > On Jun 28, 2017, at 15:59, stephan.lagerholm@yahoo.com wrote: > > Fair enough, the Dual stack example is not applicable in this section. I'm hung up that the draft says that it requires changes on in client devices because it contradicts RFC 6174 section 2 that says that current IPv6 nodes can use this mechanism without requiring any modifications. > > > The first option is to locate the DNS64 function in authoritative > servers for a zone. In this case, the authoritative server provides > synthetic AAAA RRs for an IPv4-only host in its zone. This is one > type of DNS64 server. > Another option is to locate the DNS64 function in recursive name > servers serving end hosts. In this case, when an IPv6-only host > queries the name server for AAAA RRs for an IPv4-only host, the name > server can perform the synthesis of AAAA RRs and pass them back to > the IPv6-only initiator. The main advantage of this mode is that > current IPv6 nodes can use this mechanism without requiring any > modification. > > > From: David Schinazi > To: "stephan.lagerholm@yahoo.com" > Cc: IPv6 Ops WG > Sent: Wednesday, June 28, 2017 3:00 PM > Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 > > This section is titled "Supporting IPv6-only Networks with NAT64 and DNS64", dual-stack is out of scope of this section. > > Am I missing something? > > Thanks, > David Schinazi > > >> On Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.com wrote: >> >> Hi David, >> >> Yes I have. 464XLAT or anything else is not required to be able to run DNS64/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want to. >> >> /S >> >> >> From: David Schinazi > >> To: "stephan.lagerholm@yahoo.com " > >> Cc: IPv6 Ops WG > >> Sent: Wednesday, June 28, 2017 8:37 AM >> Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 >> >> Hi Stephan, >> >> Have you read the rest of that section that details the changes required on client devices? >> >> Thanks, >> David Schinazi >> >> >> On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com " > wrote: >> >>> Hi David, >>> >>> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I find it useful. However I don't think the below sentence from this section is accurate. I can't think of any changes that are needed on a client device to run NAT64/DNS64. >>> >>> While many IPv6 transition protocols have been standardized and >>> deployed, most are transparent to client devices. The combined use >>> of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is >>> being deployed and requires changes in client devices. >>> >>> Thanks, Stephan >>> >>> >> >> > > > --Boundary_(ID_nlYOuHNE9aH5074Sng38Yg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Absolutely, the text in RFC 6147 did not consider the = scenarios described here.
      I'll mark this document as = updating RFC 6147 to reflect that.

      David Schinazi


      On = Jun 28, 2017, at 15:59, stephan.lagerholm@yahoo.com wrote:

      Fair = enough, the Dual stack example is not applicable in this = section. I'm hung up that the draft says that it requires = changes on in client devices because it contradicts RFC 6174 section 2 = that says that current IPv6 nodes can use this mechanism without = requiring any modifications. 


      The first option is to locate the DNS64 function in =
authoritative
   servers for a zone.  In this case, the authoritative server provides
   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
   type of DNS64 server.

         Another option is =
to locate the DNS64 function in recursive name
   servers serving end hosts.  In this case, when an IPv6-only host
   queries the name server for AAAA RRs for an IPv4-only host, the name
   server can perform the synthesis of AAAA RRs and pass them back to
   the IPv6-only initiator.  The main advantage of this mode is that
   current IPv6 nodes can use this mechanism without requiring any
   modification.


      From: = David Schinazi <dschinazi@apple.com>
      To: "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com>
      Cc: IPv6 Ops WG <v6ops@ietf.org>
      Sent: Wednesday, June 28, 2017 3:00 PM
      Subject: Re: Supporting IPv6-only Networks with = NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01
      =

      This section is = titled "Supporting IPv6-only Networks with NAT64 and DNS64", dual-stack = is out of scope of this section.

      Am I missing something?

      Thanks,


      =

      = --Boundary_(ID_nlYOuHNE9aH5074Sng38Yg)-- From nobody Wed Jun 28 17:37:48 2017 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 7260D126B7F for ; Wed, 28 Jun 2017 17:37:47 -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, RP_MATCHES_RCVD=-0.001, 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 9ntRgBWZzmAE for ; Wed, 28 Jun 2017 17:37:45 -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 1C8CA1200ED for ; Wed, 28 Jun 2017 17:37:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 61D19A7; Thu, 29 Jun 2017 02:37:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1498696662; bh=ndPgS0S5HaN9gxl29H/JBtQibWk7DGKuz7MmwWSr/Ag=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=j7socgjVNXxOHbE8h/iBVd4EipxMDL5/P+loZGDChcBaaNbrMmHZATYtfbxZmvm9b OC74n7EUPLgE+IZvgGsYOmKDf9XKad8vSkPlD7wpHBJLzkQuAed9kQeh7+K9a+I8mD HFMnp/UpY3cluOH7stUxipYnV3CeGRuxY1RWuT7c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4A414A6; Thu, 29 Jun 2017 02:37:42 +0200 (CEST) Date: Thu, 29 Jun 2017 02:37:42 +0200 (CEST) From: Mikael Abrahamsson To: "stephan.lagerholm@yahoo.com" cc: David Schinazi , IPv6 Ops WG In-Reply-To: <222564725.789104.1498690743587@mail.yahoo.com> Message-ID: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> <222564725.789104.1498690743587@mail.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1485285816-1498696662=:18195" Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:37:47 -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-1485285816-1498696662=:18195 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 28 Jun 2017, stephan.lagerholm@yahoo.com wrote: > Fair enough, the Dual stack example is not applicable in this > section. I'm hung up that the draft says that it requires changes on in > client devices because it contradicts RFC 6174 section 2 that says that > current IPv6 nodes can use this mechanism without requiring any > modifications.  But that doesn't mean applications running on those IPv6 nodes can access IPv4 literals. If the node also implements a CLAT, then it can. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1485285816-1498696662=:18195-- From nobody Wed Jun 28 18:46:40 2017 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 EC208127F0E for ; Wed, 28 Jun 2017 18:46:38 -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 u0JII4LamXov for ; Wed, 28 Jun 2017 18:46:37 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E93127419 for ; Wed, 28 Jun 2017 18:46:37 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id s66so42084868pfs.1 for ; Wed, 28 Jun 2017 18:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=izY2RrPwHqBk8FgAq/1ks4S3YIKD/FMIdkRFO7ee/V8=; b=DQVfxIi2/RwFkWsI31Kzh3dI+lkFbjuU/DQ3XSKO3opT/MurjpoZnSpZxD8kSSvV4Z FtrFgK0qML6FOT/J5gPpL/1sdiiTJPPmZJkpORAIMJOVgVHXdOE4/QKGU3gWQ8RrCC7i XsfCsAj8yv2AAvGOaWv0v0IeUOb9rxvEqKINOKauALuM/43nvybjwrLbNu2IxR8FuVfM mEw9rZpmENODFKs8UO4yzeo/T4W5aUax4ZHLA++YR8O7euCIwPQj7ALv7bxYn9c469oD E4KvMBh7lRkU2Mtj6oxsmB2nJXn5bxPRmOjVjBkBATLZeoBz44C03PK3S+dB8COWEnhs tP0A== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=izY2RrPwHqBk8FgAq/1ks4S3YIKD/FMIdkRFO7ee/V8=; b=gZ3MS6ATKkZuoDsu7YK2+WcerrT6Y4zCuUvyFPS2AiZzVqy+x2MGWmL4bESUJ5wQhH OERhuhKHVzKAgKGivkiQaONYRWxTamCHjRti5KBshAIQEiiC9BvxHOJXSmOIuCjlFV5M sYMlplMOA5TNlsAEUf22+GiILFG7lC1F+hFxhxdaH9hyCW0wTdijKb81py9fqUuSv1Y4 kb8WI7Gi1ks4uJ/21SZMF8PwMz113qEaJnbTm25heDmuU5Fe+noGk42UxhDdpYFUlvW2 9vMZpLjQw+Usm1LghsEQQEdwgxXkUmAgFKVM1N2Sg25/6FzkG2XTubdpwPbP8lIQfRpf 8zcg== X-Gm-Message-State: AKS2vOyTXiuCHh9n0PH6BpkFpjq+l/ErxHNG9xubouC2KGLDf2K4AaU3 qVXoi21l0Oe5w2LG X-Received: by 10.84.236.66 with SMTP id h2mr15178420pln.233.1498700796474; Wed, 28 Jun 2017 18:46:36 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id c22sm8664338pfl.97.2017.06.28.18.46.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 18:46:35 -0700 (PDT) To: v6ops@ietf.org References: <149848407068.31805.10927161382453492195@ietfa.amsl.com> <1b0ce250-78b3-b767-611a-a611757b2ed9@gmail.com> <82114BA3-4269-4056-838E-9815FA291053@thehobsons.co.uk> <69b6ba32-d14d-18b2-8e00-299661bb9d59@gmail.com> <28098FFE-6506-46EC-B677-AD9E8E88F288@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 29 Jun 2017 13:46:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <28098FFE-6506-46EC-B677-AD9E8E88F288@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 01:46:39 -0000 On 28/06/2017 20:56, Simon Hobson wrote: > > On 28 Jun 2017, at 01:44, Brian E Carpenter wrote: > >> On 28/06/2017 07:53, Simon Hobson wrote: >>> Brian E Carpenter wrote: >>> >>>>> o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) >>>>> >>>>> o L-flag = 0 (the prefix is not an on-link prefix, which means that >>>>> the UE/subscriber will NEVER assume destination addresses that >>>>> match the prefix are on-link and will ALWAYS send packets to those >>>>> addresses to its default gateway.) >>>> >>>> Hmm. Please check this assertion for a host that implements RFC8028 >>>> if the LAN is multihomed. At the very least, such a host has more >>>> than one "default" gateway - it has one per prefix. >>> >>> In a multi-homed host, all this is done per-link. An address may well be on-link for one link, and off-link for another. >> >> Yes. But the RFC8028 case is where the *LAN* is multihomed, so the host has >> a choice of first-hop routers on the same link. It does not have a unique >> default router. > > Ah, OK - that working works for a single router/advertised set of prefixes, but could be argued to be incorrectly worked where multiple routers/prefix sets are involved. > > I assume that where two routers advertise non-overlapping prefix sets, the node is supposed to combine the lists of on-link prefixes - so as long as one router has advertised a prefix as on-link then the node can use that. I vaguely recall having read that's how it's supposed to work. > > So the bit you are picking on is "to it's default gateway" whereas is should really be "to the appropriate gateway according to route selection rules ..." (or something like that) ? Yes. I also had a passing concern that the recommendation in RFC8028 might break something in this draft, but I think it's only a minor wording issue. Brian From nobody Wed Jun 28 20:01:48 2017 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 77C6F126C22 for ; Wed, 28 Jun 2017 20:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.967 X-Spam-Level: X-Spam-Status: No, score=0.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 6bG7w-zRlRv2 for ; Wed, 28 Jun 2017 20:01:45 -0700 (PDT) Received: from sonic329-22.consmr.mail.ne1.yahoo.com (sonic329-22.consmr.mail.ne1.yahoo.com [66.163.185.84]) (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 EEFF61201F8 for ; Wed, 28 Jun 2017 20:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498705304; bh=3o3/kAnCFwdXwjz3vJ80ZTBQQ84plUTc+R5Q2msQPG8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gDyfgTN/ARAmRd/U/iMnh5+oZpMudC1WfNJ8qnks8BX6equOSw6uy3moNm8BWTPVGFbL3d+d7WyNnnutIFC1Aap15A9Wc6IjsFdWiM3PI/Yxn7lqP4KRoiPiDwpvr1FTFYbiC71WO0/yVrBecuAbO4Ncr3qaBgTTaaz+O14VMKHbLRHaS6Wa94JzOGHn0jA6IiCPsz8CJTWUY+AFcuWC0Wyy6bklYucJ/Qnc0NGLAcpCDmFtNUiTZIB+6SdroGF64jxuz4gD5nJvRzDEbPxL1n9ay5rRC7pU/ZiGZhOE7ybZT0SgwxjC1rJpkJAqHou+V5/XigtLYae/2SRq1+QkeA== X-YMail-OSG: M9W1HBkVRDvvlYSmNWx2Q4K0YzqLUIFgyy7.9CftWHhRBHm37328C_gr Received: from sonic.gate.mail.ne1.yahoo.com by sonic329.consmr.mail.ne1.yahoo.com with HTTP; Thu, 29 Jun 2017 03:01:44 +0000 Date: Thu, 29 Jun 2017 03:01:42 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: Mark Andrews Cc: IPv6 Ops WG , "dschinazi@apple.com" Message-ID: <280023835.899017.1498705302254@mail.yahoo.com> In-Reply-To: <20170628220025.4FA447CB2073@rock.dv.isc.org> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_899016_135527973.1498705302249" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 03:01:46 -0000 ------=_Part_899016_135527973.1498705302249 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mark, >From: Mark Andrews >> In message <738488839.469942.14986640= 01646@mail.yahoo.com>, "stephan.lagerholm@yahoo.com" writes: >> Hi David, >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 >> section, I find it useful. However I don't think the below sentence from >> this section is accurate. I can't think of any changes that are needed o= n >> a client device to run NAT64/DNS64.=20 > >Well you obviously don't have any devices doing DNSSEC validation. >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR >NODATA to NOERROR DATA by synthesizing a AAAA RRset.=C2=A0 This from the >client's perspective is not different than forging a fake AAAA RRset >that is trying to hijack the traffic stream. This case and the remedy is already covered in RFC 6147 section 3. I don't = think it makes sense to bring it up in this draft.=20 /S | | Virus-free. www.avg.com | ------=_Part_899016_135527973.1498705302249 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Hi Mark,

      >From: Mark Andrews <marka@isc.org>
      >>= ; In message <738488839.469942.1498664001646@mail.yahoo.com>, "stepha= n.lagerholm@yahoo.com" writes:
      &g= t;> Hi David,
      >> Thanks = for adding the Supporting IPv6-only Networks with NAT64 and DNS64
      >> section, I find it useful. Howeve= r I don't think the below sentence from
      >> this section is accurate. I can't think of any changes that= are needed on
      >> a client = device to run NAT64/DNS64.
      ><= br id=3D"yui_3_16_0_1_1498704899856_3548">>Well you obviously don't have= any devices doing DNSSEC validation.
      >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR>NODATA to NOERROR DATA by synt= hesizing a AAAA RRset.  This from the
      >client's perspective is not different than forging a fake AAA= A RRset
      >that is trying to hij= ack the traffic stream.

      This case and the remedy is already covered in RFC 6147 section 3. I don= 't think it makes sense to bring it up in this draft.

      /S
       ------=_Part_899016_135527973.1498705302249-- From nobody Wed Jun 28 20:21:53 2017 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 07ADD127698 for ; Wed, 28 Jun 2017 20:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 FiSNPi-Ow-Iy for ; Wed, 28 Jun 2017 20:21:50 -0700 (PDT) Received: from sonic324-23.consmr.mail.ne1.yahoo.com (sonic324-23.consmr.mail.ne1.yahoo.com [66.163.187.85]) (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 7272B12706D for ; Wed, 28 Jun 2017 20:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498706509; bh=c40/kJN/CX6voQYai27UFoBm+1wKwFUAQlJs4sFZ5kE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RLHbUkC3DxH5oj4BsbXw8jJTik0B95LPKupLEqkDYVElu7YJE6J47a4fBNldEeYFCkCKP34Tjp42X/uTUSOKEwovf4XEdS961NEN7e0D2z39UNyjYGWlLLNFe6c4jT2gtKQ5VULw9rz1g2ezxxcqLU+w0rGzCLHhIvtXKNbGiZ/Fw2naGRDOjb9V46HbNgq4TiDA+bbz0z2Ecg1jpFzq4q5l2ACGktC5CqkhxJnxo/jhWIR0cwSUxWIYfxfIadWPW1zRAnJvUpDSvGN3zRCVR71t0ZAxolSZwar20HF7ylWbqhSjnT1me4mlyU1LyAeXKm8sq1Qdr7Q5erKNPMNDFQ== X-YMail-OSG: hAYOXMEVM1mKjJtbnj8.apWsZBCU86Z.GtCyuW1JBNkhrKdl6ZG9F_yNVhWJKmA nV.Cb3loMskndUvwGXb54CRSHjiSglBKd2ObWebn20__ETdtgmTssZWMmSU8_08CdRJSHM6xn7qn XdBCuMoMC2K9tOuuRcVx3C16joYUUkO0bXC0WL7FNtS3fSFQsa7MZ3SZC02r5mdlKcjFBQvkiOI7 7b2z6j2lWJxtyzgpzVNrVBZ4QScRiJsb_SUPMI03zKkivuiAUJA8B1MKUdEBff63K4g.NA6xqv7. zqaQvleJddCCgijcCVfU..g7m72kWeP3mAUZ4gOVWQIb8yTEqzvDf6q98A5dK0sDywLlEQ0GS1Ft LRJa8w8mRYJELKkMQ8rhWiHyntx.3_BPjAzcNlOn.Rbx2Np2RLR0lZAPpaJFMZYhpshDB66fnCAj W6MyGEiB9SEMULqVEH8FwmLnFh0knPaxt.g9ZezMCUglYg5S1ElCb4lC6WKvv2pcO0JiY8Ta5cVO YX7EPrqwQBY15qwZiXtRcA_b4UcCzwFZM.KcrPjqsXNUuv4RPTOrnnRNURLtgbUIzZd9DzA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic324.consmr.mail.ne1.yahoo.com with HTTP; Thu, 29 Jun 2017 03:21:49 +0000 Date: Thu, 29 Jun 2017 03:21:27 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: Mikael Abrahamsson Cc: David Schinazi , IPv6 Ops WG Message-ID: <361897988.912329.1498706487973@mail.yahoo.com> In-Reply-To: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> <222564725.789104.1498690743587@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_912328_490021675.1498706487971" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 03:21:52 -0000 ------=_Part_912328_490021675.1498706487971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mikael, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mikael Abrahamsson >> >> On Wed, 28 Jun 2017, stephan.lagerholm@yahoo.com wrote: >> Fair enough, the Dual stack example is not applicable in this >> section. I'm hung up that the draft says that it requires changes on in >> client devices because it contradicts RFC 6174 section 2 that says that >> current IPv6 nodes can use this mechanism without requiring any >> modifications.=20 > > > But that doesn't mean applications running on those IPv6 nodes can access > IPv4 literals. If the node also implements a CLAT, then it can. This section of the rfc6555bis draft is addressing "platforms that do not s= upport 464XLAT" so no CLAT here.=20 But we are on the same page, I'm happy that the authors are addressing the = IPv6 only use case and are extending HE to support that case too.=20 /Stephan =20 | | Virus-free. www.avg.com | ------=_Part_912328_490021675.1498706487971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Hi Mika= el,

      >     &nbs= p;  Mikael Abrahamsson <swmike@swm.pp.se>
      >>
      >= > On Wed, 28 Jun 2017, stephan.lagerholm@yahoo.com wrote:
      >> Fair enough, the Dual stack example is= not applicable in this
      >> = section. I'm hung up that the draft says that it requires changes on in
      >> client devices because it c= ontradicts RFC 6174 section 2 that says that
      >> current IPv6 nodes can use this mechanism without requ= iring any
      >> modifications.=
      >
      >
      > But tha= t doesn't mean applications running on those IPv6 nodes can access
      > IPv4 literals. If the node also impl= ements a CLAT, then it can.

      This section of the rfc6555bis draft = is addressing "platforms that do not support 464XLAT" so no CLAT here.
      =
      But we are on= the same page, I'm happy that the authors are addressing the IPv6 only use= case and are extending HE to support that case too.

      /Stephan

      <= div class=3D"qtdSeparateBR">



      =

      =09 =09=09 =09
      3D""Vi= rus-free. www.avg.com =09=09
      ------=_Part_912328_490021675.1498706487971-- From nobody Wed Jun 28 21:14:42 2017 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 D026D127871 for ; Wed, 28 Jun 2017 21:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PYVSSHg0d2O0 for ; Wed, 28 Jun 2017 21:14:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD8A127775 for ; Wed, 28 Jun 2017 21:14:40 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BFE57349315; Thu, 29 Jun 2017 04:14:37 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7EA50160047; Thu, 29 Jun 2017 04:14:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 664DE160070; Thu, 29 Jun 2017 04:14:37 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7pxI1kwBY2AR; Thu, 29 Jun 2017 04:14:37 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F9A8160047; Thu, 29 Jun 2017 04:14:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <280023835.899017.1498705302254@mail.yahoo.com> Date: Thu, 29 Jun 2017 14:14:33 +1000 Cc: IPv6 Ops WG , "dschinazi@apple.com" Content-Transfer-Encoding: quoted-printable Message-Id: <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> To: "stephan.lagerholm@yahoo.com" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 04:14:42 -0000 > On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote: >=20 > Hi Mark, >=20 > >From: Mark Andrews > >> In message <738488839.469942.1498664001646@mail.yahoo.com>, = "stephan.lagerholm@yahoo.com" writes: > >> Hi David, > >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and = DNS64 > >> section, I find it useful. However I don't think the below sentence = from > >> this section is accurate. I can't think of any changes that are = needed on > >> a client device to run NAT64/DNS64.=20 > > > >Well you obviously don't have any devices doing DNSSEC validation. > >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR > >NODATA to NOERROR DATA by synthesizing a AAAA RRset. This from the > >client's perspective is not different than forging a fake AAAA RRset > >that is trying to hijack the traffic stream. >=20 > This case and the remedy is already covered in RFC 6147 section 3. I = don't think it makes sense to bring it up in this draft.=20 RFC 6147 states that end devices need to be upgraded. Yes this is in contradiction to itself where it states that they don=E2=80=99t= need to be upgraded. Section 5.5. The disadvantage to this approach is that an end point that is translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, this strategy means that any end point that wishes to do validation in a NAT64 context must be upgraded to be translation-aware as well. Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY and in doing so completely defeating the purpose of the =E2=80=9CMUST = NOT=E2=80=9D on CD=3D1 which is to get answers which are incorrectly being rejected by the upstream validating resolver. "then vDNS64 MAY perform validation,=E2=80=9D Then you have changes to the purpose of CD which don=E2=80=99t work with TTL=3D0 answers. The whole IETF seems to think that DNS64/NAT64 works well. It doesn=E2=80=99t when you need to use the protections that DNSSEC provides. It works ok if everything else is correctly configured and there are no active attacks on the recursive DNS servers happening. >=20 > /S >=20 > Virus-free. www.avg.com --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 28 21:52:55 2017 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 E95E312704A for ; Wed, 28 Jun 2017 21:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 wqV0asJOonrK for ; Wed, 28 Jun 2017 21:52:50 -0700 (PDT) Received: from sonic328-12.consmr.mail.ne1.yahoo.com (sonic328-12.consmr.mail.ne1.yahoo.com [66.163.191.35]) (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 D796612025C for ; Wed, 28 Jun 2017 21:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498711968; bh=FjqulToIAZmWkLhtZdAYzRMfyUQqulQUhiQjjw4gju4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=R/EGRxeFU7AbcdIAciqVk9ngn66I5gSN2LENvMkOFr70/4gzngCbiSOE2RrvSj4WNOKmtpBy3nFKjoRWBUZ0m5kSnzAq9cph3Kk/IVFNRYg34Zcs2VXHW/RmEoZ0Q2KdGFHUZmjMfzAd1QthlXUW0KBXpxCMsj2DHFOSUsZdhMDC518DOc8j9hU8qgMeNDwStytGfJkt92zlGGh6qpVdL14ibJ5b/GLbdw813+ZcO5ws67Ft2ASDG0U57bWbO0DYGREE2GUeZ6k9eu4Ma1Ry0ooKP2Vqb2G77n2HeDZO3FSl4FMEFS+Cz8AuvHpgisrTzhnMfBLb+YcwvebNMuswjw== X-YMail-OSG: rZC7OW0VM1kvLqWblh9om0VXyzr6FQoOii8NEbJNGGJ8DKuSI5Egt8bQuCEo9i6 fePeD3TolugohwZpPv6C3J.7Xdw328QI1od5HgMGduOg0WR9TtKd5BJP.FyR2dPm4XUIKrCgWI1q MuTJATo5UOdei3ZQf6UQHe7XE.RiSXyt6oPpdOmeOBIVfDIkZ.9auB3cuS_kChsekmNH0E6rEetX FuOo0na9TnkFGVv3ZAsY6rpTGPTg4w9Y_h20RptiwidY3nIbi8vN9VxoAeT7Ex9bQQPhx.LAvAha 7nL5j8_UoAUA7xuDp8aO7eO78ejpaSlWslXQIiQUyITT4MU02z5L5Jyfszz5IKK5nJFSsgQIUcNK A_ISbaUOSWj7E9e7Z4g.WqHQR3G0ImLzmU1o_9BxBUZ1c2IFLJlZA.k3MUm.qKMzI9gxs0UvGjLP u2Cdj.zU5TZLgDpe8nFIBOziDm2vBrnQQ7a0QeE2fSBjdwcjBIieul8D_KpwWVBOEI6R7IHxIx.2 srFXgMrE8n61V6r9SXhLtZPIzRJOpG4JX5W8FWs53LoRD7NCI5TpCQfbLkOhjkGaRR_ML7OvgmJ7 0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic328.consmr.mail.ne1.yahoo.com with HTTP; Thu, 29 Jun 2017 04:52:48 +0000 Date: Thu, 29 Jun 2017 04:52:47 +0000 (UTC) From: "stephan.lagerholm@yahoo.com" Reply-To: "stephan.lagerholm@yahoo.com" To: Mark Andrews Cc: IPv6 Ops WG , "dschinazi@apple.com" Message-ID: <901072900.951551.1498711968004@mail.yahoo.com> In-Reply-To: <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_951549_2141093257.1498711968002" X-Mailer: WebService/1.1.9978 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 04:52:54 -0000 ------=_Part_951549_2141093257.1498711968002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mark, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mark Andrews =20 > >> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote: >> >> Hi Mark, >> >> >From: Mark Andrews >> >> In message <738488839.469942.1498664001646@mail.yahoo.com>, "stephan.= lagerholm@yahoo.com" writes: >> >> Hi David, >> >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DN= S64 >> >> section, I find it useful. However I don't think the below sentence f= rom >> >> this section is accurate. I can't think of any changes that are neede= d on >> >> a client device to run NAT64/DNS64. >> > >> >Well you obviously don't have any devices doing DNSSEC validation. >> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR >> >NODATA to NOERROR DATA by synthesizing a AAAA RRset.=C2=A0 This from th= e >> >client's perspective is not different than forging a fake AAAA RRset >> >that is trying to hijack the traffic stream. >> >> This case and the remedy is already covered in RFC 6147 section 3. I don= 't think it makes sense to bring it up in this draft. > >RFC 6147 states that end devices need to be upgraded.=C2=A0 Yes >this is in contradiction to itself where it states that they don=E2=80=99t= need >to be upgraded. > >Section 5.5. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The disadvantage to this approach is that a= n end point that is >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 translation-oblivious but security-aware an= d validating will not >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be able to use the DNS64 functionality.=C2= =A0 In this case, the end >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 point will not have the desired benefit of = NAT64.=C2=A0 In effect, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this strategy means that any end point that= wishes to do >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validation in a NAT64 context must be upgra= ded to be >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 translation-aware as well. > >Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY >and in doing so completely defeating the purpose of the =E2=80=9CMUST NOT= =E2=80=9D >on CD=3D1 which is to get answers which are incorrectly being rejected >by the upstream validating resolver. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "then vDNS64 MAY perform validation,=E2=80= =9D > >Then you have changes to the purpose of CD which don=E2=80=99t work >with TTL=3D0 answers. > >The whole IETF seems to think that DNS64/NAT64 works well.=C2=A0 It >doesn=E2=80=99t when you need to use the protections that DNSSEC >provides.=C2=A0 It works ok if everything else is correctly configured and >there are no active attacks on the recursive DNS servers happening. I agree that it does not work well if you validate on the stub resolver sid= e. I can imagine that you could do an RFC7050 query within your validator, = strip the pref64 and then validate the A record. I still think it should be= outside the scope of this draft to tackle DNSSEC related issues when using= DNS64. It is not going to add any clarity to Happy Eyeballs to have text a= round DNSSEC related issues that remains unchanged with or without this dra= ft being implemented. I'm happy to work on an rfc6174bis with you.=20 /Stephan ------=_Part_951549_2141093257.1498711968002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Hi Mark,
      <= /span>
      = >        Mark Andrews <marka@isc.o= rg>
      >
      >> On 29 Jun 2017, at 1:01 pm, stephan.lagerhol= m@yahoo.com wrote:
      >>
      >> Hi Mark,
      >>
      &g= t;> >From: Mark Andrews <marka@isc.org>
      >> >> In message <738488839.469942.149866= 4001646@mail.yahoo.com>, "stephan.lagerholm@yahoo.com" writes:
      >> >> Hi David,
      >> >> Thanks for adding the Support= ing IPv6-only Networks with NAT64 and DNS64
      >> >> section, I find it useful. However I don't thi= nk the below sentence from
      >&g= t; >> this section is accurate. I can't think of any changes that are= needed on
      >> >> a cl= ient device to run NAT64/DNS64.
      &= gt;> >
      >> >Well yo= u obviously don't have any devices doing DNSSEC validation.
      >> >DNS64 breaks DNSSEC as it changes t= he DNS responses from NOERROR
      >= ;> >NODATA to NOERROR DATA by synthesizing a AAAA RRset.  This f= rom the
      >> >client's per= spective is not different than forging a fake AAAA RRset
      >> >that is trying to hijack the traffic s= tream.
      >>
      >> This case and the remedy is already cover= ed in RFC 6147 section 3. I don't think it makes sense to bring it up in th= is draft.
      >
      >RFC 6147 states that end devices need to be upg= raded.  Yes
      >this is in c= ontradiction to itself where it states that they don=E2=80=99t need
      >to be upgraded.
      >
      >= Section 5.5.
      >
      >      The disadvant= age to this approach is that an end point that is
      >      translation-oblivious b= ut security-aware and validating will not
      >      be able to use the DNS64 functi= onality.  In this case, the end
      >      point will not have the desired bene= fit of NAT64.  In effect,
      &g= t;      this strategy means that any end point tha= t wishes to do
      >  &n= bsp;   validation in a NAT64 context must be upgraded to be
      >      tra= nslation-aware as well.
      >
      >Then you have 5.5.3, turn a DNSSE= C MUST NOT into a MAY
      >and in = doing so completely defeating the purpose of the =E2=80=9CMUST NOT=E2=80=9D=
      >on CD=3D1 which is to get an= swers which are incorrectly being rejected
      >by the upstream validating resolver.
      >
      > =      "then vDNS64 MAY perform validation,=E2=80=9D
      >
      >Then you have changes to the purpose of CD which don=E2=80=99= t work
      >with TTL=3D0 answers.<= br id=3D"yui_3_16_0_1_1498708418212_6548">>
      >The whole IETF seems to think that DNS64/NAT64 works well= .  It
      >doesn=E2=80=99t wh= en you need to use the protections that DNSSEC
      >provides.  It works ok if everything else is correct= ly configured and
      >there are n= o active attacks on the recursive DNS servers happening.

      I agree = that it does not work well if you validate on the stub resolver side. I can= imagine that you could do an RFC7050 query within your validator, strip th= e pref64 and then validate the A record. I still think it should be outside= the scope of this draft to tackle DNSSEC related issues when using DNS64. = It is not going to add any clarity to Happy Eyeballs to have text around DN= SSEC related issues that remains unchanged with or without this draft being= implemented. I'm happy to work on an rfc6174bis with you.

      /Step= han
      ------=_Part_951549_2141093257.1498711968002-- From nobody Wed Jun 28 21:58:32 2017 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 5A4A8127866 for ; Wed, 28 Jun 2017 21:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnXrWu1aIb8G for ; Wed, 28 Jun 2017 21:58:29 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6097D12704A for ; Wed, 28 Jun 2017 21:58:29 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id 84so25300888ybe.0 for ; Wed, 28 Jun 2017 21:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B47PjY+M8aAlxHPJfwvULJ9vam2C42+aUknzyeSrrQU=; b=dg/zuRu4p4T3bIaIK9EXOYoQHee4liXNbyHtH3n47XW8yaztfdOzPHJLI4Wk/6KGeR o1OhSxmALlPZTBFwY/5/W+jkZgeUiVTiV2KXD2xk3HsID9n3T0xSKbkNFcrfBqaHizWt /UWo8VrlrPSvM0R0YatTJOMXN9nW2oy9mQnH3v+/IA8MhzcYONy+OVDj81iu32a/6lpw OPhHoufYUXf/6ekJD+cIDczbRUPB3jbavHchqNbDq9oZvnKvHix93yL9gIz4LxoJTrkT 0SKQ4ua1QRtk/8P+6dDuHOF21P9zhGsP/gMqeW+cn7sC/brcRYRj2gQKfDkCpkOEt8wm 1VRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B47PjY+M8aAlxHPJfwvULJ9vam2C42+aUknzyeSrrQU=; b=S7WmUhDdoB1AXPGfZ2x+muGx+DL5Zp2Pq5J1iz24hEqXJwFAJQFhKX15slVnKH6e9n n/DRH1iOY6RbUF65bYSFc3sKRdsADkGuUhiWRs9fZR4mJFsS7f0fhm9T/gZu8Wn4ZrUP bJ5PZQyr6s4ccWYOYGWXnNpYnXih04Gz6LUhv6BInng0heahbLuZZCj8bhS1N9DGQ9ax 5HiTjWGjEkMiO9wwK2RALWiNZHet/HI/XpOUmQlzHzfv8teIpmn6qbsKgCiAcGVO/7Gc Uw14sYLmsu5KnjbzTS+ILlPKmAwuEzByBOaXaRncKW+GhJkp9Icu3ra/RWUqD26bWf96 tbrg== X-Gm-Message-State: AKS2vOylwd5PLNMlpIOMqyN99HxWfaNq4nnh84PNzEdC0UPBBpleQ0An Vyh/PvGA1GuHGfPAb0azCvMsAqg9h7su X-Received: by 10.37.45.5 with SMTP id t5mr10991003ybt.36.1498712308369; Wed, 28 Jun 2017 21:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.59.85 with HTTP; Wed, 28 Jun 2017 21:58:07 -0700 (PDT) In-Reply-To: <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> From: Erik Kline Date: Thu, 29 Jun 2017 13:58:07 +0900 Message-ID: To: Mark Andrews Cc: "stephan.lagerholm@yahoo.com" , IPv6 Ops WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1b2838c9450c055312265a" Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 04:58:31 -0000 --94eb2c1b2838c9450c055312265a Content-Type: multipart/alternative; boundary="94eb2c1b2838c35c5f055312268d" --94eb2c1b2838c35c5f055312268d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > The whole IETF seems to think that DNS64/NAT64 works well. It > doesn=E2=80=99t when you need to use the protections that DNSSEC > provides. It works ok if everything else is correctly configured and > there are no active attacks on the recursive DNS servers happening. > When the *end client* needs to do DNSSec. If the recursive servers unconditionally do DNSSec on the clients' behalf for NAT64/DNS64 networks, that seems like a reasonable operational SHOULD/MUST we can mention. --94eb2c1b2838c35c5f055312268d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      The whole IETF seems to think that DNS64/NAT64 w= orks well.=C2=A0 It
      doesn=E2=80=99t when you need to use the protections that DNSSEC
      provides.=C2=A0 It works ok if everything else is correctly configured and<= br> there are no active attacks on the recursive DNS servers happening.

      When the *end client* needs to do DNSSec.=C2= =A0 If the recursive servers unconditionally do DNSSec on the clients' = behalf for NAT64/DNS64 networks, that seems like a reasonable operational S= HOULD/MUST we can mention.
      --94eb2c1b2838c35c5f055312268d-- --94eb2c1b2838c9450c055312265a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgnYN6xXe0CMna7Eyf6Db/1OCipRfDe+Gy 3lfmHXSV6JswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjI5 MDQ1ODI4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABoa++ieS4XIu9fzwyYj+I1EWggQlnsqRKKLTn1ewBKm7k8+3w36 ro9sPQNPNgit4OSNrY5T8NNvlqNYy/NNa3fnHj9WmNUof2m94KuVfEJyqPjjACdJcalH7+9ooLwo WV9Tb0OVymMVo2F+FzqJcnJvqWa6nCtymmWauoPLFYu63TUcuYL+YmVhwMbA3jbDS8I1mEtdepvx /BQY1BfpOZWKJxp9GxDunA8V+4E+JOfeISNucYgw0UsrVDDYoNr9isf1aMuAyWY6k+lIxdW3nA09 Urqs3APr6+QvocQGaIGfG9Xd58nBfT0BGgOdZYJZ8j7ZYENWNhPi9K6frCdMMLI= --94eb2c1b2838c9450c055312265a-- From nobody Wed Jun 28 22:17:50 2017 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 8AB801273B1 for ; Wed, 28 Jun 2017 22:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GXYJYlevXNJN for ; Wed, 28 Jun 2017 22:17:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DAA12704A for ; Wed, 28 Jun 2017 22:17:47 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 64CDA349442; Thu, 29 Jun 2017 05:17:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 53083160047; Thu, 29 Jun 2017 05:17:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 401D9160070; Thu, 29 Jun 2017 05:17:44 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JG3vF0Q0l5GZ; Thu, 29 Jun 2017 05:17:44 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id EC6C9160047; Thu, 29 Jun 2017 05:17:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 38EB67D005C0; Thu, 29 Jun 2017 15:17:41 +1000 (AEST) To: Erik Kline Cc: "stephan.lagerholm@yahoo.com" , IPv6 Ops WG From: Mark Andrews References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> In-reply-to: Your message of "Thu, 29 Jun 2017 13:58:07 +0900." Date: Thu, 29 Jun 2017 15:17:41 +1000 Message-Id: <20170629051741.38EB67D005C0@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:17:48 -0000 In message , Erik Kline writes: > > > > The whole IETF seems to think that DNS64/NAT64 works well. It > > doesn’t when you need to use the protections that DNSSEC > > provides. It works ok if everything else is correctly configured and > > there are no active attacks on the recursive DNS servers happening. > > > > When the *end client* needs to do DNSSec. If the recursive servers > unconditionally do DNSSec on the clients' behalf for NAT64/DNS64 networks, > that seems like a reasonable operational SHOULD/MUST we can mention. The real problem is the choice to promote DNS64/NAT64. Just because it works "well enough" in the cellular envionment *where there is little to no DNSSEC being used (read as epsilon)*, that is not a reason to promote it as a *general* solution for IPv6-only networks. Doing that will come back to bite us in the future. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 28 22:30:56 2017 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 0BC6012871F for ; Wed, 28 Jun 2017 22:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gmxWAKhZ7bXH for ; Wed, 28 Jun 2017 22:30:53 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0C7A412025C for ; Wed, 28 Jun 2017 22:30:53 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w126so71293954wme.0 for ; Wed, 28 Jun 2017 22:30:52 -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=nM4eSVtT2XNG6Bg+LU1TQjqm8Am/prkAP/3ljk1LvlA=; b=RNQ/bK89Rv7HZmHGxJGMK17EbQQcFSVYAKSoL+f2xmIi4r5oOLXKhIcJebiGmnfmaG Xiy2BRd0Nhrd6AzHYlhq0+1S1k/GcVwXx7hbsuU6iBjC9LIAHcD7KFsXj4sdB153kQz5 HNpYpRiPcf2UoNQczoHIKLE29Fds6YdbAPWUhw9z092VPJxXfY3Qadqfu8l41lHJvdJk 1+tD1R2vgKujy4DA4Ss3CQJWcTjEQ8bPzB+RdB/8xTFyiJztVltmVFyHH64BXwy+chNW Ap0s0mo7NT2CHSxFLFb/XyYY2YKa8FnxxS6QUTJ1nua9WkHZmkgqlAc00y5c1gHKbHDC l77Q== 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=nM4eSVtT2XNG6Bg+LU1TQjqm8Am/prkAP/3ljk1LvlA=; b=jetG7RZPJByf+pqlEhKy1EXjOYwFxYAUXlNVOmft5qvwIwqPVciha0AD4zfKIoPOLm jp7DeqOGBKKAvT18R+NIudV1aCgI5fVdDZzG6CP8PyKr4KPmmdYK4ufOMePOIQzQF+Uc tiRMXnnfMkC2jMcZisZO+UC15efymkdZn0u16F0qEZoEUCUChLSLBsHxnaV9MJ0DqNg5 4sFQ8R/URanMP2N8L+1zvt7dmqC+gUAtgADQPyP8EWn6iTX3HGvvY5T6UIa82fktEfGO j83a3Kel9Gw/aLsXeT09beKuUfOx0aigocuzhuxsN2v634zJtF9DD235HvJa15liYu9i gR4A== X-Gm-Message-State: AKS2vOxAViCDh3N4xs/KqV0JO+TNFdaqw3FQsqCcPy6df4QGPO4DWsfi /C0soHikMICGgtufSEQ= X-Received: by 10.28.10.194 with SMTP id 185mr10190783wmk.119.1498714251507; Wed, 28 Jun 2017 22:30:51 -0700 (PDT) Received: from 226.66.20.149.in-addr.arpa (226.66.20.149.in-addr.arpa. [149.20.66.226]) by smtp.gmail.com with ESMTPSA id d1sm5477140wra.43.2017.06.28.22.30.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 22:30:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <20170629051741.38EB67D005C0@rock.dv.isc.org> Date: Thu, 29 Jun 2017 07:30:43 +0200 Cc: Erik Kline , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> <20170629051741.38EB67D005C0@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:30:55 -0000 On Jun 29, 2017, at 7:17 AM, Mark Andrews wrote: > The real problem is the choice to promote DNS64/NAT64. Just because > it works "well enough" in the cellular envionment *where there is > little to no DNSSEC being used (read as epsilon)*, that is not a > reason to promote it as a *general* solution for IPv6-only networks. > Doing that will come back to bite us in the future. I'm not sure I disagree, in the sense that the preferred approach would = be to move the application to IPv6. That said, isn't the point that it = hasn't yet been moved but the network is? The only option other than = "translate" is "don't turn off IPv4". I think that will be a common = solution. But when the network is turning off IPv4 and an IPv6-capable = option isn't available for an application, I think they're not going to = ask your opinion. They're going to do something that works for them.= From nobody Wed Jun 28 22:43:11 2017 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 5F675129562 for ; Wed, 28 Jun 2017 22:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 kt1mlpTBcrHw for ; Wed, 28 Jun 2017 22:43:07 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B977012025C for ; Wed, 28 Jun 2017 22:43:06 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id DEF92403A9; Thu, 29 Jun 2017 07:43:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id A33651A0072; Thu, 29 Jun 2017 07:43:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0352.000; Thu, 29 Jun 2017 07:43:04 +0200 From: To: David Schinazi , "stephan.lagerholm@yahoo.com" CC: IPv6 Ops WG Thread-Topic: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 Thread-Index: AQHS8CPu2ekPLtVzQE2/MQ9kG7wBJaI6RxYAgAAEpICAAGZMgIAAEHCAgAADRgCAAI0pYA== Date: Thu, 29 Jun 2017 05:43:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009FFCCBF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <546799735.505039.1498665245952@mail.yahoo.com> <222564725.789104.1498690743587@mail.yahoo.com> <86E168AC-48C3-4F18-A823-BFD45BF75156@apple.com> In-Reply-To: <86E168AC-48C3-4F18-A823-BFD45BF75156@apple.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009FFCCBFOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:43:10 -0000 --_000_787AE7BB302AE849A7480A190F8B933009FFCCBFOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, I don't think your document is updating RFC6147. Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de David Schinazi Envoy=E9 : jeudi 29 juin 2017 01:11 =C0 : stephan.lagerholm@yahoo.com Cc : IPv6 Ops WG Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 sect= ion of draft-ietf-v6ops-rfc6555bis-01 Absolutely, the text in RFC 6147 did not consider the scenarios described h= ere. I'll mark this document as updating RFC 6147 to reflect that. David Schinazi On Jun 28, 2017, at 15:59, stephan.lagerholm@yahoo.com wrote: Fair enough, the Dual stack example is not applicable in this section. I'm = hung up that the draft says that it requires changes on in client devices b= ecause it contradicts RFC 6174 section 2 that says that current IPv6 nodes = can use this mechanism without requiring any modifications. The first option is to locate the DNS64 function in authoritative servers for a zone. In this case, the authoritative server provides synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server. Another option is to locate the DNS64 function in recursive name servers serving end hosts. In this case, when an IPv6-only host queries the name server for AAAA RRs for an IPv4-only host, the name server can perform the synthesis of AAAA RRs and pass them back to the IPv6-only initiator. The main advantage of this mode is that current IPv6 nodes can use this mechanism without requiring any modification. ________________________________ From: David Schinazi > To: "stephan.lagerholm@yahoo.com" > Cc: IPv6 Ops WG > Sent: Wednesday, June 28, 2017 3:00 PM Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of = draft-ietf-v6ops-rfc6555bis-01 This section is titled "Supporting IPv6-only Networks with NAT64 and DNS64"= , dual-stack is out of scope of this section. Am I missing something? Thanks, David Schinazi On Jun 28, 2017, at 08:54, stephan.lagerholm@yahoo.com wrote: Hi David, Yes I have. 464XLAT or anything else is not required to be able to run DNS6= 4/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want= to. /S ________________________________ From: David Schinazi > To: "stephan.lagerholm@yahoo.com" > Cc: IPv6 Ops WG > Sent: Wednesday, June 28, 2017 8:37 AM Subject: Re: Supporting IPv6-only Networks with NAT64 and DNS64 section of = draft-ietf-v6ops-rfc6555bis-01 Hi Stephan, Have you read the rest of that section that details the changes required on= client devices? Thanks, David Schinazi On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" > wrote: Hi David, Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64 se= ction, I find it useful. However I don't think the below sentence from this= section is accurate. I can't think of any changes that are needed on a cli= ent device to run NAT64/DNS64. While many IPv6 transition protocols have been standardized and deployed, most are transparent to client devices. The combined use of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is being deployed and requires changes in client devices. Thanks, Stephan --_000_787AE7BB302AE849A7480A190F8B933009FFCCBFOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      Hi David, 

       

      I don’t think your docume= nt is updating RFC6147.

       

      Cheers,

      Med

       

      De : v6op= s [mailto:v6ops-bounces@ietf.org] De la part de David Schinazi
      Envoy=E9 : jeudi 29 juin 2017 01:11
      =C0 : stephan.lagerholm@yahoo.com
      Cc : IPv6 Ops WG
      Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 an= d DNS64 section of draft-ietf-v6ops-rfc6555bis-01

       

      Absolutely, the text in RFC 6147 did not consid= er the scenarios described here.

      I'll mark this document as updating RFC 6147 to refl= ect that.

       

      David Schinazi

       

       

      On Jun 28, 2017, at 15:59, stephan.lagerholm@yahoo.com wrote:

       

      Fair enoug= h, the Dual stack example is not applicable in this section. I'm hung = up that the draft says that it requires changes on in client devices because it contradicts RFC 6174 section 2 that says that current IPv6 node= s can use this mechanism without requiring any modifications. 

       = ;

       = ;

      The first option is to locate the DNS64 function in authori=
tative
         servers for a zone.  In t=
his case, the authoritative server provides
         synthetic AAAA RRs for an IPv4=
-only host in its zone.  This is one
         type of DNS64 server.
         Another option is to locate the DNS64 function=
 in recursive name
         servers serving end hosts.&nbs=
p; In this case, when an IPv6-only host
         queries the name server for AA=
AA RRs for an IPv4-only host, the name
         server can perform the synthes=
is of AAAA RRs and pass them back to
         the IPv6-only initiator. =
 The main advantage of this mode is that
         current IPv6 nodes can use thi=
s mechanism without requiring any
         modification.

       

      From: David Schinazi <= dschinazi@apple.com>
      To: "stephan.lag= erholm@yahoo.com" <stephan.lagerholm@yahoo.com>
      Cc: IPv6 Ops WG <v6ops@ietf.org>
      Sent: Wednesday, June 28, 20= 17 3:00 PM
      Subject: Re: Supporting IPv6= -only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-= 01

       

      This section is titled &quo= t;Supporting IPv6-only Networks with NAT64 and DNS64", dual-stack is o= ut of scope of this section.

       

      Am I missing something?

       

      Thanks,

      David Schinazi

       

       

      On Jun 28, 2017, at 08:54, stephan.la= gerholm@yahoo.com wrote:

       

      Hi David,

       = ;

      Yes I have. 464XLAT or anything else is not required to= be able to run DNS64/NAT64. You can run DNS64/NAT64 in combination with Dual Stack if you want to. 

       = ;

      /S

       

      From: David Schinazi <dschinazi@apple.com>
      To: "stephan.lagerholm@yahoo.com= " <stephan.lagerholm@yahoo.com>
      Cc: IPv6 Ops WG <v6ops@ietf.org>
      Sent: Wednesday, June 28, 2017 = 8:37 AM
      Subject: Re: Supporting IPv6-on= ly Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01<= o:p>

       

      Hi Stephan,

       

      Have you read the rest of t= hat section that details the changes required on client devices?

      Thanks,

      David Schinazi

       


      On Jun 28, 2017, at 08:33, "stephan.lagerholm@yahoo.com" <stephan.lagerholm@ya= hoo.com> wrote:

      Hi David,<= o:p>

       = ;

      Thanks for= adding the Supporting IPv6-only Networks with NAT64 and DNS64 section, I f= ind it useful. However I don't think the below sentence from this section is accurate. I can't think of any changes that are needed on = a client device to run NAT64/DNS64. 

       = ;

      While many= IPv6 transition protocols have been standardized and

        &nb= sp;deployed, most are transparent to client devices.  The combined use=

        &nb= sp;of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is

        &nb= sp;being deployed and requires changes in client devices.=

       = ;

      Thanks, St= ephan

       = ;

       = ;

      &= nbsp;

       

      &= nbsp;

       

      --_000_787AE7BB302AE849A7480A190F8B933009FFCCBFOPEXCLILMA3corp_-- From nobody Wed Jun 28 22:52:58 2017 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 3A622127867 for ; Wed, 28 Jun 2017 22:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Rfb_Yry-pvUL for ; Wed, 28 Jun 2017 22:52:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198201275C5 for ; Wed, 28 Jun 2017 22:52:55 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 236193493BB; Thu, 29 Jun 2017 05:52:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0F0D5160047; Thu, 29 Jun 2017 05:52:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F13E2160070; Thu, 29 Jun 2017 05:52:51 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HGrnDm_L3-ns; Thu, 29 Jun 2017 05:52:51 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 24126160047; Thu, 29 Jun 2017 05:52:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Thu, 29 Jun 2017 15:52:48 +1000 Cc: Erik Kline , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> <20170629051741.38EB67D005C0@rock.dv.isc.org> To: Fred Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 05:52:56 -0000 > On 29 Jun 2017, at 3:30 pm, Fred Baker = wrote: >=20 >=20 > On Jun 29, 2017, at 7:17 AM, Mark Andrews wrote: >> The real problem is the choice to promote DNS64/NAT64. Just because >> it works "well enough" in the cellular envionment *where there is >> little to no DNSSEC being used (read as epsilon)*, that is not a >> reason to promote it as a *general* solution for IPv6-only networks. >> Doing that will come back to bite us in the future. >=20 > I'm not sure I disagree, in the sense that the preferred approach = would be to move the application to IPv6. That said, isn't the point = that it hasn't yet been moved but the network is? The only option other = than "translate" is "don't turn off IPv4". I think that will be a common = solution. But when the network is turning off IPv4 and an IPv6-capable = option isn't available for an application, I think they're not going to = ask your opinion. They're going to do something that works for them. There are other mechanisms to reach IPv4 machines from IPv6-only networks. DS-Lite in host mode is one such mechanism. That works with IPv4 literals and it works with DNSSEC. It does require that the host listen for the DHCPv6 option and establish a tunnel based on the data in that option. The host can preference IPv6 over IPv4 when = sorting the addresses to try. It provides a fallback when the AAAA records are broken or the service is only available over IPv4. DS-Lite host mode shouldn=E2=80=99t have TCP PMTU issues as the MSS size advertised should be accounting for reduced size. For NAT64 you need to do mss fixup hacks to avoid this. NAT64 and DS-Lite have the same PMTU limitations with UDP (just the effective MTU is a touch higher with NAT64). Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 28 23:19:53 2017 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 CF2BE128792 for ; Wed, 28 Jun 2017 23:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U81XOd-ao_1q for ; Wed, 28 Jun 2017 23:19:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368C0126E3A for ; Wed, 28 Jun 2017 23:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12326; q=dns/txt; s=iport; t=1498717189; x=1499926789; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RZI/YPqiV0HYKbi1K9OjwCJOSIfadMr5CDe3jii1aVM=; b=mBSKgbE6whFYhytz2eRIwThihMJG0ow6ZQ/UGViBKw7G2y6sUrHclUCq H8YTAeL0qZedFRosBEQ0qknwEyr9pSG/tPgXJMGOaI6W1rZkTW3cbXvPg mI9G3Si4aw2giu4snEiflktplH82s5SO7/f6o9yL5oA6Q2WqJfXLLR0i6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AABVm1RZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4EOjgWRRSKCQYVpiCaFK4IRIQEKhXACgww/GAECAQEBAQE?= =?us-ascii?q?BAWsdC4UYAQEBAQIBAQFsCwULAgEIFQMjBAcnCxMBEQIEDgWJS0wDDQgQtEOHL?= =?us-ascii?q?QOEGQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyeDTIFgASsLgm6CV4F2AQEOM4M?= =?us-ascii?q?dgjEFh3UMgWWEOYQDhQGHFjsCjxCEYZIXi2uJPQEfOIEKdBVJEgGCN4J8gU12A?= =?us-ascii?q?QGHAg0XB4ISAQEB?= X-IronPort-AV: E=Sophos;i="5.40,279,1496102400"; d="scan'208,217";a="263744267" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2017 06:19:47 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5T6JlLo013245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Jun 2017 06:19:47 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Jun 2017 01:19:47 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Thu, 29 Jun 2017 01:19:47 -0500 From: "Rajiv Asati (rajiva)" To: "stephan.lagerholm@yahoo.com" CC: Mark Andrews , IPv6 Ops WG Thread-Topic: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 Thread-Index: AQHS8CPvoUwFnRQpqU+Scvtd7jgqBqI61B6NgACnfQCAABRagIAACq+A///EfWc= Date: Thu, 29 Jun 2017 06:19:47 +0000 Message-ID: <6450146D-C8AC-4557-8644-00EAB868E8E6@cisco.com> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org>, <901072900.951551.1498711968004@mail.yahoo.com> In-Reply-To: <901072900.951551.1498711968004@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_6450146DC8AC4557864400EAB868E8E6ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 06:19:52 -0000 --_000_6450146DC8AC4557864400EAB868E8E6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps, have section 7 for IPv6-only network with 2 sub-sections - 7.1 pointing out transition technologies such as 464XLAT based on DNS64/NAT= 64 that breaks DNSSEC for v4 destinations. 7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DNS64 i= nvolved. I still think it should be outside the scope of this draft to tackle DNSSEC= related issues when using DNS64. Agreed. Cheers, Rajiv Asati Distinguished Engineer, Cisco Services On Jun 28, 2017, at 9:53 PM, "stephan.lagerholm@yahoo.com" > wrote: Hi Mark, > Mark Andrews > > >> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote: >> >> Hi Mark, >> >> >From: Mark Andrews > >> >> In message <738488839.469942.1498664001646@mail.yahoo.com>, "stephan.lagerholm@yahoo.com" writes: >> >> Hi David, >> >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DN= S64 >> >> section, I find it useful. However I don't think the below sentence f= rom >> >> this section is accurate. I can't think of any changes that are neede= d on >> >> a client device to run NAT64/DNS64. >> > >> >Well you obviously don't have any devices doing DNSSEC validation. >> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR >> >NODATA to NOERROR DATA by synthesizing a AAAA RRset. This from the >> >client's perspective is not different than forging a fake AAAA RRset >> >that is trying to hijack the traffic stream. >> >> This case and the remedy is already covered in RFC 6147 section 3. I don= 't think it makes sense to bring it up in this draft. > >RFC 6147 states that end devices need to be upgraded. Yes >this is in contradiction to itself where it states that they don't need >to be upgraded. > >Section 5.5. > > The disadvantage to this approach is that an end point that is > translation-oblivious but security-aware and validating will not > be able to use the DNS64 functionality. In this case, the end > point will not have the desired benefit of NAT64. In effect, > this strategy means that any end point that wishes to do > validation in a NAT64 context must be upgraded to be > translation-aware as well. > >Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY >and in doing so completely defeating the purpose of the "MUST NOT" >on CD=3D1 which is to get answers which are incorrectly being rejected >by the upstream validating resolver. > > "then vDNS64 MAY perform validation," > >Then you have changes to the purpose of CD which don't work >with TTL=3D0 answers. > >The whole IETF seems to think that DNS64/NAT64 works well. It >doesn't when you need to use the protections that DNSSEC >provides. It works ok if everything else is correctly configured and >there are no active attacks on the recursive DNS servers happening. I agree that it does not work well if you validate on the stub resolver sid= e. I can imagine that you could do an RFC7050 query within your validator, = strip the pref64 and then validate the A record. I still think it should be= outside the scope of this draft to tackle DNSSEC related issues when using= DNS64. It is not going to add any clarity to Happy Eyeballs to have text a= round DNSSEC related issues that remains unchanged with or without this dra= ft being implemented. I'm happy to work on an rfc6174bis with you. /Stephan _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_6450146DC8AC4557864400EAB868E8E6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
      Perhaps, have section 7 for IPv6-only network with 2 sub-sections -&nb= sp;

      7.1 pointing out transition technologies such as 464XLAT based on DNS6= 4/NAT64 that breaks DNSSEC for v4 destinations. 

      7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DN= S64 involved.  

      I still think it should be outside the scope of this draft to t= ackle DNSSEC related issues when using DNS64.

      Agreed. 

      Cheers,
      Rajiv Asati
      Distinguished Engineer, Cisco Services


      On Jun 28, 2017, at 9:53 PM, "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com> wrote:

      Hi Mark,
      >        Mark Andrews <marka@isc.org>
      >
      >> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote:
      >>
      >> Hi Mark,
      >>
      >> >From: Mark Andrews <marka@= isc.org>
      >> >> In message <738488839.469942.1498664001646@mail.yahoo.com>= ;, "stephan.lagerholm@y= ahoo.com" writes:
      >> >> Hi David,
      >> >> Thanks for adding the Supporting IPv6-only Networks with = NAT64 and DNS64
      >> >> section, I find it useful. However I don't think the belo= w sentence from
      >> >> this section is accurate. I can't think of any changes th= at are needed on
      >> >> a client device to run NAT64/DNS64.
      >> >
      >> >Well you obviously don't have any devices doing DNSSEC validat= ion.
      >> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERR= OR
      >> >NODATA to NOERROR DATA by synthesizing a AAAA RRset.  Thi= s from the
      >> >client's perspective is not different than forging a fake AAAA= RRset
      >> >that is trying to hijack the traffic stream.
      >>
      >> This case and the remedy is already covered in RFC 6147 section 3.= I don't think it makes sense to bring it up in this draft.
      >
      >RFC 6147 states that end devices need to be upgraded.  Yes
      >this is in contradiction to itself where it states that they don’= t need
      >to be upgraded.
      >
      >Section 5.5.
      >
      >      The disadvantage to this approach is tha= t an end point that is
      >      translation-oblivious but security-aware= and validating will not
      >      be able to use the DNS64 functionality.&= nbsp; In this case, the end
      >      point will not have the desired benefit = of NAT64.  In effect,
      >      this strategy means that any end point t= hat wishes to do
      >      validation in a NAT64 context must be up= graded to be
      >      translation-aware as well.
      >
      >Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY
      >and in doing so completely defeating the purpose of the “MUST NOT= ”
      >on CD=3D1 which is to get answers which are incorrectly being rejected<= br id=3D"yui_3_16_0_1_1498708418212_6542"> >by the upstream validating resolver.
      >
      >      "then vDNS64 MAY perform validation= ,”
      >
      >Then you have changes to the purpose of CD which don’t work
      >with TTL=3D0 answers.
      >
      >The whole IETF seems to think that DNS64/NAT64 works well.  It
      >doesn’t when you need to use the protections that DNSSEC
      >provides.  It works ok if everything else is correctly configured = and
      >there are no active attacks on the recursive DNS servers happening.

      I agree that it does not work well if you validate on the stub resolver sid= e. I can imagine that you could do an RFC7050 query within your validator, = strip the pref64 and then validate the A record. I still think it should be= outside the scope of this draft to tackle DNSSEC related issues when using DNS64. It is not going to add a= ny clarity to Happy Eyeballs to have text around DNSSEC related issues that= remains unchanged with or without this draft being implemented. I'm happy = to work on an rfc6174bis with you.

      /Stephan
      _______________________________________________
      v6ops mailing list
      v6ops@ietf.org
      https://www.i= etf.org/mailman/listinfo/v6ops
      --_000_6450146DC8AC4557864400EAB868E8E6ciscocom_-- From nobody Thu Jun 29 00:03:28 2017 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 37026127775 for ; Thu, 29 Jun 2017 00:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 xyHaK0OP2vYB for ; Thu, 29 Jun 2017 00:03:24 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F57D129ACC for ; Thu, 29 Jun 2017 00:03:24 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 5AE59160605; Thu, 29 Jun 2017 09:03:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 3CCC08006A; Thu, 29 Jun 2017 09:03:22 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0352.000; Thu, 29 Jun 2017 09:03:21 +0200 From: To: "Rajiv Asati (rajiva)" , "stephan.lagerholm@yahoo.com" CC: IPv6 Ops WG Thread-Topic: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 Thread-Index: AQHS8CPvoUwFnRQpqU+Scvtd7jgqBqI61B6NgACnfQCAABRagIAACq+A///EfWeAAAtL0A== Date: Thu, 29 Jun 2017 07:03:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009FFCDA0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org>, <901072900.951551.1498711968004@mail.yahoo.com> <6450146D-C8AC-4557-8644-00EAB868E8E6@cisco.com> In-Reply-To: <6450146D-C8AC-4557-8644-00EAB868E8E6@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009FFCDA0OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:03:26 -0000 --_000_787AE7BB302AE849A7480A190F8B933009FFCDA0OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rajiv, Please see inline. Cheers, Med De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Rajiv Asati (rajiv= a) Envoy=E9 : jeudi 29 juin 2017 08:20 =C0 : stephan.lagerholm@yahoo.com Cc : IPv6 Ops WG Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 sect= ion of draft-ietf-v6ops-rfc6555bis-01 Perhaps, have section 7 for IPv6-only network with 2 sub-sections - 7.1 pointing out transition technologies such as 464XLAT based on DNS64/NAT= 64 that breaks DNSSEC for v4 destinations. 7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DNS64 i= nvolved. [Med] This is also true for other solutions, including NAT64. See, for exam= ple: =B7 https://tools.ietf.org/html/rfc6147#section-5.5 =B7 https://tools.ietf.org/html/rfc7225#section-3.1 I still think it should be outside the scope of this draft to tackle DNSSEC= related issues when using DNS64. Agreed. Cheers, Rajiv Asati Distinguished Engineer, Cisco Services On Jun 28, 2017, at 9:53 PM, "stephan.lagerholm@yahoo.com" > wrote: Hi Mark, > Mark Andrews > > >> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote: >> >> Hi Mark, >> >> >From: Mark Andrews > >> >> In message <738488839.469942.1498664001646@mail.yahoo.com>, "stephan.lagerholm@yahoo.com" writes: >> >> Hi David, >> >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DN= S64 >> >> section, I find it useful. However I don't think the below sentence f= rom >> >> this section is accurate. I can't think of any changes that are neede= d on >> >> a client device to run NAT64/DNS64. >> > >> >Well you obviously don't have any devices doing DNSSEC validation. >> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR >> >NODATA to NOERROR DATA by synthesizing a AAAA RRset. This from the >> >client's perspective is not different than forging a fake AAAA RRset >> >that is trying to hijack the traffic stream. >> >> This case and the remedy is already covered in RFC 6147 section 3. I don= 't think it makes sense to bring it up in this draft. > >RFC 6147 states that end devices need to be upgraded. Yes >this is in contradiction to itself where it states that they don't need >to be upgraded. > >Section 5.5. > > The disadvantage to this approach is that an end point that is > translation-oblivious but security-aware and validating will not > be able to use the DNS64 functionality. In this case, the end > point will not have the desired benefit of NAT64. In effect, > this strategy means that any end point that wishes to do > validation in a NAT64 context must be upgraded to be > translation-aware as well. > >Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY >and in doing so completely defeating the purpose of the "MUST NOT" >on CD=3D1 which is to get answers which are incorrectly being rejected >by the upstream validating resolver. > > "then vDNS64 MAY perform validation," > >Then you have changes to the purpose of CD which don't work >with TTL=3D0 answers. > >The whole IETF seems to think that DNS64/NAT64 works well. It >doesn't when you need to use the protections that DNSSEC >provides. It works ok if everything else is correctly configured and >there are no active attacks on the recursive DNS servers happening. I agree that it does not work well if you validate on the stub resolver sid= e. I can imagine that you could do an RFC7050 query within your validator, = strip the pref64 and then validate the A record. I still think it should be= outside the scope of this draft to tackle DNSSEC related issues when using= DNS64. It is not going to add any clarity to Happy Eyeballs to have text a= round DNSSEC related issues that remains unchanged with or without this dra= ft being implemented. I'm happy to work on an rfc6174bis with you. /Stephan _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_787AE7BB302AE849A7480A190F8B933009FFCDA0OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      Hi Rajiv,

       

      Please see inline.

       

      Cheers,

      Med

       

      De : v6op= s [mailto:v6ops-bounces@ietf.org] De la part de Rajiv Asati (rajiva)
      Envoy=E9 : jeudi 29 juin 2017 08:20
      =C0 : stephan.lagerholm@yahoo.com
      Cc : IPv6 Ops WG
      Objet : Re: [v6ops] Supporting IPv6-only Networks with NAT64 an= d DNS64 section of draft-ietf-v6ops-rfc6555bis-01

       

      Perhaps, have section 7 for IPv6-only network with 2= sub-sections - 

       

      7.1 pointing out transition technologies such as 464= XLAT based on DNS64/NAT64 that breaks DNSSEC for v4 destinations. 

       

      7.2 pointing out that MAP-T/E not breaking DNSSEC si= nce there is no DNS64 involved.

      [Med] This is also true for oth= er solutions, including NAT64. See, for example:

      =B7    &n= bsp;    https://tools.ietf.org/html/rfc6147#se= ction-5.5

      =B7    &n= bsp;    https://tools.ietf.org/html/rfc7225#se= ction-3.1  

       

      I still think it should = be outside the scope of this draft to tackle DNSSEC related issues when usi= ng DNS64.

       

      Agreed. 

       

      Cheers,

      Rajiv Asati

      Distinguished Engineer, Cisco Services

       


      On Jun 28, 2017, at 9:53 PM, "stephan.lagerholm@yahoo.com" <stephan.lagerholm@yahoo.com> wrote:<= /p>

      marka@isc.org>
      >
      >> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com wrote:
      >>
      >> Hi Mark,
      >>
      >> >From: Mark Andrews <marka@= isc.org>
      >> >> In message <738488839.469942.1498664001646@mail.yahoo.com>= ;, "stephan.lagerholm@y= ahoo.com" writes:
      >> >> Hi David,
      >> >> Thanks for adding the Supporting IPv6-only Networks with = NAT64 and DNS64
      >> >> section, I find it useful. However I don't think the belo= w sentence from
      >> >> this section is accurate. I can't think of any changes th= at are needed on
      >> >> a client device to run NAT64/DNS64.
      >> >
      >> >Well you obviously don't have any devices doing DNSSEC validat= ion.
      >> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERR= OR
      >> >NODATA to NOERROR DATA by synthesizing a AAAA RRset.  Thi= s from the
      >> >client's perspective is not different than forging a fake AAAA= RRset
      >> >that is trying to hijack the traffic stream.
      >>
      >> This case and the remedy is already covered in RFC 6147 section 3.= I don't think it makes sense to bring it up in this draft.
      >
      >RFC 6147 states that end devices need to be upgraded.  Yes
      >this is in contradiction to itself where it states that they don’= t need
      >to be upgraded.
      >
      >Section 5.5.
      >
      >      The disadvantage to this approach is tha= t an end point that is
      >      translation-oblivious but security-aware= and validating will not
      >      be able to use the DNS64 functionality.&= nbsp; In this case, the end
      >      point will not have the desired benefit = of NAT64.  In effect,
      >      this strategy means that any end point t= hat wishes to do
      >      validation in a NAT64 context must be up= graded to be
      >      translation-aware as well.
      >
      >Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY
      >and in doing so completely defeating the purpose of the “MUST NOT= ”
      >on CD=3D1 which is to get answers which are incorrectly being rejected<= br id=3D"yui_3_16_0_1_1498708418212_6542"> >by the upstream validating resolver.
      >
      >      "then vDNS64 MAY perform validation= ,”
      >
      >Then you have changes to the purpose of CD which don’t work
      >with TTL=3D0 answers.
      >
      >The whole IETF seems to think that DNS64/NAT64 works well.  It
      >doesn’t when you need to use the protections that DNSSEC
      >provides.  It works ok if everything else is correctly configured = and
      >there are no active attacks on the recursive DNS servers happening.

      I agree that it does not work well if you validate on the stub resolver sid= e. I can imagine that you could do an RFC7050 query within your validator, = strip the pref64 and then validate the A record. I still think it should be= outside the scope of this draft to tackle DNSSEC related issues when using DNS64. It is not going to add a= ny clarity to Happy Eyeballs to have text around DNSSEC related issues that= remains unchanged with or without this draft being implemented. I'm happy = to work on an rfc6174bis with you.

      /Stephan

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

      --_000_787AE7BB302AE849A7480A190F8B933009FFCDA0OPEXCLILMA3corp_-- From nobody Thu Jun 29 00:06:04 2017 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 371EF129417 for ; Thu, 29 Jun 2017 00:06:03 -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 vtTENcBLSr3W for ; Thu, 29 Jun 2017 00:06:01 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604F3127775 for ; Thu, 29 Jun 2017 00:06:01 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id r103so184671282wrb.0 for ; Thu, 29 Jun 2017 00:06:01 -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=Rf4wJr+UXY83ysCVgTWgRhf3jLAZ8elAOx0LvM5xb1g=; b=rVIMI2pxpH6BJwwehJGH6sLthxa+kB8NP19KNlT53SJnXF/SYOP3H2fTjZ8zP+i3G7 b3Xtp2COig4lnxjbtwmMlBRuCwdBG2eXDneAQoMYt3pg93LhPlpfg97qhACPd1X1XRSn io6y4pNZpcwHHYItiqtjwcBXiJ5L7oDaVHpwPMxCFqClD9i7elarnwe96Lpy8tap8w+R ulGnl8Eni3rxLUm+aJbZ9RA8TP9eS8rdcbQv0qU55NeimrCGtUNTpv/vWC3oM+MmZB2D NrRw6rW5xBSRqk/IkbRFAuAnR8Rr6c1t3C3TatdbbwBZScZ0I9FVEEMSU31XQlwvCHAq l5Uw== 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=Rf4wJr+UXY83ysCVgTWgRhf3jLAZ8elAOx0LvM5xb1g=; b=Fm5anUirBG9kmfLihI11Mp2/eP6lBe8+O3ENva53UEW81jDpvh+YUmkQPzFFG2kscU GXOZaFiAVK54+LMojN9O5+ml/kcI+XKkz4OghQcYCFvclu4R30u+F7HgVpgxxS6qUbjz yIA+QsLQha2n92QS1fMg4SItmezz7Ye7O5ckOIuaDrrsMB8ESqkhk6Ze5X5EUdIoUXlo 2RCdehhZvxvtSRS26VHjex05vX/xHALyrGBjG6GQ7ffcPtyDzTXx3vufDD5kYOIPuLgT Zg/UunekWxiciofIHYfFlmxAcb0QUZkmRYDswaSIYXw5UcLPGAyAq2TPbJOsEw3SNuXb UK9Q== X-Gm-Message-State: AKS2vOxrndGQB4FqP0Ucm89XWyJhmk96BVgRnWhjGC6Gn1n5EkegYOzp fPzE2bSrdHdHgQ== X-Received: by 10.223.163.197 with SMTP id m5mr21514538wrb.128.1498719959966; Thu, 29 Jun 2017 00:05:59 -0700 (PDT) Received: from 210.66.20.149.in-addr.arpa (210.66.20.149.in-addr.arpa. [149.20.66.210]) by smtp.gmail.com with ESMTPSA id g5sm424693wmf.5.2017.06.29.00.05.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 00:05:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Thu, 29 Jun 2017 09:05:53 +0200 Cc: Erik Kline , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <83384A74-973E-4D89-9CAD-3159E2D28A97@gmail.com> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> <20170629051741.38EB67D005C0@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:06:03 -0000 > On Jun 29, 2017, at 7:52 AM, Mark Andrews wrote: >=20 > There are other mechanisms to reach IPv4 machines from IPv6-only > networks. DS-Lite in host mode is one such mechanism. True, and if the host implements the protocol that probably works. If it = is an unmodified host...= From nobody Thu Jun 29 00:24:38 2017 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 C595F129BA4 for ; Thu, 29 Jun 2017 00:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uNiQzGhy2qIE for ; Thu, 29 Jun 2017 00:24:17 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198AF129B29 for ; Thu, 29 Jun 2017 00:24:17 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 62so73584716wmw.1 for ; Thu, 29 Jun 2017 00:24:16 -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=gxT4CwRR7tDL7NHa58QMoTZusRudcvVGWRIdSjWzEM4=; b=WP3rJGEY/ngx+thhQdRgSjYG/YMxU4R8+TcRVvBEuGey6yMmvnvRd2CjGyII8OqMau rlOSABxiFWKrqLARCj6OcD3c/5TENmD0WADHFmIBjcXikgeIog5OnpcXzTelE88L7mkO XmJjG7kmfiHedcWsiVRuV6xa4Gm3WJC40S+878YRrDZDzmbIk3+jYd2ZgYFlosz0p0RN IfltyGmir4FS/Rfm4omiZ5gVAzG5Medc5OYbYUlj4VEinqiEQwVZk5QpIucWiLk91HnQ lTtua//yV3raPO+z/U9I+hBTVUOXxpyWPppFfXBjKQogF4WwARiYc0d14OzYsP2yUwGX 8lVA== 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=gxT4CwRR7tDL7NHa58QMoTZusRudcvVGWRIdSjWzEM4=; b=DADNaCAYVBV40vxn8XdjFjy8y2EUgT29CFg6pYVYsE1IfMmtSZe/WVYaVgCi1elbDU ynHelyPBZNpxtKT84qWzMIDSENe40QqMZBZpOc4kbMXvNZnVNxG7Gee2gD/IcCm4A9Us INEPtdzAt9Ytw4wwRhX0TXSvLC4thX1yVtChS8thpDzPL2wu8tsmt0LZIo8eB701YyPS LRvdWAr1qo8pNQ8KLy2DE34gC5Zz2/B7kq9JFvfHVASU9oJwb7Cx43ahXUYbSjsi8VUJ MjjotYHsUu8G3MyDfdQtR4l81HcMC43r25lbwZ6M+cFtpywRZPgMwQA1UZBuXbjzc1iY esXA== X-Gm-Message-State: AIVw110pLYVihZMqlb9v9r8QRlN/PzrjDwUibLvwkL3BdrVu6o4pvz7V f1gl7T5sj9kUZA== X-Received: by 10.28.149.209 with SMTP id x200mr1349302wmd.91.1498721055542; Thu, 29 Jun 2017 00:24:15 -0700 (PDT) Received: from 210.66.20.149.in-addr.arpa (210.66.20.149.in-addr.arpa. [149.20.66.210]) by smtp.gmail.com with ESMTPSA id p99sm4310965wrb.6.2017.06.29.00.24.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 00:24:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Thu, 29 Jun 2017 09:24:07 +0200 Cc: Erik Kline , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <161FDFD5-DFCE-4A69-AC15-C4BFCE9D9629@gmail.com> References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> <20170629051741.38EB67D005C0@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:24:37 -0000 > On Jun 29, 2017, at 7:52 AM, Mark Andrews wrote: >=20 > There are other mechanisms to reach IPv4 machines from IPv6-only > networks. DS-Lite in host mode is one such mechanism. Thinking through my comments a little further. I'm not portraying the = issue well. Let's start out with a picture. I have three hosts that need to talk with each other. They are running = the same application or compatible applications, but two (Hosts A and B) = are on an IPv6-only network and the third (Host C) is on an IPv4-only = network. +------+ |Host A| +------+ / ,-----. ,---. / +------+ / \ +------------+ / \ |Host C+--( IPv4 )--+Interconnect+--( IPv6 ) +------+ \ / +------------+ \ / `-----' `---'\ \+------+ |Host B| +------+ So, contrary to what I said a few moments ago, the application is = IPv6-capable. My error. What you propose is that Host A somehow know that Host B is IPv6-capable = and that Host C is not, and choose an alternative and = not-widely-deployed mechanism such as DS-Lite in Host Mode for access to = Host C. This requires the administrator of the network Host A is in to = give it relevant software and whatever is required to communicate that = distinction. What a translation model proposes is that Host A sees both Host B and = Host C as IPv6-capable and talk with them the same way. Host C's IPv6 = address is in a certain prefix and contains an embedded IPv4 address. = Host A doesn't necessarily realize that - it sees a 128 bit address and = uses it. The network changes the underlying Internet Protocol to make = that work. Is that a perfect solution? NAT is never a perfect solution, and I don't = think anyone here is saying anything different. But operationally, the = administrator doesn't have to change Host A or do anything magical to = make this work. It has issues, specifically with DNSSEC as you point = out. One could argue that the Interconnect is a perfect MITM, and one = would argue correctly. But using a translator allows most of what needs = to happen without saddling the administrator with a gargantuan task. If = he has a huge task, he is unlikely to do it at all. If he can do = something relatively simple, he can take baby steps. Recall that Host C is presumably not under his/her control, but he = presumably has business reasons to enable access between the hosts. =20 From nobody Thu Jun 29 00:51:23 2017 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 A8BA012EACE for ; Thu, 29 Jun 2017 00:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 caSIN0s01Onn for ; Thu, 29 Jun 2017 00:51:11 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5088712EAB0 for ; Thu, 29 Jun 2017 00:51:11 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 07F3C3493A2; Thu, 29 Jun 2017 07:51:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D0A3D160053; Thu, 29 Jun 2017 07:51:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8BA42160096; Thu, 29 Jun 2017 07:51:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gPN0SJHjdAmc; Thu, 29 Jun 2017 07:51:08 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1E698160053; Thu, 29 Jun 2017 07:51:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 071347D1A22B; Thu, 29 Jun 2017 17:51:06 +1000 (AEST) To: Fred Baker Cc: Erik Kline , IPv6 Ops WG From: Mark Andrews References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <738488839.469942.1498664001646@mail.yahoo.com> <20170628220025.4FA447CB2073@rock.dv.isc.org> <280023835.899017.1498705302254@mail.yahoo.com> <47F7A2D8-9516-4E25-A673-40D6293B7CE7@isc.org> <20170629051741.38EB67D005C0@rock.dv.isc.org> <83384A74-973E-4D89-9CAD-3159E2D28A97@gmail.com> In-reply-to: Your message of "Thu, 29 Jun 2017 09:05:53 +0200." <83384A74-973E-4D89-9CAD-3159E2D28A97@gmail.com> Date: Thu, 29 Jun 2017 17:51:05 +1000 Message-Id: <20170629075106.071347D1A22B@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:51:13 -0000 In message <83384A74-973E-4D89-9CAD-3159E2D28A97@gmail.com>, Fred Baker writes: > > > On Jun 29, 2017, at 7:52 AM, Mark Andrews wrote: > > > > There are other mechanisms to reach IPv4 machines from IPv6-only > > networks. DS-Lite in host mode is one such mechanism. > > True, and if the host implements the protocol that probably works. If it > is an unmodified host... There is no clean solution that works, in general, for unmodified hosts connected IPv6-only network. They all require something to be modified. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 29 00:52:26 2017 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 C7C2A12EAAA for ; Thu, 29 Jun 2017 00:52: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, 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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvGaGvhBFyfb for ; Thu, 29 Jun 2017 00:52:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7304512EA52 for ; Thu, 29 Jun 2017 00:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1498722741; x=1499327541; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=r3fziOKvqMJOX0eQ16KF/ps8z o3APjD0TJJwfn8pOYo=; b=VlJ+Sv9A4vFkymM6vFKMKacJucVG/n7GvrHYdQh26 5fPbNL8HNYg8NkLyTB+CW9JBE3tDX7jHyQ/0W0gDmQTntQ0V5y02vrcJ6yevfPrk z/E/ywKfGsvxqKzjK6A0yM7HLsQkxBueqd0r7mmhAXT1LQKk0I1hqpdh0kMHtl/O T8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=e1GpKXiohWi2N7ePke/OUQaRC8wf7gS+9gysgblYcahg+Iysh2yEaM2UOYz8 fxucu+617TWZRNVduI1fsfnGHJMT2A+eeugViOt0d96Eyw/yX2/LvTrRs WohvXUC24+ZaCa3WSsUccIEfF/3MA7f0USW9UsRi6+R4RIpEKUTWvY=; X-MDAV-Processed: mail.consulintel.es, Thu, 29 Jun 2017 09:52:21 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 29 Jun 2017 09:52:20 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005461309.msg for ; Thu, 29 Jun 2017 09:52:19 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170629:md50005461309::ADHLK0I399ugjSTz:000003Hg X-Return-Path: prvs=1353ba9eec=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 29 Jun 2017 09:52:14 +0200 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <17C48B38-9EE2-4C17-AE6D-4DFAE1A700B5@consulintel.es> Thread-Topic: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 References: <149670589074.3841.10812713591494006570@ietfa.amsl.com> <65F3C8F4-6533-4C15-83F9-64AFC0EFFA79@apple.com> <4AC6726C-142E-48E5-95CF-2C3AD3331441@consulintel.es> <63B9D8C9-159F-4026-9CF8-75ABB1EF7885@apple.com> In-Reply-To: <63B9D8C9-159F-4026-9CF8-75ABB1EF7885@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:52:26 -0000 =20 =20 On Jun 28, 2017, at 01:18, JORDI PALET MARTINEZ wrote: =20 I don't think the document needs to mandate making constants config= urable. Modern operating systems receive periodic software updates that can= change the values as we work our way towards deprecating Happy Eyeballs. A= verage smartphone users shouldn't be bothered with this (if you can't confi= gure it you can't misconfigure it). =20 [Jordi] I understand that, however, having parameter in the OS, it mean= s other apps can change that if they need it, even before there is an OS up= date. There are many users that don=E2=80=99t update the OS, so this is not= a good way to ensure a correct future behaviour. Remember recent wannacry,= etc., because outdates OS? =20 =20 =20 =20 [DS] I don't believe the benefit of increasing HE timers outweighs the = risk of misconfiguration. The section is titled "Summary of Configurable Values" which means OS i= mplementers can choose to make these configurable. Some implementers will n= ot. [Jordi-2] Do you think it makes sense to let the implementors to not make t= hem configurable? Because if that=E2=80=99s the case then a strong recommen= dation to make it configurable in section 8, should work ;-) =20 As we discussed in Chicago, end users should never be made aware of= IPv6 network failures as they are not their burden or responsibility to fi= x. Network operators shouldn't expect their users to be the first ones to n= otice something's broken. In effect HE will be deprecated when ISPs stop ro= uting IPv4. =20 [Jordi] Yes, and not. This is the intend of HE, but if HE only sort out= s part of the possible issues, then one way or the other, the user notice i= t =E2=80=A6 so this is related with the suggestion for PMTUD failures to be= also sorted out by HE =E2=80=A6 =20 Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't cu= rrently help with the issue so we marked it out of scope. Are you suggestin= g a remedy? =20 [Jordi] Exactly, what I=E2=80=99m suggesting is to improve a bit more = HE and be able to verify the PMTUD filtering, so if IPv6 is faster than IPv= 4, but then PMTUD is filtered, then HE can also =E2=80=9Ctake=E2=80=9D the = decision to use IPv4. This way we got what you wanted: User not aware of IP= v6 failures! I don=E2=80=99t get then the =E2=80=9Cwarning=E2=80=9D to the = ISP, but we can find a different way for that problem of course =E2=80=A6 =20 =20 =20 =20 =20 [DS] Solving PMTUD issues is currently done inside the TCP stack not HE= , I'm not certain of the value of adding complexity to HE for this. =20 [Jordi-2] Here is the point. I now increase a bit the HE complexity, but we= are taking a big opportunity of a successfully widely implemented mechanis= ms to do something very good with an update. If instead of that we choose t= o write a *new* mechanism specific for detecting the PMTUD problem, it will= take much longer to become widely implemented, and I think we are in the I= ETF to solve the problems in a way that is more convenient and better for t= he community, right? =20 Regarding section 7.1, old socket APIs are out of scope as HE is im= plemented above or alongside sockets. Applications using sockets directly w= ill not get any of these benefits. =20 [Jordi] I understand that, and I=E2=80=99m somehow ignorant about how O= S do this internally, so just wondering if we can take also the opportunity= to also allow them to use HE. =20 =20 =20 =20 =20 [DS] That isn't possible with current architectures, but either way we'= re moving away from sockets so I don't think there's much value in solving = this issue: https://tools.ietf.org/html/draft-trammell-taps-post-sockets =20 [Jordi-2] got it, thanks! =20 [Jordi] Final comment. Do you think we can further extend HE in order t= o provide a way to warn the ISP that HE is forcing IPv4, because IPv6 perfo= rmance is low? I think we can find several ways to do that, may be a common= dns name such as he-fail.isp.com or something sim= ilar, that IF the ISP want to implement, gets info about those failures, bu= t the ISP is free to implement it or not. This is useful for those ISPs tha= t really do a good job monitoring their networks, of course, but I think is= a perfect opportunity from HE instead of something different. =20 =20 =20 =20 =20 [DS] That sounds reasonable to me, I think it deserves its own draft th= ough (and will require a serious discussion about user privacy implications= ). [Jordi-2] Same argument as above for the PMTUD. I think is feasible to make= it in the same document and take the opportunity of the success. I underst= and that it may mean that the move to last call may take a couple of additi= onal cycles. It is not my intent to delay this at all, but instead, to make= whatever is better for the community. A couple of months of delay is worth= instead of waiting years for an alternative protocol to be implemented wid= ely. I=E2=80=99m sure you understand my point. This is my suggestion. I gue= ss you will be in Prague. Let=E2=80=99s work (probably other people is inte= rested in that) in a couple of alternatives about how to do this from now t= o the meeting. Then we can met face to face on Sunday in Prague and we can = advance it as much as possible, and we could ask in the v6ops session a pol= l about this with already =E2=80=9Csomething=E2=80=9D in draft (may be pres= enting) a couple of choices. I=E2=80=99m happy to draft something in the ne= xt couple of days. I understand what you mean about the privacy implication= s, however: 1) The ISPs are already mandated by law to log the data of the = customers 2) We don=E2=80=99t need to send the ISP the address of the host,= the WAN address is enough probably (just a quick idea). =20 Thanks, David Schinazi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Jun 30 08:30:53 2017 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 BE46112F28A; Fri, 30 Jun 2017 08:30:44 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883664468.4596.2223987155547274208@ietfa.amsl.com> Date: Fri, 30 Jun 2017 08:30:44 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 15:30:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-06.txt Pages : 8 Date : 2017-06-30 Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-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/