Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

It should also be noted that dhcpv6-pd allocations need to have a route
installed at the BRAS or other aggregation router (in my personal
experience, that is) which is likely a non-issue, but will present a
consideration for devices with small routing tables, especially in
environments with significant numbers of clients. If each client receives a
prefix, a route for each prefix needs to be instantiated which may result
in tens of thousands of routes. Not a huge issue, but a potentially
important resource detail.
The idea of using a PIO to indicate a limit of addresses available does
sound like an elegant solution. I do see some value in extending a prefix
like a /64 for host use similar to rfc7278 where "LAN" is some bridge
internal to a given host. This could be especially useful in containerized
environments which are more and more prevalent as described by Jen in the
use of container-like technology in ChromeOS and the extensive use of
containers in DC environments. They almost feel like different problem
spaces that exhibit similar symptoms.

----
nb

ᐧ

On Mon, Nov 14, 2022 at 1:14 AM Vasilenko Eduard <vasilenko.eduard=
40huawei.com@dmarc.ietf.org> wrote:

> > There is a Reserved2 field in a PIO that could be redefined to indicate
> a maximum number of addresses allowed per host under a given prefix.
>
> Hi Brian,
> It would be a good solution.
> Because local limits is better to announce from the local router.
> Announce limits from the one centralized location (DHCP server) looks more
> complex and error prone.
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Sunday, November 13, 2022 10:33 PM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Andrey Kostin <
> ankost@podolsk.ru>; V6 Ops List <v6ops@ietf.org>
> Subject: Re: [v6ops] Fwd: New Version Notification for
> draft-linkova-v6ops-ipmaclimi-00.txt
>
> On 14-Nov-22 06:44, Vasilenko Eduard wrote:
> > If the network has limits Then hosts should adapt to the limits (not
> vice versa).
> > It is needed to know the limits to adapt. DHCP could inform about the
> limit, but SLAAC could not.
>
> It could. There is a Reserved2 field in a PIO that could be redefined to
> indicate a maximum number of addresses allowed per host under a given
> prefix.
>
>     Brian
>
> >
> > The number of virtual things per hardware instance would be always
> restricted.
> > If the best AP would support 200 IP per MAC then it is still possible to
> run containers and stretch even that.
> >
> > DHCP could impose different limits per different links. Hence, if APs'
> different segment has different restrictions then DHCP would impose
> different limits.
> > If the particular link has APs with different restrictions then indeed
> DHCP should be configured to limit on the smallest.
> > Ed/
> > -----Original Message-----
> > From: Andrey Kostin [mailto:ankost@podolsk.ru]
> > Sent: Friday, November 11, 2022 9:15 PM
> > To: V6 Ops List <v6ops@ietf.org>
> > Cc: Jen Linkova <furry13@gmail.com>; Ole Troan <otroan@employees.org>;
> > Vasilenko Eduard <vasilenko.eduard@huawei.com>
> > Subject: Re: [v6ops] Fwd: New Version Notification for
> > draft-linkova-v6ops-ipmaclimi-00.txt
> >
> > Vasilenko Eduard писал(а) 2022-11-08 13:58:
> >> N+1 allocation should fail.
> >> But the network and host should be aware of it (in sync).
> >>
> >>> Or do we want NAT66?
> >> No. DHCP in this case.
> >
> > What if the underlying access network has access points from multiple
> vendors and they have different limits that are lower than allowed by DHCP?
> >
> > The problem Jen is trying to point out is not an addressing problem and
> not related either to SLAAC, DHCP or static assignment. Looks like some
> comments pronounce SLAAC guilty in described issue and try to use this
> statements to push DHCP vs SLAAC dispute. This is not the case. This is an
> operational problem caused by lack of common practice and agreement between
> vendors. And that is exactly what Jen is trying to solve. She is requesting
> to make underlying networks equipment's behavior deterministic and provide
> troubleshooting capabilities by creating log messages.
> >
> > Regarding limits, in some networks big number of IPs per host can be
> absolutely appropriate and necessary, in others there may be stricter
> limits and this is also a real use case. We all understand that everything
> is a resource and cost some money. Let's allow network owners decide what's
> reasonable for them and what's not. Like Bill Gates said that 640K of RAM
> will be always enough. Although now we are used to have a lot more memory
> in our computers and servers, but it's still expensive and each admin can
> choose how much he/she can afford.
> > So, in situations where host wants more addresses then allowed, some
> mechanism should exist to make this limit less painful and predictive.
> > DHCP is one way for it, but it can't prevent creation of multiple
> link-local or ULA addresses and it can hit ND cache limit even for
> addresses legally assigned via DHCP. So it can't be considered as a
> solution.
> > For replacement technique for me it looks simpler just to rely on ND
> cache expiration timers in the same way how it works for MAC tables.
> > Some vendors can develop more sophisticated features similar to MAC
> security to differentiate their products from the base level. Eventually a
> user who tries to use more addresses than allowed should realize that there
> is a limit and shut down some interfaces/VMs/containers/etc to obey network
> rules.
> >
> > Kind regards,
> > Andrey
> >
> >> Ed/
> >> -----Original Message-----
> >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova
> >> Sent: Tuesday, November 8, 2022 9:55 PM
> >> To: Ole Troan <otroan@employees.org>
> >> Cc: V6 Ops List <v6ops@ietf.org>
> >> Subject: Re: [v6ops] Fwd: New Version Notification for
> >> draft-linkova-v6ops-ipmaclimi-00.txt
> >>
> >> On Wed, Nov 9, 2022 at 1:12 AM Ole Troan <otroan@employees.org> wrote:
> >>>> Fact #1: my devices need to have 7-10 IPv6 addresses.
> >>>
> >>> In the network you operate, that may be a fact.
> >>> In other networks other rules.
> >>>
> >>> A requirement like that would be perfectly fine in an RFQ. Less so
> >>> in an RFC.
> >>
> >> What I'm struggling to understand from this thread is: what's the
> >> device supposed to do if it needs N addresses and the network only
> >> agrees to provide N-1?
> >> Shall the application fail? How is it better than the situation we
> >> have now?
> >> Or do we want NAT66?
> >>
> >>
> >> --
> >> SY, Jen Linkova aka Furry
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>