RE: A common problem with SLAAC in "renumbering" scenarios

"STARK, BARBARA H" <bs7652@att.com> Mon, 04 February 2019 15:41 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 4BD96130E83 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 07:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVmPScUwjswE for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 07:41:46 -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 393EF130E81 for <ipv6@ietf.org>; Mon, 4 Feb 2019 07:41:46 -0800 (PST)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x14Fcwa6046116; Mon, 4 Feb 2019 10:41:27 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2qer7e823b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Feb 2019 10:41:27 -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 x14FfQQ4020058; Mon, 4 Feb 2019 10:41:27 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x14FfGEq019754; Mon, 4 Feb 2019 10:41:22 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 0F3704013D2A; Mon, 4 Feb 2019 15:41:16 +0000 (GMT)
Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30484.vci.att.com (Service) with ESMTPS id F0E3A4013D2B; Mon, 4 Feb 2019 15:41:15 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Mon, 4 Feb 2019 10:41:15 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Jan Zorz - Go6' <jan@go6.si>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUuln87r4hXF0vu02sI0LVCflDuaXPw69Q
Date: Mon, 04 Feb 2019 15:41:14 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DFB7B00@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <c40020c9-b9ef-adef-144d-5e077bf6d1e3@go6.si>
In-Reply-To: <c40020c9-b9ef-adef-144d-5e077bf6d1e3@go6.si>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.195.178]
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-04_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 mlxscore=0 impostorscore=0 mlxlogscore=726 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902040121
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Jkvvy1zDNu6oPMo2euifnNHyF1Q>
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: Mon, 04 Feb 2019 15:41:47 -0000

> However, RFC7084 is Informational and not Standard. I think this should
> make it into Standard. I've seen many CPE vendors saying "we found
> relevant standard documents and implemented whatever was a MUST and
> shipped the product."

RFC7084 has no business being labeled an "Internet Standard", and its ability to impact CE router vendor development decisions is completely unrelated to how it is labeled.

It has no business being an "Internet Standard" because CE router requirements are derived/designed based on access architecture. CE router requirements do not, cannot, and will not ever drive access architecture. Whenever access architecture changes, CE router requirements change. Some of the changes that we saw from RFC6204 to RFC7084 were because ISPs decided they wanted to do different things in their access networks than what they originally thought (DS-Lite, 6rd, and some other items). So the requirements had to adjust. Now we have ISPs not agreeing on "IPv6aas" architecture. So the CE router is being asked to do all of them. What if 5G/wireline convergence becomes a reality? CE router requirements will change. Trying to standardize something that is outside IETF's control is unrealistic.

CE router vendors (and ISPs) really don't care whether something is labeled as "Standard" or "Informational". If it's well-defined and useful, that's all that's needed. L2TP is "Standards Track". PPPoE is "Informational". Which one do ISPs use in the access network, and which is implemented in CE routers? PPPoE. Why? It was a good tool for what was needed, and the RFC is easy to read and implement. L2TP was not the right tool.

Are there any major CE router vendors who haven't tried to implement all the "MUST" requirements of RFC7084? Not that I'm aware of. Some may not have done it right, but that's not the same as not trying.

I'm opposed to any attempt to turn CE router requirements into a "Standard". It's unrealistic and the status would have no impact on whether it's implemented.
Barbara