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

[Ted Lemon <[e-mail]>]

Yes, we can do that, but that can lead to Xeno’s paradox if the upstream
doesn’t renew that prefix: each renewal is for a shorter and shorter time,
so as we get close to the end most of the traffic on the link is dhcp
renewals.

I think if we get to T2 and don’t have a renewal, we can’t renew
downstream.

Op ma 12 aug 2024 om 16:15 schreef Timothy Winters <[e-mail]>

> Hi Ted,
>
>
>
> On Mon, Aug 12, 2024 at 11:15 AM Ted Lemon <[e-mail]> wrote:
>
>> Mow that you mention is, it does seem like a gap not to specify how the
>> isp lifetime and dependent router lifetime interact.
>>
>> For example, it’s probably worth making sure we don’t get into a Xeno’s
>> paradox situation with the downstream lease, because the remaining lifetime
>> isn’t constant and hence the lifetime of the downstream lease could always
>> be shorter than the lifetime of the prefix provided by the ISP. However,
>> specifying that would complexify the document a bit.
>>
>> But the main point is that I can think of several ways to choose the
>> lifetime of the downstream lease based on the current text, and that’s not
>> good. :)
>>
> Ted, one idea is we can borrow this text from the CPE Renumbering draft
> with a twist.
>
> LPD-X: IPv6 CE routers MUST NOT advertise prefixes via delegate prefixes
> via DHCPv6 on the LAN side using lifetimes that exceed the remaining
> lifetimes of the corresponding prefixes learned on the WAN side via
> DHCPv6-PD. For more details, see 9096 Section 3.3
> <https://datatracker.ietf.org/doc/html/rfc9096#section-3.3>.
>
>
>> Op ma 12 aug 2024 om 10:29 schreef Jen Linkova <[e-mail]>
>>
>>> Hi Tim,
>>>
>>> Sorry, coming late to the party (..again...;( )
>>>
>>> On Fri, Aug 9, 2024 at 4:36 AM Timothy Winters <[e-mail]> wrote:
>>> > LPD-7:
>>> > The IPv6 CE Router MUST provision IA_PD prefixes with a prefix-length
>>> of 64 unless configured to different prefix-length by the user. The prefix
>>> length of 64 is used as that is the current prefix length supported by
>>> SLAAC.
>>>
>>> While I do not have a strong opinion on that, I think that maybe
>>> saying smth like 'MUST provision....a prefix length suitable for SLAAC
>>> (currently /64)' would be better...
>>>
>>> I read the text you have in -04 as 'the router MUST provide /64 (btw
>>> we chose that number because it's the current value for SLAAC)', so
>>> the value is still hardcoded, so if we ever change the SLAAC prefix
>>> length, this document would still require an update.
>>>
>>> What do you think?
>>>
>>> A few more comments:
>>>
>>> 1) shall the draft say anything about a flash renumbering/the change
>>> of the delegated prefix?
>>> LPD-3 allows the onlink prefix change if the topology or config
>>> changes, but what about the pool? Would it be too much to ask for a
>>> reconfigure message to be sent?
>>> 2) is it assumed that T1/T2 values are consistent with T1/T2 received
>>> from the ISP?
>>> 3) It's been mentioned already, I believe, that the draft updates 7084
>>> but there is no update text. In particular, I think, it needs to
>>> update  WPD-5 to include packets to delegated prefixes.
>>>
>>>
>>> > On Thu, Aug 8, 2024 at 2:15 PM Ted Lemon <[e-mail]> wrote:
>>> >>
>>> >> What happened to the updates we talked about earlier (e.g., MUST, and
>>> explaining what "by default" means)? :)
>>> >>
>>> >> I'm otherwise okay with this text though.
>>> >>
>>> >> On Thu, Aug 8, 2024 at 2:04 PM Timothy Winters <[e-mail]>
>>> wrote:
>>> >>>
>>> >>> Hi Tim,
>>> >>>
>>> >>> I can get on board with that.
>>> >>>
>>> >>> OLD:
>>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>>> prefixes with a prefix-length of 64.
>>> >>>
>>> >>> New:
>>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>>> prefixes with a prefix-length of 64. The prefix length of 64 is
>>> >>>    used as that is the current prefix length supported by SLAAC.
>>> >>>
>>> >>> ~Tim
>>> >>>
>>> >>> On Thu, Aug 8, 2024 at 4:22 AM Tim Chown <[e-mail]>
>>> wrote:
>>> >>>>
>>> >>>> Hi Tim,
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> From: Timothy Winters <[e-mail]>
>>> >>>> Date: Wednesday, 7 August 2024 at 20:09
>>> >>>> To: Tim Chown <[e-mail]>
>>> >>>> Cc: Brian E Carpenter <[e-mail]>, Nick Buraglio
>>> <[e-mail]>, IPv6 Operations <[e-mail]>
>>> >>>> Subject: Re: [v6ops] Re: Correction: Re: Working group Last call:
>>> draft-ietf-v6ops-cpe-lan-pd
>>> >>>>
>>> >>>> Hi Tim,
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Wed, Aug 7, 2024 at 7:24 AM Tim Chown <Tim.Chown=
>>> [e-mail]> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> From: Brian E Carpenter <[e-mail]>
>>> >>>> Date: Tuesday, 6 August 2024 at 21:53
>>> >>>> To: Nick Buraglio <[e-mail]>, IPv6 Operations <
>>> [e-mail]>
>>> >>>> Subject: [v6ops] Correction: Re: Working group Last call:
>>> draft-ietf-v6ops-cpe-lan-pd
>>> >>>>
>>> >>>> I support the draft going forward.
>>> >>>>
>>> >>>> I do have one comment on the scope of the document. I believe that
>>> it should also cover use of PD for a locally assigned ULA prefix. Please
>>> don't turn this into another endless ULA thread - but if the CE has
>>> assigned a ULA prefix, and supports PD for a GUA prefix, it should also
>>> support PD for the ULA prefix.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> This seems reasonable.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Should /64 be hard coded in the document, or should it refer to a
>>> prefix of the length required to support SLAAC as currently defined?
>>> >>>>
>>> >>>> I'm concerned this will cause confusion amongst the CE Router
>>> community if I don't put an actual number.  If you really want we can 64 is
>>> based on the prefix length of SLAAC as currently defined.  How strong do
>>> you feel about this?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Not strongly, but the WG has of late been trying not to
>>> unnecessarily hard code the 64 into documents. If 64 is used, then a short
>>> statement as to why would be good.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> The pd-per-device draft uses /64 in an example and says “Note that
>>> the prefix lengths used in the example are /64 because that is the prefix
>>> length currently supported by SLAAC and is not otherwise required by the
>>> proposed deployment model” and says a little more on /64 in section 8 which
>>> also refers to RFC 7084, and in section 11. The 64 isn’t “hard coded” in
>>> there, in that its use in the example is clearly explained.
>>> >>>>
>>> >>>> Minor nit – the “addresses” at the end of para 1 of the intro
>>> should probably say “prefixes”.
>>> >>>>
>>> >>>> thanks, fixed in -03.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Best wishes,
>>> >>>>
>>> >>>> Tim
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Tim
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> (There are several grammatical nits in the Introduction. I'll send
>>> them to the author off-list.)
>>> >>>>
>>> >>>> Regards
>>> >>>>      Brian Carpenter
>>> >>>>
>>> >>>> On 07-Aug-24 03:18, Nick Buraglio wrote:
>>> >>>> > 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/ <
>>> 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]
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> v6ops mailing list -- [e-mail]
>>> >>>> To unsubscribe send an email to [e-mail]
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> v6ops mailing list -- [e-mail]
>>> >>>> To unsubscribe send an email to [e-mail]
>>> >>>
>>> >>> _______________________________________________
>>> >>> v6ops mailing list -- [e-mail]
>>> >>> To unsubscribe send an email to [e-mail]
>>> >
>>> > _______________________________________________
>>> > v6ops mailing list -- [e-mail]
>>> > To unsubscribe send an email to [e-mail]
>>>
>>>
>>>
>>> --
>>> Cheers, Jen Linkova
>>>
>>