[dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

[Mirja Kuehlewind <[e-mail]>]

Hi Med,

it would be easier to not touch the RAN network and stay with IPv4 but in DHCPv4 we don’t have a way to distribute topology information that we need for automated setup. We first thought about proposing a similar solution as RFC6221 for DHCPv4, however, at the last meeting the idea came up to use DHCPv6 relay in the first hop instead.

Mirja



From: "[e-mail]" <[e-mail]>
Date: Thursday, 18. July 2024 at 19:47
To: Mirja Kuehlewind <[e-mail]>, "Eric Vyncke (evyncke)" <evyncke=[e-mail]>, Michael Richardson <[e-mail]>, Jari Arkko <[e-mail]>, dhcwg <[e-mail]>
Subject: RE: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

Re-,

Thanks Mirja for the clarification.

I sill don’t understand the need especially for the “legacy case”. Why should that legacy touched at the first place? What matters for deploying IPv6 is the user plane, not the transport plane.

Cheers,
Med

De : Mirja Kuehlewind <[e-mail]>
Envoyé : jeudi 18 juillet 2024 18:54
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Eric Vyncke (evyncke) <evyncke=[e-mail]>; Michael Richardson <[e-mail]>; Jari Arkko <[e-mail]>; dhcwg <[e-mail]>
Objet : Re: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

Hi all,

thanks a lot for the feedback! I agree that the RAN use case if just one use and this is a more general mechanism but we wanted to make sure the group understand out actual need here. We will move this in the appendix in the next version and we can even remove it entirely before publication.

To answer a few question that came up: First, why can we not just update the client? Because that is not in our hands. The Radio Unit are already deployment and there is no reason to make a big investment and replace them just for IPv6. As such this solution is at least a way to independently update the RAN network to IPv6. Second, Ericsson is the vendor for the Radio equipment and we also sometimes deploy the networks for the operators but the network equipment in the RAN network is equipment from other vendors. As such it would be really useful for us to have a stable specification that we can ask these vendors to implement.

Hope that helps a bit!

Mirja



From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 18. July 2024 at 10:42
To: "Eric Vyncke (evyncke)" <evyncke=[e-mail]<mailto:evyncke=[e-mail]>>, Michael Richardson <[e-mail]<mailto:[e-mail]>>, Jari Arkko <[e-mail]<mailto:[e-mail]>>, dhcwg <[e-mail]<mailto:[e-mail]>>
Subject: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

Hi all,

I would agree that RAN mention is a distraction if we have other cases to illustrate the need.

The RAN case is interesting as the clients (and likely the server) are under the control of the same entity. I fail to see why deploying a hack (4o6 relay) is optimal here.

Putting that aside, RFC7341 has a clear applicability scope:

   This is intended as a special-purpose mechanism that
   will be implemented **on nodes that must obtain IPv4 configuration**
   information using DHCPv4 in specific environments where native DHCPv4
   is not available.

Cheers,
Med

De : Eric Vyncke (evyncke) <evyncke=[e-mail]<mailto:evyncke=[e-mail]>>
Envoyé : jeudi 18 juillet 2024 07:43
À : Michael Richardson <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>
Objet : [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

Hello Michael

[and without any hat] I also think that this document would benefit if the RAN use case was removed. I.e., plain DHCPv4 relay over DHCPv6 is interesting enough and more generic.

Regards

-éric


From: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 17 July 2024 at 21:13
To: Jari Arkko <[e-mail]<mailto:[e-mail]>>, dhcwg <[e-mail]<mailto:[e-mail]>>
Subject: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

I reviewed    draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra-00
I am confused by the radio uni use cases.  Is this 5G or what exactly?  I
assume because this is coming from Ericsson, that it's 5G.  I guess I'm
surprised DHCPv4 is relevant.

I'm also unclear how/if this requires multi-vendor interoperability.
I think it probably does, but I'd like to understand where the lines are.

It seems like interesting and useful work in eleminating old DHCPv4
infrastructure.  I'm happy to adopt the document into DHC. I think that the
use case could perhaps be a bit more concrete.

Some in the WG have been relucant to work on clearer DHCP server->Relay Agent
options for topology (such as PD delegated), with some claiming that the
current technique of scraping into the DHCP messages by the relay is "running
code". But my impression is that this document would also benefit from.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.