Re: [v6ops] Interesting problems with using IPv6

["Hemant Singh (shemant)" <[e-mail]>]

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.

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