Subject: [ieee-ietf-coord] FW: [802.1 - 10757] FW: Proposed PAR: P802c - Overview and Architecture - Amendment: Local Media Access Control (MAC) Address Usage

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Feb 2015 11:36:38 +0000

> -----Original Message-----
> From: IEEE 802.1 List Help ONLY [mailto:[email-masked]] On
> Behalf Of Glenn Parsons
> Sent: Wednesday, February 04, 2015 8:54 PM
> To: [email-masked]
> Subject: [802.1 - 10757] FW: Proposed PAR: P802c - Overview and
> Architecture - Amendment: Local Media Access Control (MAC) Address
> Usage
> 
> 802.1 list help: www.ieee802.org/1/email-pages/zmqw1113.html
> List archives (access-controlled) by date:
>                www.ieee802.org/1/private/email2/mail1.html
> -----
> 
> FYI this PAR has been pre-circulated to the EC.
> 
> We will review any comments in November during the Local Address Study
> Group meeting and entertain a motion for approval.
> 
> Cheers,
> Glenn.
> 
> 
> From: Glenn Parsons
> Sent: Wednesday, February 04, 2015 1:53 PM
> To: [email-masked]
> Subject: Proposed PAR: P802c - Overview and Architecture - Amendment:
> Local Media Access Control (MAC) Address Usage
> 
> 
> Folks,
> 
> 
> 
> The November 802.1 plenary authorized the Local Address Study Group at
> the 802.1 interim to potentially draft PAR & CSD for the local address space.
> The Study Group had a productive meeting per the minutes
> (https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ieee802.org_1_files_public_docs2015_admin-2Dminutes-2Dlasg-
> 2D0115-
> 2Dv01.docx&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJ
> fQzvlsiLQfucBXRucPvdrphpBsFA&m=buDa5mHyGphA276qKbYoeFVtobt0ylyc
> c_2c8MS2Kb0&s=bNIHyUmeMNjfMrWe58_Mt8cxTqC86cKEvC4_lBl5i2g&e= )
> with the following conclusion:
> 
> The 802.1 Local Address Study Group (LASG) met for five hours over the
> course of three days during the January 2015 IEEE 802 Interim session in
> Atlanta.  During these meetings the LASG developed a PAR and CSG for
> recommendations on local address usage.  While this PAR is similar to that
> circulated to Working Group chairs during the November 2014 Plenary, it
> represents a considerable reworking of the text of the PAR and CSD with
> wider participation from members of other 802 Working Groups.  The
> comments received on the previous PAR were considered during the
> development of this PAR, however the LASG did not generate comment-by-
> comment responses.  The LASG requests that the Working Groups consider
> this as a new PAR and CSD.
> 
> 
> 
> As a result, I am pre-circulating the new proposed PAR for P802c as posted
> here:
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ieee802.org_1_files_public_docs2015_new-2Daddresses-
> 2Dthaler-2Dlocal-2Daddress-2Dusage-2Dpar-2D0115-
> 2Dv1.pdf&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ
> zvlsiLQfucBXRucPvdrphpBsFA&m=buDa5mHyGphA276qKbYoeFVtobt0ylycc_
> 2c8MS2Kb0&s=9TRVarJilEo93jj9cpvkDH16X63gWE4nZE8wHpgd0oU&e=
> 
> 
> 
> The  new 'CSD' is here:
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__ieee802.org_1_files_public_docs2015_lasg-2Dmjt-2D802c-2DCSD-
> 2D0115-
> 2Dv02.pdf&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJf
> QzvlsiLQfucBXRucPvdrphpBsFA&m=buDa5mHyGphA276qKbYoeFVtobt0ylycc
> _2c8MS2Kb0&s=-YpoYnO7eNvDXsRGsKMcDtAhRYRc3vhv5R24b26xCXw&e=
> 
> 
> 
> These are for pre-circulation to meet the 30-day requirement for March
> plenary EC approval to forward to NesCom.
> 
> 
> 
> Cheers,
> 
> Glenn.
> 
> 
> --
> Glenn Parsons - Chair, IEEE 802.1
> [email-masked]<mailto:[email-masked]>
> +1-613-963-8141
> 
> 
> ===
> Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-
> [email-masked]
> IEEE. Fostering technological innovation and excellence for the benefit of
> humanity.

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Feb 2015 00:53:06 -0500

