RE: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)

"STARK, BARBARA H" <bs7652@att.com> Tue, 19 February 2019 15:14 UTC

Return-Path: <bs7652@att.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBD112F19D for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rxBADUQ-rBi3 for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 07:14:41 -0800 (PST)
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 8283A1295EC for <ipv6@ietf.org>; Tue, 19 Feb 2019 07:14:41 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1JFBjms028464 for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:14:41 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2qrjs72t8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:14:40 -0500
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 x1JFEI2C021891 for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:14:18 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1JFECYT021773 for <ipv6@ietf.org>; Tue, 19 Feb 2019 10:14:15 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 75C294014066 for <ipv6@ietf.org>; Tue, 19 Feb 2019 15:14:12 +0000 (GMT)
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 6186D401404B for <ipv6@ietf.org>; Tue, 19 Feb 2019 15:14:12 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.91]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0435.000; Tue, 19 Feb 2019 10:14:11 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)
Thread-Topic: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)
Thread-Index: AQHUx/Ea7Gm/VjMK9EqZTnA15tUFu6XnMj0AgAACwQCAAAUFAIAABIGAgAAWz4D//9f9kIAABirg
Date: Tue, 19 Feb 2019 15:14:10 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E0A8021@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <155053352190.25856.12031845488827430669.idtracker@ietfa.amsl.com> <fe9eecc0-b41a-53c5-5e17-7f8d732cb7cf@si6networks.com> <105E9F49-A9E7-4C77-963D-0B37997FF7AE@consulintel.es> <61d3daff-927f-b289-197a-01ff504aeba9@go6.si> <7f0bd1d3-2bc2-69d1-1ff9-91e4da104e3e@gmail.com> <alpine.DEB.2.20.1902191102200.24327@uplift.swm.pp.se> <20190219102427.GK33237@ernw.de> <fd19943c-1601-5e0e-b402-bd5164c50f07@go6.si> <2D09D61DDFA73D4C884805CC7865E6114E0A7FC3@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E0A7FC3@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.232]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-19_10:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=975 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902190113
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jK2k_5tNS1stQFAyz1QBeJbQG1U>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2019 15:14:44 -0000

On the off-chance that people in IETF might want to base recommendations on real research and statistics, here is an excellent paper regarding frequency of IP address changes. 

https://www.caida.org/publications/papers/2016/reasons_dynamic_addresses_change/ 

What we don't (publicly) have are numbers of customers who complain about the impact of IP address changes. But the number of ISPs who are saying this presents a problem for them (i.e., drives up help desk calls, causes customers to switch to other ISPs, etc.) might be an indication ...

Another data point is this:
https://www.vicimediainc.com/often-ip-addresses-change/

The claims they make as to frequency and why ISPs don't change don't seem to have any factual basis, so that's not what I consider relevant. What I consider relevant is they are a (non-ISP, non-ISP-affiliated) advertising company who claims to make money from selling ads based on mapping IP addresses to physical location. They don't claim to get their data from ISPs. 

Personally, I have no interest in enabling companies like this. I'm also not aware of any actual mass market problem related to IP address changes. Mass market products aren't about meeting the needs of 100% of people at any cost. Mass market broadband products are about meeting the needs of the mass market.

While I don't see a mass market problem related to IP address changes, I do support Fernando's goal with this draft. I think making edge networks and hosts more resilient to network changes is helpful. I think it might be good if we had more comments suggesting improvements to Fernando's proposals, rather than pretending we could obviate any need for these proposals by insisting ISPs provide static IP addresses/prefixes and that people be able to take their IP address(es) with them when they move.
Barbara