[v6ops] Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd

[Timothy Winters <[e-mail]>]

Hi Ed,

On Thu, Aug 8, 2024 at 3:02 AM Vasilenko Eduard <[e-mail]>
wrote:

> Hi Tim,
>
>    - 8415 has some text about if a client detects a change in network
>    that it should transmit a Renew which might also help.
>
> How DHCP client could see flapping on the uplink of the upstream CPE?
> (even if the client is directly connected to the CPE) How client would
> guess when DHCP Renew?
>
> Nobody in DHC WG thought about the situation when the link prefix changed
> periodically without link up/down.
>
So that's not entirely true from Section 18.2.12.

   "If not associated with one of the above-mentioned conditions, a
   client SHOULD initiate a Renew/Reply exchange (as if the T1 time
   expired) as described in Section 18.2.4 or an Information-request/
   Reply exchange as described in Section 18.2.6 if the client detects a
   significant change regarding the prefixes available on the link (when
   new prefixes are added or existing prefixes are deprecated), as this
   may indicate a configuration change."

If the addresses or prefixes change that are announced in PIO a DHCPv6
client SHOULD send a Renew.

>
>
> The situation would be much worse for IPv6 because IPv4 DHCP is not
> dependent on the flapping uplink, the IPv4 subnet is always static (and
> probably even private RFC 1918).
>
> It would be another reason not to migrate to IPv6.
>
>
>
> 37% of the world would hate you personally (not me, I do not have IPv6
> from my Carrier) – they would have stable outages. It is a “Pandora box”.
>
> How is it possible to introduce a standard that would create problems for
> 1/3 of the world?!?
>
Well I hope 37% of the world doesn't hate me personally with this draft.
As it stands now without this draft those IPv6 prefixes never go beyond the
CE Router. If a CE Router is using DHCPv6 IA_NA on the LAN these problems
exist as well.   In this case, this draft doesn't change the renumbering
problem as you describe it.

>
>
> Renumbering MUST not be ignored, especially in this case.
>
It's not ignored, it's assuming the renumbering strategy that DHCP (v4 or
v6) uses as it's built on top of that. I'm aware of several ISP deployments
that use planned renumber regularly utilizing DHCPv6 on the LAN properly
with these renumbering. The general DHCPv6 renumbering issues you are
describing, if you want to document how to avoid those issues in v6ops
document that might be useful.

> Ed/
>
> *From:* Timothy Winters <[e-mail]>
> *Sent:* Wednesday, August 7, 2024 21:46
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IPv6 Operations <[e-mail]>
> *Subject:* Re: [v6ops] Re: Working group Last call:
> draft-ietf-v6ops-cpe-lan-pd
>
>
>
> Hi Ed,
>
>
>
> On Wed, Aug 7, 2024 at 3:14 AM Vasilenko Eduard <vasilenko.eduard=
> [e-mail]> wrote:
>
>
>    - After LAN link prefix assignment the IPv6 CE Router MUST make the
>    remaining IPv6 prefixes available to other routers via Prefix Delegation.
>    ¶
>    <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-lan-pd-02#section-5.1-1.4.1>
>
> Why “other routers”? Maybe “other nodes”.
>
> Yes I can update this.
>
>
>
>    - The IPv6 CE Router MUST set the O flag to 1 in its transmit Router
>    Advertisments messages [RFC4861
>    <https://www.rfc-editor.org/info/rfc4861>].¶
>    <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-lan-pd-02#section-5.1-1.5.1>
>
> Will the host try DHCP IA_NA in this case? (that is probably not
> available) For how long it would delay address acquisition?
>
> I remember that 6man was trying hard to optimize this time (RFC 9131).
>
> By the way, it is an excellent example of why a separate flag is needed
> for IA_NA and IA_PD.
>
> Unfortunately, the P flag (planned) has a different meaning “only /64
> IA_PD is available”. Hence, the P flag is not a resolution for the problem.
>
> If you believe that the P flag is the solution to this problem – you
> should mention it.
>
> I'm removing the mention of M and O flags from the draft as it's caused
> confusion.   7084 routers have requirements for those bits for WAN. Please
> read 7084 WPD-4 and WAA-6, which are still the same.
>
>
>
>
>
> I have not found what should happen after the CPE reload. If the same
> prefix would be delegated to the CPE then would the same prefixes would be
> sub-delegated?
>
>
>
> I have not found out what would happen after the uplink flapping (very
> probable on mobile links). As we know, in 37% of cases the CPE would get a
> different prefix.
>
> There is no way to inform hosts and routers downstream, they would
> blackhole the traffic up to the lease time.
>
> This initiative looks to me as “mine the field”.
>
> It is easy to predict a lot of screams (people would step on this mine)
> and pressure on 6man/v6ops to fix this disaster.
>
> For renumbering, this works as it does now for any DHCPv6 Client, they
> will send a DHCPv6 Renew and get the new information.   8415 has some text
> about if a client detects a change in network that it should transmit a
> Renew which might also help.
>
>
>
> IMHO: it is better not to open this “Pandora box”.
>
>
>
> Ed/
>
> *From:* Nick Buraglio <[e-mail]>
> *Sent:* Tuesday, August 6, 2024 18:18
> *To:* IPv6 Operations <[e-mail]>
> *Subject:* [v6ops] Working group Last call: draft-ietf-v6ops-cpe-lan-pd
>
>
>
> All,
>
> This message begins the working group last call for
> draft-ietf-v6ops-cpe-lan-pd. Please read the draft and send your comments
> in response to this email.
>
> The draft can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/
>
>
>
> nb
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>