Dan:

At the meeting in Newark, we talked about the need for a DHCP-like protocol to assign addresses.  Thinking about this since the Newark meeting, I am worried that one protocol to get a MAC address and DHCP to get an IP address will become a big problem.  Two round trips just to get the addresses is too much.  I think there is a way to use DHCP to get both addresses in one round trip.

Another concern that was raise in Newark was the great reduction in the address pool that can be used for the privacy work.

Some of the security protocols use a certificate that binds the MAC address to a public key.  How will a dynamically assigned address be handled?  This aspect does not seem to be covered by the proposed work.

Russ

On Feb 5, 2015, at 6:36 AM, Romascanu, Dan (Dan) wrote:

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

---

From: Pat Thaler <[email-masked]>
Date: Fri, 6 Feb 2015 17:53:42 +0000

Russ,

This project does not include an address acquisition protocol. It only describes an optional structure of the local address space to support such protocols having different default address blocks to assign from and coexist in the same address domain.

The assumption is that there will not be one protocol that fits all needs. For example, hypervisor vendors often want to control the assignment of addresses to their VMs and have that as part of the orchestration system. Fibre Channel over Ethernet already specifies two protocols for getting a MAC address for a virtual  FCoE port. A DHCP based protocol may make sense for devices using DHCP - assuming that they have some way to talk to DHCP without a MAC address assigned yet (or for instances like the VM case where there is a physical MAC address that can be used for the address request from a virtual device).

There is an early draft of a PAR for a protocol development project at: 
http://www.ieee802.org/1/files/public/docs2015/lasg-mjt-protocol-par-csd-0115-v01.pdf
We discussed this PAR at our January interim but aren't ready to go forward with it yet. I expect more discussion in March to continue to define the scope of this PAR including presentations on candidates for such a protocol. 

Since the 802c PAR allows for address assignment protocols to coexist, it would also be possible for IETF to develop one as a DHCP extension without conflicting with an 802 protocol. 

Within IEEE 802 we continue to discuss the question of the address pool for privacy work. It is probable that there use cases where random address selection for privacy is the only protocol in use and the whole 46 bit individual local address space is used.

The issue of dynamic MAC addresses and security protocols will have to be addressed regardless of this project. VMs already get non-globally-unique addresses from hypervisors. As you mentioned, the privacy work is discussing random address assignment. Do the security protocols have an alternative to MAC address as the binder? For example, what if some devices have an EUI-64 assignment as their only global identifier and use a dynamic value for the MAC address? This is a topic we should continue to coordinate on. 

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, February 05, 2015 9:53 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [ieee-ietf-coord] FW: [802.1 - 10757] FW: Proposed PAR: P802c - Overview and Architecture - Amendment: Local Media Access Control (MAC) Address Usage

Dan:

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Feb 2015 21:42:50 -0500

> This project does not include an address acquisition protocol. It only describes an optional structure of the local address space to support such protocols having different default address blocks t…

I think that we need to make sure that we are considering the whole system. I understand breaking up, but we need to make sure that it all hangs together. That was the high-level point of my message.

> The assumption is that there will not be one protocol that fits all needs. For example, hypervisor vendors often want to control the assignment of addresses to their VMs and have that as part of th…

Your presentation in Newark assumed the use of a well-known MAC address for the address assignment protocol.  Has this changed?

> Since the 802c PAR allows for address assignment protocols to coexist, it would also be possible for IETF to develop one as a DHCP extension without conflicting with an 802 protocol. 

Your FCoE shows that there is room for more than one solution, but I think that it would be unwise to create too many solutions.  Interoperability is based on few robust solutions.

> Within IEEE 802 we continue to discuss the question of the address pool for privacy work. It is probable that there use cases where random address selection for privacy is the only protocol in use…

I'm glad this remains under discussion.

> The issue of dynamic MAC addresses and security protocols will have to be addressed regardless of this project. VMs already get non-globally-unique addresses from hypervisors. As you mentioned, the…

As Jari said in Newark, the MAC address has an important role in privacy.  He gave the example that a change in IP address can be tracked by using the same MAC address, and vice versa.

Best,
  Russ