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

[David Farmer <[e-mail]>]

At a very high level, I've been thinking about alternatives to DHCP
Snooping for PD route injection.

The first alternative would be having the client participate in a network
routing system and advertise its own PD route. However, the network must
trust the client not to inject other routes. It would be possible for the
first-hop routers to apply a policy that only allows the client to inject
its own PD route. But to apply such a policy, the first-hop router needs
the same information from DHCP snooping that it needs to inject the PD
route on behalf of the client.

Another alternative would be to change the attachment point for the PD
route in the routing architecture. The draft uses the client's link-local
address as the attachment point for the PD route. Therefore, since the
link-local address is only valid in the context of the attached link, the
client itself or a first-hop router on the attached link must be
responsible for injecting the PD route into the routing system. However, if
a ULA or GUA were used as the attachment point in the routing architecture,
then a routing protocol that allows for a remote next-hop, such as BGP,
could be used, and the DHCP server could be responsible for injecting the
PD route, possibly through a BGP route server.

While many people find DHCP snooping distasteful, given the draft's desire
to reduce the ND context as much as possible and, therefore, using the
client's link-local address as the routing attachment point, DHCP snooping
or a similar mechanism will be necessary to get the appropriate information
to the first-hop router for it to inject the PD route into the routing
system on behalf of the client.

Thanks

On Thu, Oct 5, 2023 at 1:41 AM Ole Trøan <otroan=
[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>
> [image: ietf-logo-nor-180.png]
> <https://datatracker.ietf.org/doc/html/draft-stenberg-pd-route-maintenance-00>
> <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]> 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]]
> *Sent:* Thursday, October 5, 2023 1:47 AM
> *To:* Jen Linkova <[e-mail]>
> *Cc:* Pascal Thubert <[e-mail]>; [e-mail];
> Vasilenko Eduard <[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]> 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]> 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]>
> 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]> 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]]
> >>> >> Sent: Tuesday, October 3, 2023 4:42 PM
> >>> >> To: Vasilenko Eduard <[e-mail]>
> >>> >> Cc: [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]> 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]]
> >>> >>>> Sent: Tuesday, October 3, 2023 4:17 PM
> >>> >>>> To: Vasilenko Eduard <[e-mail]>
> >>> >>>> Cc: [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]> 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]
> >>> >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>> >>>>> _______________________________________________
> >>> >>>>> v6ops mailing list
> >>> >>>>> [e-mail]
> >>> >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>> >>>> --
> >>> >>>> SY, Jen Linkova aka Furry
> >>> >>>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> SY, Jen Linkova aka Furry
> >>> >
> >>> > _______________________________________________
> >>> > v6ops mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > --
> > Pascal
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================