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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sat, 02 February 2019 18:42 UTC

Return-Path: <prvs=193645c206=jordi.palet@consulintel.es>
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 7278712426E for <ipv6@ietfa.amsl.com>; Sat, 2 Feb 2019 10:42:43 -0800 (PST)
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
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 I3SUSZzbOYwQ for <ipv6@ietfa.amsl.com>; Sat, 2 Feb 2019 10:42:40 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF51228B7 for <ipv6@ietf.org>; Sat, 2 Feb 2019 10:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1549132958; x=1549737758; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=LC/U+2nO7eL4ulS5dX27bCH53oinZ1FfNg9Ph+3Bnlg=; b=u4/KmCDhUmwcK NHj+ansyw79bwzZlH2tFNDShjSa06c+eVnsgadJ4zqXwLje3fcZPq41JU6pDYgD3 Pll9FU8twY9YMLnE7aV5TWBh0rHukfEc0IWJnc7wtyFKtKsEcIIASq22590otFkH 5ediGZcj5LWsYWjkhux6++BTuxRtg8=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 02 Feb 2019 19:42:38 +0100
X-Spam-Processed: mail.consulintel.es, Sat, 02 Feb 2019 19:42:37 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006138854.msg for <ipv6@ietf.org>; Sat, 02 Feb 2019 19:42:37 +0100
X-MDRemoteIP: 2001:470:1f09:495:15ec:a82d:2827:8071
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sat, 02 Feb 2019 19:42:37 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=193645c206=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.6.190114
Date: Sat, 02 Feb 2019 19:42:32 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Jan Zorz - Go6 <jan@go6.si>
CC: ipv6@ietf.org
Message-ID: <0AC92C54-F91C-46D4-BDE7-837F0BE0E373@consulintel.es>
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
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> <29941.1549127940@dooku.sandelman.ca>
In-Reply-To: <29941.1549127940@dooku.sandelman.ca>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Bkm3vfzMBgCVB10-RoT5TKJkb3A>
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: Sat, 02 Feb 2019 18:42:44 -0000

When I started the work in RFC7084-bis (now draft-ietf-v6ops-transition-ipv4aas, waiting for the final IESG "go"), I was always thinking that it must become a standard, but the discussions in the WG didn't went that way.

I will be happy also to co-author if more work is needed in this direction.

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Michael Richardson <mcr+ietf@sandelman.ca>
Fecha: sábado, 2 de febrero de 2019, 18:19
Para: Jan Zorz - Go6 <jan@go6.si>
CC: <ipv6@ietf.org>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    
    Jan Zorz - Go6 <jan@go6.si> wrote:
        > On 31/01/2019 13:11, Fernando Gont wrote:
        >>> Doesn't RFC7084 already say this? L-13.
        >> 
        >> Yes, and we missed this (thanks!). -- that said, we added this bullet
        >> for completeness sake. The case we care about in this doc is the
        >> reboot scenario.
    
        > However, RFC7084 is Informational and not Standard. I think this should
    
    Additionally, when it comes to what the CPE can expect from the ISP, 7084 is
    essentially a set of heuristics, and there is no document about what the
    *ISP* can expect from the CPE.
    
    We need to turn both in standards, with a clear palette of behaviours.
    
    For instance, I'd like to see standardized support for:
    Scenario A:
       a) do *not* number the PPP(oE) link in IPv6. (use LL only)
       b) ISP delegates /60 or bigger and the CPE uses an address out of it.
    
    Scenario B:
       a) do *not* number the PPP(oE) link in IPv6. (use LL only)
       b) ISP delegates exactly a /64, and the CPE uses an address out of it,
          and uses the rest for tethering, single link.
    
    Scenario C:
       a) number the PPPoE link with RA and/or DHCPv6.
       b) Use rfc6603 to clearly exclude the link prefix
    
    Scenario D:
       a) number the link with a /64
       b) provide another /60+ if the CPE asks for it later on.
    
    For ISPs, there is a major win to having the all of the customer prefixes in
    a single prefix (routing entry), but it's hard to know which scenario is
    going to occur.
    
    There is not enough in RFC7084 for an ISP to provide requirements to PPPoE
    termination vendors (DSLAM) or to CPE vendors.    In the work I did at
    Finepoint, I basically had to invert 7084 to make my requirements, but I
    couldn't be sure what CPEs would support which scenarios.
    
    The Broadband Forum TR-187 is useful, but still has too much wiggle room.
    
    I would be willing to co-author a document.
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.