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

Hi Mirja,

Aah, OK. IPv6 is a collateral effect then ;-)

I wonder whether you checked https://www.rfc-editor.org/rfc/rfc7969.html#section-3 (see para 4 after Figure 2, specifically).

Cheers,
Med

De : Mirja Kuehlewind <[email protected]>
Envoyé : mardi 23 juillet 2024 17:27
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Eric Vyncke (evyncke) <[email protected]>; Michael Richardson <[email protected]>; Jari Arkko <[email protected]>; dhcwg <[email protected]>
Objet : Re: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?

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: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Thursday, 18. July 2024 at 19:47
To: Mirja Kuehlewind <[email protected]<mailto:[email protected]>>, "Eric Vyncke (evyncke)" <[email protected]<mailto:[email protected]>>, Michael Richardson <[email protected]<mailto:[email protected]>>, Jari Arkko <[email protected]<mailto:[email protected]>>, dhcwg <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Envoyé : jeudi 18 juillet 2024 18:54
À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; Michael Richardson <[email protected]<mailto:[email protected]>>; Jari Arkko <[email protected]<mailto:[email protected]>>; dhcwg <[email protected]<mailto:[email protected]>>
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: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Thursday, 18. July 2024 at 10:42
To: "Eric Vyncke (evyncke)" <[email protected]<mailto:[email protected]>>, Michael Richardson <[email protected]<mailto:[email protected]>>, Jari Arkko <[email protected]<mailto:[email protected]>>, dhcwg <[email protected]<mailto:[email protected]>>
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) <[email protected]<mailto:[email protected]>>
Envoyé : jeudi 18 juillet 2024 07:43
À : Michael Richardson <[email protected]<mailto:[email protected]>>; Jari Arkko <[email protected]<mailto:[email protected]>>; dhcwg <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Date: Wednesday, 17 July 2024 at 21:13
To: Jari Arkko <[email protected]<mailto:[email protected]>>, dhcwg <[email protected]<mailto:[email protected]>>
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.
____________________________________________________________________________________________________________
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.

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]