Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

"STARK, BARBARA H" <bs7652@att.com> Wed, 29 August 2018 12:13 UTC

Return-Path: <bs7652@att.com>
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 A20C9130E84; Wed, 29 Aug 2018 05:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiUnADWiTjFu; Wed, 29 Aug 2018 05:13: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 8C8F1130DD4; Wed, 29 Aug 2018 05:13:09 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w7TC5qtq020457; Wed, 29 Aug 2018 08:11:40 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2m5tuvgm2c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Aug 2018 08:11:40 -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 w7TCBdOi008445; Wed, 29 Aug 2018 08:11:40 -0400
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7TCBYjY008371; Wed, 29 Aug 2018 08:11:35 -0400
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id F1FB04048C25; Wed, 29 Aug 2018 12:11:34 +0000 (GMT)
Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id E02824048C21; Wed, 29 Aug 2018 12:11:34 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.179]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0408.000; Wed, 29 Aug 2018 08:11:34 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Fred Baker' <fredbaker.ietf@gmail.com>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt
Thread-Index: AQHUH3NaZWefO7PE5UO6xLlEY9uInaSW+0GAgAAwrwCAPQk0kIAA3boAgACyxoCAAHyjgP//zKLg
Date: Wed, 29 Aug 2018 12:11:34 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com>
In-Reply-To: <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.246.63]
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=2018-08-29_03:, , 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=645 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808290131
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/aeB0MNuPM5y5PnDsztyJhdLda1I>
Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 12:13:14 -0000

> My understanding, no hats and potentially incorrect, is that any ISP I know of
> will respond to a DHCPv6 IA_PD with a prefix at least as large as requested,
> up to /48.

I don't think this is correct. Of course, any provider using 6rd won't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there.
Wireless LTE providers don't tend to support DHCPv6, either. The /64 advertised by the RA in an LTE environment is all the LTE UE will get. That includes the case where the LTE UE is supporting a fixed wireless installation.
For ISPs that support DHCPv6, it may or may not be the case. I've heard several say they do, but I'm not aware of a survey of all ISPs that would tell me how prevalent it is.

BTW, I disagree with the abstract's statement that the "policy should reflect that assignment of a single subnet is never appropriate." I do not believe this takes into consideration the fact that it would be tremendously expensive for some ISPs to replace their current equipment when those current equipment vendors are being slow about supporting certain features. Cost is always an appropriate consideration. It also does not take into account CE routers that only request a single /64. I think it's inappropriate for IETF to be trying to dictate what is and isn't "appropriate". Recommending a best current practice is fine. But that's not the same as saying something is "never appropriate".

Barbara