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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Mar 2019 13:56:15 +0000

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 (see https://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.

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Mar 2019 14:13:34 +0000

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) <[email-masked]<mailto:[email-masked]>> 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.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Mar 2019 14:09:24 -0400

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 <[email-masked]> wrote:
> 
> Hi,
> 
>> On 27 Mar 2019, at 13:56, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi:
>>  
>> 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 <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 <https://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 <https://github.com/dhcwg/dhcp-mac/blob/master/ietf-dhc-mac-assign.pdf>, as the IEEE is exploring allocation protocols.
>>  
>> 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.
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>
> [email-masked]

---

From: Timothy Winters <[email-masked]>
Date: Wed, 27 Mar 2019 15:17:03 -0400

I also support adoption.

~Tim

On Wed, Mar 27, 2019 at 2:09 PM Russ Housley <[email-masked]> 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
>
>
> I support adoption. I understand the IEEE is supportive, and that there is
> no other alternative being proposed in that community.
>
> On 27 Mar 2019, at 13:56, Bernie Volz (volz) <[email-masked]> 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 (see
> https://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.

---

From: Lin He <[email-masked]>
Date: Thu, 28 Mar 2019 09:58:34 +0100

This work is very important and useful.

I support adoption.

Timothy Winters <[email-masked]> 于2019年3月27日周三 下午8:17写道：

>> On Mar 27, 2019, at 10:13 AM, Tim Chown <[email-masked]
>> <[email-masked]>> wrote:
>>
>> Hi,
>>
>> I support adoption. I understand the IEEE is supportive, and that there
>> is no other alternative being proposed in that community.
>>
>> 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
>> https://github.com/dhcwg/dhcp-mac/blob/master/ietf-dhc-mac-assign.pdf,
>> as the IEEE is exploring allocation protocols.
>>

-- 

    Yours Sincerely,

*   Lin He*

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Mar 2019 09:31:52 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

I support adoption.

Russ

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

Hi,

Tim

Hi:

Thanks much!

  *   Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Mar 2019 10:19:56 +0000

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

Hi,

Tim

I support adoption.

Russ

Hi,

Tim

Hi:

Thanks much!

  *   Tomek & Bernie