Re: RFC4941bis: consequences of many addresses for the network

[Naveen Kottapalli <[e-mail]>]

Hello,

Some time back a draft was submitted to tackle some of these problems in
SLAAC.

https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00

If WG is okay, we can enhance the draft to tackle more cases.

Yours,
Naveen.


On Thu, 23 Jan 2020 at 15:57, Pascal Thubert (pthubert) <[e-mail]>
wrote:

> Hello Ole
>
> There are a number of cases where the address creates a state in the
> network:
> - in case there's routing taking place within the subnet (e.g., RPL in the
> an IOT LLN and RIFT or eVPN in a data center)
> - in case the network protects the address ownership since ND doesn't
> (SEND being what it is) and does minimal SAVI
> - in case the network tries to implement ND proxy which is mandated by
> IEEE std 802.11
> - in case Jen's draft is used to proactively assign ND state in the routers
>
> In order to protect itself, the network blocks excessive amounts of
> addresses for a same device. It would serve this list to recognize it as a
> fact of life.
>
> Sadly it is very hard with IPv6 ND alone to decide which address(es) to
> keep and which to remove. For the temporary addresses, LRU seems to work
> most of the time, with  a reasonable count of like 8 as suggested below.
> But some nodes like printers (silently) keep a permanent addresses that
> should survive the churn of other temporary addresses.
>
> To serve the hosts correctly, the network is missing a classical but so
> useful information of lifetime that allows the state associated to the
> address to age out if not renewed. It is also classical in many IPv6-based
> standards (e.g., MIPv6, NEMO and RPL) that the nodes have  a chance to
> release a binding by indicating a lifetime of zero. The shortest path to
> get that is generalizing RFC 8505 to all MAC layers. *Is there any reason
> we do not?*
>
> Conversely the network cannot signal how many addresses per node will be
> served properly in parallel. It cannot recommend lifetime values for
> temporary addresses and quasi-permanent addresses. It cannot signal that it
> rebooted and that all state need to be rebuilt. We need new RA information
> for that. I can write the draft within a few days if the group is willing
> to progress the work.
>
> All the best,
>
> Pascal
>
> > -----Original Message-----
> > From: ipv6 <[e-mail]> On Behalf Of [e-mail]
> > Sent: jeudi 23 janvier 2020 09:59
> > To: 6man WG <[e-mail]>
> > Subject: RFC4941bis: consequences of many addresses for the network
> >
> > 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>