Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
Thanks Michael, I will bring this point to have the discussion with our customer. Thanks, Jim -Original Message- From: Michael Brown [mailto:mc...@ipxe.org] Sent: Friday, January 22, 2016 4:31 PM To: Fu, Siyuan Cc: Jim Hung (洪銘駿); edk2-devel@lists.01.org Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address On 22/01/16 02:59, Fu, Siyuan wrote: > Thanks Michael, maybe use UUID is a good way to solve this issue. But I still > curious why the server has such requirement which is apparent violate the RFC > requirement. Could you provide more details? The DHCPv6 RFC was designed without taking network boot into account. There is no way, for example, for a network bootloader to use the same DUID as the operating system that is going to be booted, since the DUID includes elements of arbitrary choice (e.g. which network device to use for a DUID-LL, and which time to use in a DUID-LLT). RFC 6355 attempts to improve this situation, by suggesting that all DHCPv6 clients should converge on the use of DUID-UUID. This at least eliminates the elements of arbitrary choice, and makes it possible for a bootloader to use the same DUID as the booted operating system. However, many customers (such as yours) are used to creating reservations by MAC address rather than by UUID. With DUID-UUID, the MAC address is not exposed anywhere in the DHCPv6 packet. There is no good solution to this problem at present. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
On 22/01/16 02:59, Fu, Siyuan wrote: Thanks Michael, maybe use UUID is a good way to solve this issue. But I still curious why the server has such requirement which is apparent violate the RFC requirement. Could you provide more details? The DHCPv6 RFC was designed without taking network boot into account. There is no way, for example, for a network bootloader to use the same DUID as the operating system that is going to be booted, since the DUID includes elements of arbitrary choice (e.g. which network device to use for a DUID-LL, and which time to use in a DUID-LLT). RFC 6355 attempts to improve this situation, by suggesting that all DHCPv6 clients should converge on the use of DUID-UUID. This at least eliminates the elements of arbitrary choice, and makes it possible for a bootloader to use the same DUID as the booted operating system. However, many customers (such as yours) are used to creating reservations by MAC address rather than by UUID. With DUID-UUID, the MAC address is not exposed anywhere in the DHCPv6 packet. There is no good solution to this problem at present. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
On 21/01/16 10:13, Jim Hung (洪銘駿) wrote: There is one network issue in customer datacenter, the “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source network device if multi LANs on the system. And, this cause the PXE boot failure at customer datacenter environment. On our system, it has two network devices, one is Intel NIC, the other is Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to generate the DULD-LLT. However at customer Data Center, they do NOT accept this. Each interface needs to generate their DUID-LL(T) based on their own LL. This means that they must use their own MAC address. Both interface will have different DUIL-LL(T), which is technically against the RFC here. Can you please help to check how networkstack driver could be supported on this requirement? We have encountered exactly the same problem in iPXE. We decided to adopt the solution proposed by RFC6355: we use DUID-UUID rather than any of the DUID-LL(T) variants. This is the only sensible way in which we can hope to make the same choice of DUID as the loaded operating system. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
Thanks Michael, maybe use UUID is a good way to solve this issue. But I still curious why the server has such requirement which is apparent violate the RFC requirement. Could you provide more details? Best Regards Siyuan -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Brown Sent: Thursday, January 21, 2016 10:49 PM To: "Jim Hung (洪銘駿)" <jim.h...@quantatw.com>; edk2-devel@lists.01.org Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address On 21/01/16 10:13, Jim Hung (洪銘駿) wrote: > There is one network issue in customer datacenter, the > “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source > network device if multi LANs on the system. And, this cause the PXE boot > failure at customer datacenter environment. > > On our system, it has two network devices, one is Intel NIC, the other is > Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to > generate the DULD-LLT. However at customer Data Center, they do NOT accept > this. Each interface needs to generate their DUID-LL(T) based on their own > LL. This means that they must use their own MAC address. Both interface will > have different DUIL-LL(T), which is technically against the RFC here. > > Can you please help to check how networkstack driver could be supported on > this requirement? We have encountered exactly the same problem in iPXE. We decided to adopt the solution proposed by RFC6355: we use DUID-UUID rather than any of the DUID-LL(T) variants. This is the only sensible way in which we can hope to make the same choice of DUID as the loaded operating system. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
A while ago, a change was added to EDK2 to introduce a Pcd to select either
DUID-LLT or DUID-UUID. Did you look at modifying that PCD?
Sent from my Android phone using Symantec TouchDown (www.symantec.com)
-Original Message-
From: Fu, Siyuan [siyuan...@intel.com]
Received: Thursday, 21 Jan 2016, 8:59PM
To: Michael Brown [mc...@ipxe.org]
CC: edk2-devel@lists.01.org [edk2-devel@lists.01.org]; Jim Hung (洪銘駿)
{[jim.h...@quantatw.com]
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per
own MAC address
Thanks Michael, maybe use UUID is a good way to solve this issue. But I still
curious why the server has such requirement which is apparent violate the RFC
requirement. Could you provide more details?
Best Regards
Siyuan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Brown
Sent: Thursday, January 21, 2016 10:49 PM
To: "Jim Hung (洪銘駿)" <jim.h...@quantatw.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per
own MAC address
On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
> There is one network issue in customer datacenter, the
> “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source
> network device if multi LANs on the system. And, this cause the PXE boot
> failure at customer datacenter environment.
>
> On our system, it has two network devices, one is Intel NIC, the other is
> Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to
> generate the DULD-LLT. However at customer Data Center, they do NOT accept
> this. Each interface needs to generate their DUID-LL(T) based on their own
> LL. This means that they must use their own MAC address. Both interface will
> have different DUIL-LL(T), which is technically against the RFC here.
>
> Can you please help to check how networkstack driver could be supported on
> this requirement?
We have encountered exactly the same problem in iPXE. We decided to adopt the
solution proposed by RFC6355: we use DUID-UUID rather than any of the
DUID-LL(T) variants. This is the only sensible way in which we can hope to
make the same choice of DUID as the loaded operating system.
Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address
Thanks Michael, Siyuan and Samer.
We have used the Pcd to decide the type for Dhcp server and the setting is
DUID-LLT to meet the requirement from customer datacenter, unfortunately, their
environment only supports DUID-LL(T), the DUID-UUID is not a accepted type in
their usage and they even cannot move the setting to DUID-UUID since the PXE
environment has been used by many products with a lot of systems on-line, not
possible to do the change only for the project that created with multi-network
devices. So this is the problem what we have and must to come out a way to
generate DUID-LL(T) per own MAC address to meet the mechanism of customer DC.
gEfiNetworkPkgTokenSpaceGuid.PcdDhcp6UidType|1|UINT8|0x1001
About this requirement which is violate the RFC, we didn't got the detail
answer from customer but it's a true requirement for us now.
Thanks,
Jim
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Friday, January 22, 2016 11:13 AM
To: mc...@ipxe.org; siyuan...@intel.com
Cc: edk2-devel@lists.01.org; Jim Hung (洪銘駿)
Subject: RE: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per
own MAC address
A while ago, a change was added to EDK2 to introduce a Pcd to select either
DUID-LLT or DUID-UUID. Did you look at modifying that PCD?
Sent from my Android phone using Symantec TouchDown (www.symantec.com)
-Original Message-
From: Fu, Siyuan [siyuan...@intel.com]
Received: Thursday, 21 Jan 2016, 8:59PM
To: Michael Brown [mc...@ipxe.org]
CC: edk2-devel@lists.01.org [edk2-devel@lists.01.org]; Jim Hung (洪銘駿)
{[jim.h...@quantatw.com]
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per
own MAC address
Thanks Michael, maybe use UUID is a good way to solve this issue. But I still
curious why the server has such requirement which is apparent violate the RFC
requirement. Could you provide more details?
Best Regards
Siyuan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Brown
Sent: Thursday, January 21, 2016 10:49 PM
To: "Jim Hung (洪銘駿)" <jim.h...@quantatw.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per
own MAC address
On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
> There is one network issue in customer datacenter, the
> “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source
> network device if multi LANs on the system. And, this cause the PXE boot
> failure at customer datacenter environment.
>
> On our system, it has two network devices, one is Intel NIC, the other is
> Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to
> generate the DULD-LLT. However at customer Data Center, they do NOT accept
> this. Each interface needs to generate their DUID-LL(T) based on their own
> LL. This means that they must use their own MAC address. Both interface will
> have different DUIL-LL(T), which is technically against the RFC here.
>
> Can you please help to check how networkstack driver could be supported on
> this requirement?
We have encountered exactly the same problem in iPXE. We decided to adopt the
solution proposed by RFC6355: we use DUID-UUID rather than any of the
DUID-LL(T) variants. This is the only sensible way in which we can hope to
make the same choice of DUID as the loaded operating system.
Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
