Re: RFC4941bis: consequences of many addresses for the network

Warren Kumari <warren@kumari.net> Thu, 23 January 2020 18:53 UTC

Return-Path: <warren@kumari.net>
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 231C9120A47 for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 10:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 apcfTd0haIrI for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 10:53:22 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0EE120A41 for <ipv6@ietf.org>; Thu, 23 Jan 2020 10:53:07 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id c24so3319347qtp.5 for <ipv6@ietf.org>; Thu, 23 Jan 2020 10:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qsf7lNhGRmU2jk5oyYJ72z9g+cqNx1PilKd+MrrSF94=; b=Ug/NZgO79jqqx+gZOsY0wmS7nlqH3IOrwcy52d8oyvam7k52XwWk3wGqSAfrd1NoLa QKSv+x4K04NyZoSfnPj+edPplcLUpKMD/T9lR4DCxH93weMnsmQn1blm34NR72rmraZq fnbtBCoqC4aDcv4+3kDJQsEEPMBe3J6OX2AsbJuao1jgZq+Bc+qqWzEo/tVo6LKuZQLB uW66sk19XkPd3FNzqiaY+I9BwWf8OpdWNJxWaroNRTmD6d1CCWXYq5+EEjrk1jenIGkr HC1fI10GfMn8lfkpW8fMLzJvAvTvNKCyFPdjQdxWGYI0XoXxhJHOB6Z1o+jH2SND+dB9 g40w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Qsf7lNhGRmU2jk5oyYJ72z9g+cqNx1PilKd+MrrSF94=; b=hpMMx6MCPtZYSK2v3P5OdifNfjpXgWeCvZBUkHI9gISAan2vFyP1mYQZ/5AZOa7a6/ 3uKG1d3/Jdu4MbIDEVg9Jxs7wU3ICJ2kLh59QXLW+PEFIuP2dRPt4ICYlZTGpNTKG6n7 xbIGV3yN0T6dwKEFcL7tkOy/SV8qZlua6q9NxigVrkYmrqBN27z6ztUnGI5aSxaM67Bi f4xrjdXWNgHNJLsKc5HSbJIXG2mz19u6KF9kVUlekcWRFIJulS88qKr1bC8hWXXBQMRA mXopBJNWutWwRwKga9X5zWn/7rPcYYMTp4MpZzElJ6yhKTj9Tcf2Du52Ii4c29n1ID7b PCAA==
X-Gm-Message-State: APjAAAUNT8ocb2MzkFcRpD+LwzrMECn7zZ0onHAq7QQQyObaTVsplb/R E27HAu74EM0Dj14M4U7KtxSFjM+sRuWC6mK+juWPLA==
X-Google-Smtp-Source: APXvYqzOTPo9jkzLD3/XZfuu33EETDHntSBiWk3+hk5sF+bYtvfoaNn2okZLFvsPdBiJF8zzZmYERMlq+oFgZRYbDkw=
X-Received: by 2002:ac8:387b:: with SMTP id r56mr18023899qtb.364.1579805586720; Thu, 23 Jan 2020 10:53:06 -0800 (PST)
MIME-Version: 1.0
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <2044DC74-3529-45BF-9886-56030B5EA515@gmail.com> <059D9CB7-9677-4CD2-BCDC-2393FA072BD7@cisco.com>
In-Reply-To: <059D9CB7-9677-4CD2-BCDC-2393FA072BD7@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 23 Jan 2020 13:52:30 -0500
Message-ID: <CAHw9_i+LFa=u6jdtFL-AkwLpDQLqnU9kci+0DO0rogDJMULahA@mail.gmail.com>
Subject: Re: RFC4941bis: consequences of many addresses for the network
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MtxjkoRJ9hJqNycN53OyC7iDV4A>
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: Thu, 23 Jan 2020 18:53:24 -0000

On Thu, Jan 23, 2020 at 12:52 PM Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
>
> Hello Bob
>
> The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs).

Indeed -- RFC6583 - "Operational Neighbor Discovery Problems", and,
much more so, RFC8273 - "Unique IPv6 Prefix per Host" seem very
relevant here...

Yay,  "We can solve any problem by introducing an extra level of
indirection" ( or aegrescit medendo :-))

W


>
>
> Regards,
>
> Pascal
>
> > Le 23 janv. 2020 à 18:35, Bob Hinden <bob.hinden@gmail.com> a écrit :
> >
> > Ole,
> >
> > Clearly a very number of addresses is a problem for router and other devices on the link.   I note looking at my local machine (MacOS 10.14.6) I have five IPv6 addresses:
> >
> > Link-local
> > ULA (temp and secured)
> > Global  (temp and secured)
> >
> > My router advertises a Global and ULA prefix.
> >
> > This seems to be current practice.   Is this a problem?   If I had 100 local devices on my link that would be 700 addresses, 1000 devices, then 7,000 addresses.  Is that excessive?   Also, depends on how the nodes manage this state, completely separate entries for each address, or all the addresses tied to the same link address.
> >
> > For RFC4941bis, I think text that raises the issue is a good thing, but the issue isn’t created by the bis draft, it a part of SLACC.   We have multiple ways of creating IPv6 addresses, they all contribute to this.
> >
> > I think a new document that discusses the issue and makes some recommendations would be useful.
> >
> > Bob
> >
> >
> >
> >
> >
> >
> >> On Jan 23, 2020, at 12:59 AM, otroan@employees.org wrote:
> >>
> >> While reviewing RFC4941bis (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I found one gap.
> >>
> >> A discussion of the consequences of a host having many (active) addresses on the network.
> >>
> >> A 4941bis implementation following the defaults, would at the maximum use 8 active addresses.
> >> (Valid lifetime of one week and one new address per day.)
> >>
> >> Shorter regeneration intervals or other approaches like a new address per connection could lead to dramatic numbers.
> >>
> >> If we use Ethernet as an example, each new address requires state in the network. In the ND cache in first-hop routers, and in SAVI binding tables in bridges. Given ND's security properties these tables must be policed by the network. A host with a very liberal address regeneration policy might be viewed as performing an attack.
> >>
> >> There is no signal available in SLAAC apart from DAD to reject an address. If the network runs out of resources (or prohibits the additional address by policy) the address will not be served. The host has to be deal with that situation.
> >>
> >> SLAAC is also missing a mechanism to release an address. Which leads me to think that the address regeneration interval must not be shorter than the ND cache scavenger timeout (which in many networks is high to avoid cache churn and high level of address re-resolutions).
> >>
> >> I would like to hear from other network-side implementors and operators.
> >> Is there an issue here?
> >>
> >> Best regards,
> >> Ole
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf