Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

[Vasilenko Eduard <[e-mail]>]

Indeed, snooping could be completely cancelled.
But then the prefix for this link should be big enough to withstand the biggest crowd attacking this WiFi link.
It would need renumbering in many cases.
But then we could have a workaround: the link could have an additional prefix (even with a different size) – clients do not have local communication anyway.

All in all, it would be very similar to ordinary DHCP, where snooping is not needed, and parent prefixes are attached to the link manually.
Ed/
From: Paolo Nero [mailto:[e-mail]]
Sent: Thursday, October 5, 2023 9:50 AM
To: Ole Trøan <[e-mail]>
Cc: Vasilenko Eduard <[e-mail]>; Jen Linkova <[e-mail]>; IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

Why not prescribe/suggest to use a pool from the prefix already routed to the site in the first place? It seems this would be in line with the spirit of the draft, i.e. exploiting the richness of addressing in a /48.

Relays could still fail to see the REPLY then, but you would be guaranteed that at least one of them saw it and the issue would be limited to the "inside" route and not the IGP.

Thanks

Paolo

On Thu, Oct 5, 2023, 08:41 Ole Trøan <[e-mail]<mailto:[e-mail]>> wrote:
Snooping is indeed tricky.
For PD route injection I don’t think much has happened since:
IPv6 Prefix Delegation routing state maintenance approaches<https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00>
datatracker.ietf.org<https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00>

[ietf-logo-nor-180.png]<https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00>




Any better ideas?

O.


On 5 Oct 2023, at 08:28, Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:

