Subject: rfc4941bis: On the use of multiple addresses

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 19:49:08 -0300

Folks,

Based on the recent discussion regarding the possible impact of the use 
of multiple addresses, I suggest we include the following text in 
Section 4 of rfc4941bis:

"Network deployments are currently recommended to provide multiple IPv6 
addresses from each prefix to general-purpose hosts. However, in some 
scenarios, use of a large number of IPv6 addresses may have negative 
implications on some network devices (e.g. [RFC6583]), exacerbate other 
operational problems (e.g. [draft-ietf-mboned-ieee802-mcast-problems]) 
and/or may lead to traffic employing these addresses being dropped by 
devices that enforcing port security that may enforce a limit on the 
maximum number of configured addresses per host (e.g. [RFC7039]). A 
discussion on possible approaches to allow for unconstrained use of IPv6 
addresses can be found in [RFC7934]"

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: David Farmer <[email-masked]>
Date: Thu, 30 Jan 2020 17:20:10 -0600

> addresses can be found in [RFC7934]"

maybe "...found in [RFC7934] and one of these approaches is defined in
[RFC8273]."

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 20:34:41 -0300

On 30/1/20 20:20, David Farmer wrote:
> 
> 
> On Thu, Jan 30, 2020 at 4:54 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 

Certainly [RFC8273] sketches how to do "Unique Prefix Per Host with 
SLAAC". However, I wonder the state to which it is a spec: there are 
many things that are unspecified. Besides, in all fairness, one should 
also mention DHCPv6-PD. Not sure if I would go for that level of detail...

THoughts?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Jan 2020 09:18:15 +0900

I don't think the two RFC citations are appropriate. RFC 6583 is about the
size of subnets, not about the number of hosts per subnet. RFC 7039 is
about the SAVI framework, and I don't think there's anything in there about
limiting the number of bindings. I also can't find anything in that
document that talks about "enforcing port security that may enforce a limit
on the maximum number of configured addresses per host". SAVI is a security
mechanism to prevent spoofing, not a mechanism to limit the number of
addresses.

draft-ietf-mboned-ieee802-mcast-problems is relevant in the sense that more
addresses on the link create more neighbour discovery traffic. So how about
rewording to the following?

=====
Network deployments are currently recommended to provide multiple IPv6
addresses from each prefix to general-purpose hosts. In some scenarios, use
of a large number of IPv6 addresses may have negative implications on
network devices that permanently maintain forwarding entries for all
neighbour caches (e.g., [RFC7039]). Additionally, concurrent active use of
multiple IPv6 addresses will increase neighbour discovery traffic if
neighbour caches in network devices are not large enough to store all
addresses on the link. This can impact performance and energy efficiency on
networks on which multicast is expensive (e.g.
[draft-ietf-mboned-ieee802-mcast-problems]).
=====

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 06:05:53 +0000

This is playing ostrich again.

 Limiting the amount of addresses is an obvious implication of SAVI in a managed network. When we did RFC 8505 the Sec-Dir review insisted to have text  to protect against DOS attacks. The SAVI draft did not go through that full cycle and is not complete to that regard. So I think the original text was a lot better.

And the size of the cache is mostly irrelevant to the ND churn these days. When addresses are dropping for the lack of rmemory there’s really an issue.  What’s relevant is the amount of new addresses joining the network, the number of nodes in the network that need to resolve it, and what nodes do when they sleep cycle or roam.

We measured (on the wire) several hundred multicast per second in average over 90 minutes during a keynote with a large audience. /64 per host is indeed tempting in such environment. But it boils down to IPv4 with 8 bytes addresses. We can do better.

Regards,

Pascal

Le 31 janv. 2020 à 01:18, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :

I don't think the two RFC citations are appropriate. RFC 6583 is about the size of subnets, not about the number of hosts per subnet. RFC 7039 is about the SAVI framework, and I don't think there's anything in there about limiting the number of bindings. I also can't find anything in that document that talks about "enforcing port security that may enforce a limit on the maximum number of configured addresses per host". SAVI is a security mechanism to prevent spoofing, not a mechanism to limit the number of addresses.

draft-ietf-mboned-ieee802-mcast-problems is relevant in the sense that more addresses on the link create more neighbour discovery traffic. So how about rewording to the following?

