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

[Bernie Volz (volz)]

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: internet-***@ietf.org [mailto:internet-***@ietf.org]
Sent: Monday, March 05, 2018 3:32 PM
To: Tomek Mrugalski <***@gmail.com>; Bernie Volz (volz) <***@cisco.com>
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

[Tomek Mrugalski]

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

[Bernie Volz (volz)]

Hi:

Few notes inline (BV>) below.

- Bernie

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

Hi,

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

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).

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.

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

[何林]

Hi:

Few notes inline (LH>) below.

Post by Tomek Mrugalski
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).
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.
​LH> Make sense.
2. Would such a topic be interesting to the WG?
​LH> Yes,

​I think it's an interesting topic
..

3. Do we want to allow or even mandate Reconfigure here? One of the

Post by Tomek Mrugalski
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.
​LH> I think it's better to allow any number of LLADDR per IA_LL. Firstly,

this provides flexibility and allows clients to request different types of
link-layer addresses just in one Solicit message (Although I don't know
whether such scenarios exist). Secondly, one LLADDR per IA_LL can be just
considered as a special case.

Post by Tomek Mrugalski
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
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg

[何林]

Another question: should we consider solutions for IPv4-only hypervisors
and LoT devices?

Post by Tomek Mrugalski
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).
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.
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
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg

[Bernie Volz (volz)]

IPv4, what’s that?

But, seriously, IPv6 link-local is all that is needed if the DHCPv6 server is on the local link and that really isn’t a high bar? Yes, if you need relays you need them to be able to communicate to the servers over IPv6.

My feeling is that we probably don’t want to consider it. But it may be something to consider later when this work is further along, perhaps using DHCPv6 over v4?

Also, IEEE is looking at protocols to do this (that would probably use direct Ethernet layer packets and not IP) and so maybe those environments could use that?


- Bernie

From: dhcwg <dhcwg-***@ietf.org> On Behalf Of ??
Sent: Monday, April 16, 2018 5:54 AM
To: Tomek Mrugalski <***@gmail.com>
Cc: dhcwg <***@ietf.org>
Subject: Re: [dhcwg] Some questions regarding draft-bvtm-dhc-mac-assign-00

Another question: should we consider solutions for IPv4-only hypervisors and LoT devices?

2018-03-06 6:57 GMT+08:00 Tomek Mrugalski <***@gmail.com<mailto:***@gmail.com>>:
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


_______________________________________________
dhcwg mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg