Re: [v6ops] Interesting problems with using IPv6

[Andrew 👽 Yourtchenko <[e-mail]>]

Hemant,

On 9/9/14, Hemant Singh (shemant) <[e-mail]> wrote:
> Andrew,
>
> Great input from you.   However, there is one catch.  A basic switch works
> at layer-2 and may not have its implementation communicate with upper
> transport layers such as TCP and UDP.  The switch is merely snooping MLD.
> Then the switch should just support never letting its cpu go higher than 40%
> and rate limit processing in the switch punt path.

"should", absolutely!

But safeguarding by other means to avoid the fireworks and explosions
if this "should" is violated due to human error (designer, programmer,
operator, or user) seems like a prudent engineering choice.

Besides, the multicast group explosion and MLD traffic is just one of
the facets related to excessive temporary addresses that just happens
to be in the spotlight today, but it is not the only one.

--a

>
> Hemant
>
> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Andrew ??
> Yourtchenko
> Sent: Tuesday, September 09, 2014 11:42 AM
> To: Chuck Anderson
> Cc: [e-mail]
> Subject: Re: [v6ops] Interesting problems with using IPv6
>
>
> 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
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>