IETF Logo Mail Archive

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

Michael Richardson <mcr@sandelman.ca> Mon, 11 February 2019 22:59 UTC

Return-Path: <mcr@sandelman.ca>
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 6A0C8131155 for <ipv6@ietfa.amsl.com>; Mon, 11 Feb 2019 14:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HMR2PgyxJL7P for <ipv6@ietfa.amsl.com>; Mon, 11 Feb 2019 14:59:12 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF6B1286E7 for <ipv6@ietf.org>; Mon, 11 Feb 2019 14:59:11 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1ED1F38261; Mon, 11 Feb 2019 17:56:04 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id BD70A26C3; Mon, 11 Feb 2019 17:59:09 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BC1B13FD; Mon, 11 Feb 2019 17:59:09 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: Jan Zorz - Go6 <jan@go6.si>
cc: ipv6@ietf.org
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-Reply-To: <e42b03d3-d133-bcad-9cb6-b6e48f9024b8@go6.si>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <alpine.DEB.2.20.1902111006510.23912@uplift.swm.pp.se> <e42b03d3-d133-bcad-9cb6-b6e48f9024b8@go6.si>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 11 Feb 2019 17:59:09 -0500
Message-ID: <13377.1549925949@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/smhyhJSIXqQW_6i-65ErVhMLnjw>
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, 11 Feb 2019 22:59:16 -0000

Jan Zorz - Go6 <jan@go6.si> wrote:
    >>> The decision on for the production residential IPv6 broadband deployment I
    >>> worked on back in 2010 was to do dynamic GUA /64s on the PPPoE
    >>> session/link, and a static/stable PD prefix provided via RADIUS. So
    >>> outside the BNG, there was only 1 PD route per customer.
    >>
    >> For IPoE this is not great as you don't want the ND table growing
    >> potentially large. Most people I see do this with an optional IA_NA on WAN
    >> and then PD. The two examples I have available at home neither announces
    >> any PIO on WAN but instead have M=1 and one of them only offers single
    >> IA_NA plus /56 PD (DOCSIS ISP with modem in bridge mode), the other one (my
    >> FTTH AE IPoE provider) just offers IA_PD with unnumbered WAN.
    >>
    >> I think both models are fine.

    > Sure.

    >>
    >> With PPPoE of course the ND scalability problem doesn't exist so just
    >> routing the /56 down it and using PD exclude for a /64 for WAN that is then
    >> announced in RA+PIO seems like a perfectly sensible thing to do.

    > Still wondering what happens if a single end-host with PPPoE client that
    > can't do PD (for example a windows station) connects to the internet and
    > tries to get IPv6. Would it fallback to SLAAC?

Unless it's been configured to ignore RAs, if the ISP sent an RA with M=0,O=0,
then the host would configure with SLAAC.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email