Subject: [dhcwg] New Draft - draft-bvtm-dhc-mac-assign-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 5 Mar 2018 20:36:50 +0000

Hi:

Tomek and I posted a new individual submission draft, draft-bvtm-dhc-mac-assign-00.

We will discuss this at the DHC WG session in London (IETF-101).

For some background, see Pat Thaler's "Emerging IEEE 802 Work on MAC Addressing" slide deck at https://datatracker.ietf.org/meeting/96/materials/slides-96-edu-ieee802work-0/.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2018 3:32 PM
To: Tomek Mrugalski <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: New Version Notification for draft-bvtm-dhc-mac-assign-00.txt

A new version of I-D, draft-bvtm-dhc-mac-assign-00.txt
has been successfully submitted by Bernie Volz and posted to the
IETF repository.

Name:		draft-bvtm-dhc-mac-assign
Revision:	00
Title:		Link-Layer Addresses Assignment Mechanism for DHCPv6
Document date:	2018-03-05
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-bvtm-dhc-mac-assign-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bvtm-dhc-mac-assign/
Htmlized:       https://tools.ietf.org/html/draft-bvtm-dhc-mac-assign-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bvtm-dhc-mac-assign-00

Abstract:
   In certain environments, e.g. large scale virtualization deployments,
   new devices are created in an automated manner.  Such devices
   typically have their link-layer (MAC) addresses randomized.  With
   sufficient scale, the likelihood of collision is not acceptable.
   Therefore an allocation mechanism is required.  This draft proposes
   an extension to DHCPv6 that allows a scalable approach to link-layer
   address assignments.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 5 Mar 2018 23:57:35 +0100

Hi,

Thanks to Bernie for pushing forward, editing and uploading the draft.

This is an initial proposal for a new mechanism in DHCPv6. It looks a
bit odd at first (why would a device request MAC address if it's able to
transmit DHCPv6 packets already), but there are at least two scenarios
where this is justified.

I'd like to encourage people to read the draft. It short - 4 pages of
the actual proposal text (or 7 if you count option format sections).

There are couple questions we'd like to hear your comments on:

1. Does it make sense to reuse DHCPv6 mechanisms to solve this problem?
Several current and former IESG members think so, but we'd like to hear
your opinion on this.

2. Would such a topic be interesting to the WG?

3. Do we want to allow or even mandate Reconfigure here? One of the
objections raised to DHCPv6 protocol in general was that it's not always
possible to change the configuration at moment's notice.

4. We haven't really figured out whether it would be better to have
always one LLADDR per IA_LL or one or more? Arguments can be made both
ways. We're eager to hear what's the preference here.

On a related note, we organized the repo for this work here:
https://github.com/dhcwg/dhcp-mac. Feel free to comment on existing
issues or open new ones. Keep the discussion on dhcwg list, though.

Thanks,

Bernie & Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 Mar 2018 16:14:15 +0000

Hi:

Few notes inline (BV>) below.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, March 05, 2018 5:58 PM
To: [email-masked]
Subject: [dhcwg] Some questions regarding draft-bvtm-dhc-mac-assign-00

Hi,

BV> Well, Tomek did most of the work on writing the draft.

This is an initial proposal for a new mechanism in DHCPv6. It looks a bit odd at first (why would a device request MAC address if it's able to transmit DHCPv6 packets already), but there are at least two scenarios where this is justified.

I'd like to encourage people to read the draft. It short - 4 pages of the actual proposal text (or 7 if you count option format sections).

1. Does it make sense to reuse DHCPv6 mechanisms to solve this problem?
Several current and former IESG members think so, but we'd like to hear your opinion on this.

3. Do we want to allow or even mandate Reconfigure here? One of the objections raised to DHCPv6 protocol in general was that it's not always possible to change the configuration at moment's notice.

BV> I would suspect we would, but this also raises the issue, especially for hypervisor or another entity that gets a block of mac addresses and assigns to "devices", exactly what actions are needed when the assigned addresses "expire" - for example, does the hypervisor "kill" (terminate) the device? (Would there potentially also be some "connection" between the mac-addresses and DHCPv6 assigned addresses or delegated prefixes to these devices).

4. We haven't really figured out whether it would be better to have always one LLADDR per IA_LL or one or more? Arguments can be made both ways. We're eager to hear what's the preference here.

BV> My feeling is we should be flexible and allow any number. Not sure what advantage there is to limit this? There is also a question as to whether the link-layer-type/link-layer-len should be moved into the IA_LL as then there could be 0 or more LLADDR (for example, a device wanting just one address would not need to include a OPTION_LLADDR)? But I don't think there is necessarily any good argument over current (LLADDR) vs IA_LL approach.

On a related note, we organized the repo for this work here:
https://github.com/dhcwg/dhcp-mac. Feel free to comment on existing issues or open new ones. Keep the discussion on dhcwg list, though.

BV> I also started a few issues at https://github.com/dhcwg/dhcp-mac/issues.

Thanks,

Bernie & Tomek

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg