[v6ops] Re: [IPv6]Re: Is the P flag even necessary? M flag already does enough (Re: Re: A detail review of draft-ietf-6man-pio-pflag-04)

[Daryll Swer <[e-mail]>]

Why not:

LPD-8: The IPv6 CE Router MUST provision IA_PD prefixes with a
prefix-length of *60* unless configured to different prefix-length by the
user.

Assuming, we want to force CPEs (in turn forcing ISPs) vendors to normalise
BCOP-690 (/56 ia_pd minimum for home networks).

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/1be637bce3a03573f0aba79c5b508ea9c46d50f0?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=9e0cfb1d70527150>


On Tue, 6 Aug 2024 at 21:04, Timothy Winters <[e-mail]> wrote:

> Hi Ted,
>
> I almost made that modification and can't think of a great reason not to.
>
> OLD:
> LPD-8: The IPv6 CE Router SHOULD by default provision IA_PD IA prefixes
> with a prefix-length of 64.
>
> New:
> LPD-8: The IPv6 CE Router MUST provision IA_PD prefixes with a
> prefix-length of 64 unless configured to different prefix-length by the
> user.
>
> ~Tim
>
> On Tue, Aug 6, 2024 at 11:32 AM Ted Lemon <[e-mail]> wrote:
>
>> Yes, much better. Thanks!
>>
>> Why SHOULD and not MUST?  What is the case where they would not do this?
>>
>> Op di 6 aug 2024 om 11:26 schreef Timothy Winters <[e-mail]>
>>
>>> Hi Ted,
>>>
>>> How about this:
>>>
>>> OLD:
>>> LPD-8: The IPv6 CE Router SHOULD by default provision IA_PD IA prefixes
>>> with a prefix-length of 64.
>>>
>>> New:
>>> LPD-8: The IPv6 CE Router SHOULD provision IA_PD prefixes with a
>>> prefix-length of 64 unless configured to different prefix-length by the
>>> user.
>>>
>>> I'll make this change in the next revision.
>>>
>>> ~Tim
>>>
>>> On Tue, Aug 6, 2024 at 10:49 AM Ted Lemon <[e-mail]> wrote:
>>>
>>>> What I’m saying is that the text is ambiguous because you don’t say
>>>> what “by default” means. I am one of the people who wants to get rid of the
>>>> hierarchical model.
>>>>
>>>> Op di 6 aug 2024 om 09:05 schreef Timothy Winters <[e-mail]>
>>>>
>>>>> Hi Ted,
>>>>>
>>>>> On Mon, Aug 5, 2024 at 2:30 PM Ted Lemon <[e-mail]> wrote:
>>>>>
>>>>>> On Mon, Aug 5, 2024 at 11:16 AM Timothy Winters <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> v6ops has a draft for PD on the LAN to improve this situation.
>>>>>>>
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/
>>>>>>>
>>>>>>> Please feel free to send comments, we are about to do WGLC on it.
>>>>>>>
>>>>>>
>>>>>> Hey, Tim. I hadn't read the document in a while. I see this text in
>>>>>> the last requirement:
>>>>>>
>>>>>> The IPv6 CE Router SHOULD by default provision IA_PD IA prefixes with
>>>>>> a prefix-length of 64.
>>>>>>
>>>>>> I read this as "if the DHCP client doesn't specify a narrower prefix,
>>>>>> the CE router SHOULD .. 64"
>>>>>>
>>>>>> Is that what you intended? If not, I think you need to say more. If
>>>>>> that is what you intended, this won't work, because if we stack CE routers,
>>>>>> I expect every CE router to ask for a /48, rather than not specifying, and
>>>>>> that would mean that we'd always delegate the narrowest remaining subset of
>>>>>> the outer CE router's delegation to the first inner router that makes a
>>>>>> request.
>>>>>>
>>>>> That's what the working group wanted.  The original version of this
>>>>> document had more text about how to support hierarchical or flat models.
>>>>> After a round or two discussion what came out of that was routers behind a
>>>>> CE Router are no longer a CE Router as they aren't at the customer edge.
>>>>>  The draft reflects that general consensus, that leans towards deploying a
>>>>> flat model as opposed to hierarchical, which is where the /64 length
>>>>> derives from.
>>>>>
>>>>> I think it may be time for another document to specify what to do if
>>>>> you're a Internal Router (but not SNAC).  We could include all the flat
>>>>> model text for becoming a DHCP Relay and giving out IA_PD with /64 from the
>>>>> customer edge.
>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>