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

[Vasilenko Eduard <[e-mail]>]

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.

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?!?

Renumbering MUST not be ignored, especially in this case.
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]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, August 6, 2024 18:18
To: IPv6 Operations <[e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>