Re: [dhcwg] Call for Adoption - draft-bvtm-dhc-mac-assign - Respond by April 16, 2019

["Bernie Volz (volz)" <[e-mail]>]

The host booting one is an interesting one. The main issue here is that DHCPv6 requires (link-local) communication and that requires a mac-address. So, we kind of have the chicken and egg problem.

The most obvious way forward is that the device uses a temporary short term randomly assigned address (from perhaps some limited mac address space) to do the DHCPv6 communication to obtain a longer term mac-address assignment. The device could ask for the a link-layer address assignment and an IA_NA (or IA_PD) at the same time and thus need only one configuration round trip. Obviously the client identifier (DUID) used should not be a link-layer derived one (but a DUID-UUID or DUID-EN). The temporary short term address may result in conflicts, but not sure that is really that fatal as retries will hopefully clear that up (except perhaps if you had very many devices all trying to boot at once, such as after a power recovery).

Another option might be to provide some means of multicast link-local communication (this is similar to DHCPv4 where broadcasts are used), but this would require sending multicast without a link-local address and I haven’t explored whether that has all sorts of issues as most networking stacks probably can’t easily support that (and we tried to avoid need for special communications with DHCPv6 as that raised the complexity for DHCPv4 implementations).


  *   Bernie

From: dhcwg <[e-mail]> On Behalf Of Tim Chown
Sent: Thursday, March 28, 2019 5:32 AM
To: Russ Housley <[e-mail]>
Cc: [e-mail]; Bernie Volz (volz) <[e-mail]>; [e-mail]
Subject: Re: [dhcwg] Call for Adoption - draft-bvtm-dhc-mac-assign - Respond by April 16, 2019

Hi,

I asked a question related to this at the mic at the meeting, but it's not clear (at least yet) whether the mechanism is designed for host bootstrapping, or for a connected host to request a pool of MAC addresses (which I understand to be a starting address and number of sequential addresses that can be used beyond that) for its own use, e.g., internal VMs.  I had the feeling from the discussion that it was the latter case, but I would support exploring the first case too after adoption.

Perhaps the chairs have some further comment on that.

Tim


On 27 Mar 2019, at 18:09, Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:

I understand that the IEEE 802 might work on a protocol to dynamically assign a MAC address, but I think it is important to get both an IP address and a MAC address in one round trip.  That needs to be done in the IETF.

I support adoption.

Russ



On Mar 27, 2019, at 10:13 AM, Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I support adoption. I understand the IEEE is supportive, and that there is no other alternative being proposed in that community.

I agree we should keep the "quadrant" draft separate.

Tim




On 27 Mar 2019, at 13:56, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:

Hi:

As discussed at the DHC WG session at IETF-104, we are trying another call … this starts the WG Call for Adoption for the draft-bvtm-dhc-mac-assign-02 document. Please respond by end of day April 16, 2019 whether you support adoption of this work or not.

This was presented at IETF-104 (see https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-link-layer-addresses-assignment-mechanism-for-dhcpv6-refresher-01) and also IETF-101 (seehttps://datatracker.ietf.org/meeting/101/materials/slides-101-dhc-mac-addresses-assignment-for-dhcpv6-01) and discussed with our Area Director (Suresh) as acceptable work for the DHC WG to adopt. This work was also presented by Tomek and Bernie to the IEEE P802.1CQ discussions at the OmniRAN meeting in May 2018 – slides available at https://github.com/dhcwg/dhcp-mac/blob/master/ietf-dhc-mac-assign.pdf, as the IEEE is exploring allocation protocols.

If you are silent, it is not possible for us to know your support or lack therefore; so please do respond if you feel this work is something the DHC WG should (or should not) work on.

Thanks much!


  *   Tomek & Bernie

PS: We will also start a call on the extension work draft-bernardos-dhc-slap-quadrant<https://www.ietf.org/archive/id/draft-bernardos-dhc-slap-quadrant-01.txt> shortly.
_______________________________________________
dhcwg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dhcwg

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