=====
Network deployments are currently recommended to provide multiple IPv6 addresses from each prefix to general-purpose hosts. In some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that permanently maintain forwarding entries for all neighbour caches (e.g., [RFC7039]). Additionally, concurrent active use of multiple IPv6 addresses will increase neighbour discovery traffic if neighbour caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (e.g. [draft-ietf-mboned-ieee802-mcast-problems]).
=====

On Fri, Jan 31, 2020 at 7:54 AM Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Thoughts?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Jan 2020 15:49:50 +0900

On Fri, Jan 31, 2020 at 3:06 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Limiting the amount of addresses is an obvious implication of SAVI in a
> managed network. When we did RFC 8505 the Sec-Dir review insisted to have
> text  to protect against DOS attacks. The SAVI draft did not go through
> that full cycle and is not complete to that regard. So I think the original
> text was a lot better.
>

The fact remains that if the SAVI RFC contains no text in support of a
statement, it should not be cited in support of the statement. Maybe we can
say that if address tracking technologies are in use, and network devices
run out of memory to store address mappings, then creating further
addresses will result in some of them not being usable. This is not a
policy issue, it's a scaling issue.

And the size of the cache is mostly irrelevant to the ND churn these days.
> When addresses are dropping for the lack of rmemory there’s really an
> issue.  What’s relevant is the amount of new addresses joining the network,
> the number of nodes in the network that need to resolve it, and what nodes
> do when they sleep cycle or roam.
>

Ok, but that text is too vague. What specific problems would you like to
mention here? From the two lines you just wrote it sounds like when nodes
create many addresses, there is lots of ND traffic, and:

   1. Networks that inspect all ND (e.g., if SAVI in use) can run out of
   CPU cycles because there is too much ND traffic.
   2. If there are very battery-constrained devices on the network, the
   power used to listen to ND packets can meaningfully impact battery life.
   (In the real world, this does not happen to laptop or phone class devices,
   but it can probably happen to lower-power devices.)

We measured (on the wire) several hundred multicast per second in average
> over 90 minutes during a keynote with a large audience. /64 per host is
> indeed tempting in such environment. But it boils down to IPv4 with 8 bytes
> addresses. We can do better.
>

500 pps of multicast sounds like a lot, but if the network is very large,
well, ND scales linearly with the size of the network (assuming L=0 which
for a network with thousands of hosts it pretty much has to be). The only
meaningful measurement here is what percentage of airtime was used by ND,
and that shouldn't vary too much from network to network. As for better,
well, it depends. From a host perspective, being able to create addresses
without having to ask the network is desirable.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 15:45:31 +0000

My words below can be misinterpreted, and I apologize. I’m sure that SAVI went through due review process.

I’m just disappointed that the Security Considerations do not mention the need for the SAVI node to protect itself against DoS attacks, which is what SEC_DIR asked us to do with RFC 8505, and what we did when implementing it.

Quoting RFC 8505

The registration mechanism may be used by a rogue node to attack the
   6LR or 6LBR with a denial-of-service attack against the registry.  It
   may also happen that the registry of a 6LR or 6LBR is saturated and
   cannot take any more registrations; this scenario effectively denies
   the requesting node the capability to use a new address.  In order to
   alleviate those concerns, (1) Section 5.2<https://tools.ietf.org/html/rfc8505#section-5.2> provides a sequence counter
   that keeps incrementing to detect and clean up stale registration
   information and that contributes to defeat replay attacks and
   (2) Section 5.7<https://tools.ietf.org/html/rfc8505#section-5.7> provides a number of recommendations that ensure that
   a stale registration is removed as soon as possible from the 6LR
   and 6LBR.

Sorry for that,

Pascal

From: ipv6 <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 31 janvier 2020 07:06
To: Lorenzo Colitti <lorenzo=[email-masked]>
Cc: Fernando Gont <[email-masked]>; [email-masked]
Subject: Re: rfc4941bis: On the use of multiple addresses

Regards,

Pascal

Le 31 janv. 2020 à 01:18, Lorenzo Colitti <lorenzo=[email-masked]<mailto:lorenzo=[email-masked]>> a écrit :

=====

Thoughts?

Thanks!

Cheers,