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

[Timothy Winters <[e-mail]>]

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]
>