IETF Logo Mail Archive

RE: [v6ops] A common problem with SLAAC in "renumbering" scenarios

"STARK, BARBARA H" <bs7652@att.com> Wed, 13 February 2019 17:44 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 D6B22130DE5 for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 09:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcj_iiDKYJDr for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 09:44:05 -0800 (PST)
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 419CB1200B3 for <ipv6@ietf.org>; Wed, 13 Feb 2019 09:44:05 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1DHd2kv018944; Wed, 13 Feb 2019 12:43:49 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2qmpr4jae1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 12:43:48 -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 x1DHhlen004106; Wed, 13 Feb 2019 12:43:47 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1DHhdjU003929; Wed, 13 Feb 2019 12:43:39 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 3C7D44014674; Wed, 13 Feb 2019 17:43:39 +0000 (GMT)
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30483.vci.att.com (Service) with ESMTPS id 27193401466C; Wed, 13 Feb 2019 17:43:39 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.65]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0435.000; Wed, 13 Feb 2019 12:43:38 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Jan Zorz - Go6' <jan@go6.si>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUu7vkUWddHYvx9Euc6GQiM5rkGKXOfr6AgAAHLQCAAAnPAIAAHVOAgAAgNQCAAAE1gIAABwQAgAACVoCAAApPgIAADU4AgAAoQACAAAVYgIAOSV8AgADrowD//7ufkA==
Date: Wed, 13 Feb 2019 17:43:38 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E094CF6@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <A0201A4B-77BB-40F4-A35F-F1491732D537@consulintel.es> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org> <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> <DFDEF631-B6EF-440E-A245-261FBC780BBB@employees.org> <38eb8b47-6ae9-f256-81b4-3313c7f0a83f@si6networks.com> <3d609c48-399f-b3b4-385e-50a58b9b72b3@go6.si>
In-Reply-To: <3d609c48-399f-b3b4-385e-50a58b9b72b3@go6.si>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.194.183]
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-13_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=753 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130124
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DrMcnC-HrrdMWlwv44kwZHxNNWw>
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: Wed, 13 Feb 2019 17:44:07 -0000

> > Not necessarily. There is no requirement that the ISP leases the same
> > prefix if the client just asks a new prefix.
> 
> Seriously? Same DUID should get the same PD inside the lifetime cycle
> (whatever lifetime is set, 1h or 30 years).
> 
> No requirement? Well, then we need one, do we?

Maybe it would be helpful to place such a requirement on the network equipment implementations, rather than the ISPs? It's really hard for an operator to meet "requirements" when the equipment either doesn't make it possible, makes it difficult, or increases cost (e.g., if this capability is enabled, this equipment will only be able to handle half as many customers). I'm not saying that is or isn't the case for any particular implementations for prefix delegation. But in my experience, the capabilities of deployed equipment play a *huge* role in an operator's deployment decisions and configurations.
Barbara

v2.23.0 | Report a Bug | By Email