Re: [v6ops] Interesting problems with using IPv6

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Tue, 09 September 2014 15:41 UTC

Return-Path: <ayourtch@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC5F1A6FE3 for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 08:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level:
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 tarL8cofSaHa for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 08:41:40 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12AD1A6FD8 for <v6ops@ietf.org>; Tue, 9 Sep 2014 08:41:40 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id hn18so4757886igb.5 for <v6ops@ietf.org>; Tue, 09 Sep 2014 08:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T1KIjXAkOhyTcC3C/Mx4Qa9o3JWQjOV5YX54ecR7gdo=; b=Sl40mHXJf9oWNisS5DUAenfivIzqgd+sLZmTf7KTn06eeKr+JB/GcPgw2EZFYRCOMr Q4tLPhfkV9MPXPSLS+lFduX9Ezt6dvM333615RQy65AMgsdZnvjD0xH7zjkRMN0bfjDb J8XdjTrLJMjDy+r1L39XH9zYOVytIpR1rYVJ1NAFH/+tV36dOj1Jzm402fJjm5hDb1D3 kxMWmONy+qamb0EOG6+/Hocq9OvXcbBye6CfxKgbCBw2vdtFinw8ouApv3dsZ4LIL3Kx bEjDS28Q4dekfeFLqnDdbQxOmfzxRbl8ZKhvNGW3Gs7NENiL281yXu9rud474qesox1Z NlYg==
MIME-Version: 1.0
X-Received: by 10.50.56.38 with SMTP id x6mr32679729igp.30.1410277299832; Tue, 09 Sep 2014 08:41:39 -0700 (PDT)
Received: by 10.107.137.39 with HTTP; Tue, 9 Sep 2014 08:41:39 -0700 (PDT)
In-Reply-To: <20140909142226.GP15839@angus.ind.WPI.EDU>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540ECB9E.9000102@foobar.org> <CAKD1Yr1_sCLHv=D3MeCe47Fa0dxXTXH5B+=wOKpvmEDFkJFiZw@mail.gmail.com> <75B6FA9F576969419E42BECB86CB1B89155AF364@xmb-rcd-x06.cisco.com> <20140909142226.GP15839@angus.ind.WPI.EDU>
Date: Tue, 9 Sep 2014 17:41:39 +0200
Message-ID: <CAPi140Nwzjh-f_kj9tWmcmcjqh55nUdyr6EjHbQySom+SvX_fQ@mail.gmail.com>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <ayourtch@gmail.com>
To: Chuck Anderson <cra@wpi.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/smxo8VKMg-HfN3hNiOW9xUZAZPM
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Interesting problems with using IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 09 Sep 2014 15:41:42 -0000

On 9/9/14, Chuck Anderson <cra@wpi.edu> wrote:
> Disagree.
>
> In common practice, ARP doesn't need to scale to hundreds of IPv4
> addresses per host.  Unforutnately, IPv6 SLAAC with Privacy Addressing
> means that ND and hence MLD does need to scale much larger than ARP
> ever did.  The cure of using Solicited Node multicast for ND is worse
> than the disease of using broadcast for ARP.
>
> It is not reasonable to expect a switch to scale to maintaining state
> for 300 * (# of hosts connected) Solicited-Node multicast groups.
> 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable.
> 90,000 MLD groups for a 300 port switch stack is also unreasonable.

Not delving into the whole "why in today-scale network we need to
maintain separate groups per each solicited multicast" argument, let's
just assume there are some noticeable gains there and focus on the
number of groups.

1) http://tools.ietf.org/html/rfc4941#section-3.3 says:

   1.  Process the Prefix Information Option as defined in [ADDRCONF],
       either creating a new public address or adjusting the lifetimes
       of existing addresses, both public and temporary.  If a received
       option will extend the lifetime of a public address, the
       lifetimes of temporary addresses should be extended, subject to
       the overall constraint that no temporary addresses should ever
       remain "valid" or "preferred" for a time longer than
       (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
       DESYNC_FACTOR), respectively.  The configuration variables
       TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
       approximate target lifetimes for temporary addresses.

One way to interpret this text is that with the defaults, a host with
SLAAC and temporary addresses will have: 1 LL + 1 SLAAC + 7 temp
addresses = 9.

This gives 1.5 order of magnitude less groups than in the example you
cite - a not terribly unreasonable number, though it's still a 9x
amount.

The TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME are host-coded,
the network (for better or worse) appears to have not much say about
them.

2) The "300 addresses" situation might look like either the defaults
were changed, or the stack is being "helpful" as described in
http://tools.ietf.org/html/rfc4941#section-6:

   An implementation might want to keep track of which addresses are
   being used by upper layers so as to be able to remove a deprecated
   temporary address from internal data structures once no upper layer
   protocols are using it (but not before).  This is in contrast to
   current approaches where addresses are removed from an interface when
   they become invalid [ADDRCONF], independent of whether or not upper
   layer protocols are still using them.  For TCP connections, such
   information is available in control blocks.  For UDP-based
   applications, it may be the case that only the applications have
   knowledge about what addresses are actually in use.  Consequently, an
   implementation generally will need to use heuristics in deciding when
   an address is no longer in use.

Would this mean the host has a connection that is lasting 300 days and
is using the same temporary address ? This does not look too
temporary, so arguably that application should not be using temporary
addresses (Also: interesting that e.g. Linux limits the default # to
16 - cf.: http://oss.sgi.com/archives/netdev/2004-01/msg01002.html
which is still true in the Ubuntu 14.04.)

BTW, talking about the applications, they should be able to select
whether they need the temporary addresses or not: rfc5014. Do they
intentionally select the temporary addresses on the long-lasting
connections ?

Now, let me argue with myself:

1) IPv6 requiring 9x time the IPv4 addresses is still quite a stretch.
If someone needs a long-lasting session, they should use a stable
address.

2) Does application have a way to say "I do not want temporary addresses" ?
(cf: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756)
Seems not today ?

3) Also, http://tools.ietf.org/html/rfc4941#section-3.6 clearly says:

" In addition, some applications may not behave
   robustly if temporary addresses are used and an address expires
   before the application has terminated, or if it opens multiple
   sessions, but expects them to all use the same addresses.
   Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions.  Individual
   applications, which have specific knowledge about the normal duration
   of connections, MAY override this as appropriate."


So, if the hosts were gentle with the number of addresses they try to
use, apps with long-lasting connections were to disable the temporary
addresses and the server fleet had the temporary addresses disabled
altogether, SLAAC (and, where appropriate, temporary addresses) would
not be so bad at all.

Of course, the amount of manual work this requires today means that
the A-bit is turned off and the DHCPv6 is being used. Which may be
perfectly okay - but if it is not, and we do assert that "An RA with
prefix having an A-bit set and default settings, should not cause the
10x expansion to the resource requirements compared to Legacy IP",
seems like some sort of a correction in default stacks/apps behavior
with respect to temporary addresses could be useful.

--a