IMHO: Paolo and Pascal are effectively talking (in a different way) that snooping is not reliable mechanism to depend routing on it.
Ed/
From: Paolo Nero [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, October 5, 2023 1:47 AM
To: Jen Linkova <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

Hi Jen,

On Wed, Oct 4, 2023 at 1:27 PM Jen Linkova <[e-mail]<mailto:[e-mail]>> wrote:

Oh I see the source of the confusion. As I've said in another email -
the text *implies* that the relay injects the routes into IGP and
we'll make it explicit in the next revision.

please forgive me if I'm missing something, but what would be the consequence, in a topology with multiple first-hop routers/relays, of one of the routers missing a RELEASE message (e.g. due to packet loss of the multicast transmission)? Would that router keep injecting the route into the infrastructure at large? On first thought it seems this would be more impactful than when simply snooping IA_NA, or when losing a REPLY message. Could that prefix be reassigned elsewhere while the route is still "stuck"?

Thanks,

Paolo


>
>
> Le mer. 4 oct. 2023 à 09:47, Lorenzo Colitti <[e-mail]<mailto:[e-mail]>> a écrit :
>>
>> Pascal,
>>
>> I'm not sure I understand how what we are proposing is different to what is in use today. Today, any network that uses DHCPv6 snooping (e.g., for SAVI purposes) must snoop DHCPv6 replies, no? Those replies are sent unicast by the DHCPv6 server through the relays to the client. The same set of devices that snoops replies and processes IA_NA options can process the IA_PD options in those replies.
>>
>> There is a bit of a difference in the sense that for IA_NA the snooping devices only populate ACLs, whereas for IA_PD, some of the snooping devices - likely the first-hop router(s) - must inject into the IGP mesh a route pointing to the prefix assigned to the client. But I don't understand why this matters. Those devices snoop the DHCPv6 reply anyway, no?
>>
>> Cheers,
>> Lorenzo
>>
>> On Wed, Oct 4, 2023 at 4:38 PM Pascal Thubert <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> Hello Eduard and Jen
>>>
>>> Snooping by all access routers might appear to be working in a lab but there’s no way to impose that in an enterprise network.
>>>
>>> There can be multiple / many access routers (think ToRs), possibly distributed over the WAN as an overlay.  In such network one would choose that either all ToRs run a dhcp relay but then they block the broadcast or there’s only only relay ( with appropriate HA ). But it is unrealistic to expect that the DHCP request will be relayed by all ToRs. I hope we do not write such a recommendation in an ops document!
>>>
>>> Moreover there is ample experience with ND and MLD that snooping broadcast protocols is the sure recipe for repeated calls to support for unpredictable and difficult to debunk issues.
>>>
>>> And then there’s the problem of routing from the higher aggregation point to the ToR. Some routes will have to be injected somewhere.
>>>
>>> Bottom line is that as written, the draft will only add to the long list of arguments for enterprise people who claim that IPv6 is not for them, along with the issues that the draft attempts to solve, e.g., SLAAC.
>>>
>>> Suggestion for this draft would be to at least recognize that there’s a missing link in the standard suite and indicate on the positive side that 6MAN has an architecture on the works that solves the issue in a secure fashion.
>>>
>>> Regards,
>>>
>>> Pascal
>>>
>>> > Le 3 oct. 2023 à 15:58, Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> a écrit :
>>> >
>>> > OK. Therefore it is a new requirement for the DHCP server. It does look not very difficult.
>>> > But it is interesting anyway: Do DHCP vendors support it out of the box (just configuration) or is development needed?
>>> > Ed/
>>> >> -----Original Message-----
>>> >> From: Jen Linkova [mailto:[e-mail]<mailto:[e-mail]>]
>>> >> Sent: Tuesday, October 3, 2023 4:42 PM
>>> >> To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
>>> >> Cc: [e-mail]<mailto:[e-mail]>
>>> >> Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02
>>> >>
>>> >>> On Tue, Oct 3, 2023 at 6:39 AM Vasilenko Eduard
>>> >>> <[e-mail]<mailto:[e-mail]>> wrote:
>>> >>> Are you sure that the DHCP server would answer many client requests
>>> >> (received through different relays) with the same transaction-id?
>>> >>> Where in RFC 8415 is it stated?
>>> >>
>>> >> I do not think it's stated there, it's up to implementation. Hence we
>>> >> have a specific text in Section 7, saying that "while deploying this
>>> >> solution, please configure your server that way".
>>> >>
>>> >>> Why server should do it?
>>> >>
>>> >> Why shouldn't it?
>>> >>
>>> >>> Eduard
>>> >>>> -----Original Message-----
>>> >>>> From: Jen Linkova [mailto:[e-mail]<mailto:[e-mail]>]
>>> >>>> Sent: Tuesday, October 3, 2023 4:17 PM
>>> >>>> To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
>>> >>>> Cc: [e-mail]<mailto:[e-mail]>
>>> >>>> Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02
>>> >>>>
>>> >>>> On Mon, Oct 2, 2023 at 5:04 AM Vasilenko Eduard
>>> >>>> <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
>>> >>>>
>>> >>>>> "(it should be noted that [I-D.dhcwg-dhc-rfc8415bis] deprecates the
>>> >> Server
>>> >>>> Unicast option exactly because it is not compatible with multiple relays
>>> >>>> topology). Therefore as long as the Server Unicast option is not used, all
>>> >> first-
>>> >>>> hop routers shall be able to install the route for the delegates prefix".
>>> >>>>> dhcwg-dhc-rfc8415bis looks critical but it is expired. Is it possible to
>>> >> delete
>>> >>>> this reference?
>>> >>>>
>>> >>>> Sorry, I'll fix the reference - it should be
>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/ which is
>>> >>>> an active draft.
>>> >>>>
>>> >>>>> " As per Section 18.4 of [RFC8415] the server is not supposed to accept
>>> >>>> unicast traffic when it is not explicitly configured to do, and unicast
>>> >>>> transmission is only allowed for some messages and only if the Server
>>> >>>> Unicast option ([RFC8415], Section 21.12) is used."
>>> >>>>> This is not relevant information - it is about the client transmission.
>>> >>>>
>>> >>>> It is relevant, because as long as the client sends multicast
>>> >>>> messages, all routers (relays) see the message and relay it. So each
>>> >>>> really would send a relay message - as a unicast - to the server. Each
>>> >>>> relay would receive a unicast Relay-repy, which will be used to  snoop
>>> >>>> the route and send to the client.
>>> >>>>
>>> >>>>> Another router should see the server unicast reply to understand the
>>> >> prefix.
>>> >>>>
>>> >>>> Indeed it would receive a unicast reply. The source address of the
>>> >>>> IPv6 packet containing the relayed message would be the relay address.
>>> >>>>
>>> >>>>> On 9/30/2023 4:42 PM, Xipengxiao wrote:
>>> >>>>>
>>> >>>>> Hi Folks,
>>> >>>>>
>>> >>>>> This message initiates a WGLC for draft-ietf-v6ops-dhcp-pd-per-device-
>>> >> 02.
>>> >>>> The call will end on Oct 14, 2023.  Your opinion will be valued.
>>> >>>>>
>>> >>>>> Ron & XiPeng
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> v6ops mailing list
>>> >>>>> [e-mail]<mailto:[e-mail]>
>>> >>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> >>>>> _______________________________________________
>>> >>>>> v6ops mailing list
>>> >>>>> [e-mail]<mailto:[e-mail]>
>>> >>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> >>>> --
>>> >>>> SY, Jen Linkova aka Furry
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> SY, Jen Linkova aka Furry
>>> >
>>> > _______________________________________________
>>> > v6ops mailing list
>>> > [e-mail]<mailto:[e-mail]>
>>> > https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
> Pascal
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops



--
SY, Jen Linkova aka Furry

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops