Subject: [OPSAWG] IEEE RAC policy on virtualization

From: Glenn Parsons <[email-masked]>
Date: Mon, 19 Sep 2011 02:02:42 -0400

Folks,

I am sending this message to make you aware of a policy concern that the IEEE Registration Authority Committee is currently studying.  The IEEE RAC is responsible for oversight of the assignment of OUIs that are used to create MAC addresses -- http://standards.ieee.org/about/bog/rac.html

A "prime directive" of the RAC is to not run out of global MAC48 addresses for 100 years.  In the first ~30 years of assignment, less than 1% of the possible global MAC addresses have been assigned.  Still, the concern of running out is driving our study of machine virtualization (aka cloud computing) as it has the potential to increase MAC48 address usage dramatically.

The RAC Policy on machine virtualization is currently that only one (or at most a few) global MAC48 addresses can be assigned to a single hardware device.  This is apparently being violated by existing VM vendors.

As a result, the RAC is seeking input as to if this is a problem and how could it be solved.  We have been asking these questions to ourselves and to vendors in the VM space to understand the requirements:
  1. Should a MAC48 be the network identifier for VM, equivalent to a MAC48 on a physical machine?
  2. If so, should the MAC48 be from the local or global address space?
  3. Should the address be globally unique forever or reusable?
  4. Should the RAC enforce this?

Some have suggested that we need to look at the solutions for the VM requirements (before they have been determined), these include:
  - Just allow assignment of MAC48 to VMs
  - Assign OUI address blocks for VM applications (for either or both of the local and global address space)
  - Lease, instead of sell, an OUI/IAB address block
  - Create a DHCP-like mechanism to allow dynamic assignment of MAC48 addresses
  - Create a new "MAC128" identifier for VMs

I would appreciate input from the IETF OPS Area and the community in general, that I will then take back to the RAC.

Cheers,
Glenn Parsons
Chair, IEEE RAC

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2011 09:12:36 +1200

Hi Glenn,

On 2011-09-19 18:02, Glenn Parsons wrote:
> Folks,
> 
> I am sending this message to make you aware of a policy 
> concern that the IEEE Registration Authority Committee is 
> currently studying.  The IEEE RAC is responsible for 
> oversight of the assignment of OUIs that are used to create 
> MAC addresses -- http://standards.ieee.org/about/bog/rac.html
> 
> 
> 
> A "prime directive" of the RAC is to not run out of global 
> MAC48 addresses for 100 years.  In the first ~30 years of 
> assignment, less than 1% of the possible global MAC addresses
>  have been assigned.  Still, the concern of running out is 
> driving our study of machine virtualization (aka cloud 
> computing) as it has the potential to increase MAC48 address 
> usage dramatically.
> 
> The RAC Policy on machine virtualization is currently that 
> only one (or at most a few) global MAC48 addresses can be 
> assigned to a single hardware device.  This is apparently 
> being violated by existing VM vendors.
> 
> As a result, the RAC is seeking input as to if this is a 
> problem and how could it be solved.  We have been asking 
> these questions to ourselves and to vendors in the VM space 
> to understand the requirements:

> 1. Should a MAC48 be the network identifier for VM,
> equivalent to a MAC48 on a physical machine?

Well, no. It clearly should be a network address, not a link
layer address. I hope it isn't necessary here to explain why.
IPv6 allows an essentially infinite number of addresses per
subnet; that will do nicely.

> 2. If so, should the MAC48 be from the local or global

Who cares? It has no importance outside the local scope.

> 3. Should the address be globally unique forever or reusable?

Reusable is fine (see previous point).

>  4. Should the RAC enforce this?

You can't, so don't waste time trying.

> 
> Some have suggested that we need to look at the solutions for
>  the VM requirements (before they have been determined),
> these include:

> - Just allow assignment of MAC48 to VMs - Assign OUI address
> blocks for VM applications (for either or both of the local
> and global address space)

Doesn't matter (see 2 above).

> - Lease, instead of sell, an OUI/IAB address block

No point (see 2 above).

> - Create a DHCP-like mechanism to allow dynamic assignment of

No, please no.

> - Create a new "MAC128" identifier for VMs

Wait a minute - why not use EUI-64, which was designed for
exactly this problem (and is why IPv6 uses modified EUI-64
format)? Designing a new version would be crazy.

    Brian Carpenter, speaking only for myself.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 19 Sep 2011 14:53:49 -0700

It seems to me that it would be rational to allocate an OUI
range for virtual machines.

Since the OUI does not need to be globally unique, I would
suspect that, say, 16 OUIs allocated to VMs would be more
than sufficient to meet the EUI-48 addressing needs for said
VMs on any likely box. That's 16*16.7M VMs per subnet
worth of OUIs.

The OUIs would not need to be VM vendor unique and this
would provide a way for the APIs to easily allow administrator
and/or automated control of the OUI/EUI assignments
for the VMs in their environment(s).

Owen

On Sep 19, 2011, at 2:12 PM, Brian E Carpenter wrote:

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

---

From: Glenn Parsons <[email-masked]>
Date: Tue, 20 Sep 2011 02:20:38 -0400

Brian,

Some are proposing EUI-64 is not large enough and that a MAC-128 (or EUI-128) be created as a new network address specifically for VMs, replacing MAC-48

Cheers,
Glenn.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: September-19-11 5:13 PM
To: Glenn Parsons
Cc: [email-masked]
Subject: Re: [OPSAWG] IEEE RAC policy on virtualization

Hi Glenn,

On 2011-09-19 18:02, Glenn Parsons wrote:
> Folks,
> 
> I am sending this message to make you aware of a policy concern that 
> the IEEE Registration Authority Committee is currently studying.  The 
> IEEE RAC is responsible for oversight of the assignment of OUIs that 
> are used to create MAC addresses -- 
> http://standards.ieee.org/about/bog/rac.html
> 
> 
> 
> MAC48 addresses for 100 years.  In the first ~30 years of assignment, 
> less than 1% of the possible global MAC addresses  have been assigned.  
> Still, the concern of running out is driving our study of machine 
> virtualization (aka cloud
> computing) as it has the potential to increase MAC48 address usage 
> dramatically.
> 
> The RAC Policy on machine virtualization is currently that only one 
> (or at most a few) global MAC48 addresses can be assigned to a single 
> hardware device.  This is apparently being violated by existing VM 
> vendors.
> 
> As a result, the RAC is seeking input as to if this is a problem and 
> how could it be solved.  We have been asking these questions to 
> ourselves and to vendors in the VM space to understand the 
> requirements:

> MAC48 on a physical machine?

Well, no. It clearly should be a network address, not a link layer address. I hope it isn't necessary here to explain why.
IPv6 allows an essentially infinite number of addresses per subnet; that will do nicely.

> 
> Some have suggested that we need to look at the solutions for  the VM 
> requirements (before they have been determined), these include:

> - Just allow assignment of MAC48 to VMs - Assign OUI address blocks 
> for VM applications (for either or both of the local and global 
> address space)

No point (see 2 above).

No, please no.

> - Create a new "MAC128" identifier for VMs

Wait a minute - why not use EUI-64, which was designed for exactly this problem (and is why IPv6 uses modified EUI-64 format)? Designing a new version would be crazy.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2011 09:04:03 +1200

Glenn,

I'd like to see an argument why EUI-64 is too small in any realistic universe.

Regards
   Brian

---

From: William Herrin <[email-masked]>
Date: Tue, 20 Sep 2011 17:37:04 -0400

On Mon, Sep 19, 2011 at 2:02 AM, Glenn Parsons
<[email-masked]> wrote:
> As a result, the RAC is seeking input as to if this is a problem and how
> could it be solved.  We have been asking these questions to ourselves and to
> vendors in the VM space to understand the requirements:

Hi Glenn,

It's a virtual machine. Depending on the scenario, it may have all the
characteristics of a "real" machine. This is often the deliberate
intent of the system administrator: if he just wanted multiple apps,
he'd run multiple apps on top of a single OS instead of running VMs.

So generally speaking, yes the NICs in the VMs should have their own
MAC addresses.

Not entirely sure what you mean by the "network identifier for the
VM." A unicast MAC generally identifies a NIC, not a whole machine.
Yes there are exceptions (Sun) but those are increasingly rare. VMs
are just like real machines. Some have one NIC. Some have more.

>   2. If so, should the MAC48 be from the local or global address space?

Local by default unless there's some non-stupid way to assign
non-overlapping global MACs whenever someone downloads an open source
copy of virtualbox. User override to any MAC address.

>   3. Should the address be globally unique forever or reusable?

Resuable. VM host systems aren't bare hardware. They can (and probably
should) be smart enough to look for address conflicts before booting a
guest VM and be able to reconfigure the MAC if there is a local
conflict.

A DHCP-like protocol for this is going to be overkill in most cases.
An echo-request will be good enough in most.

Also, considering that the querent is a already-booted OS considering
how to initiate a VM and considering that it's desirable to hold the
same MAC over time, it may be better to use some sort of general
database application instead of highly specialized network stack code.

>   4. Should the RAC enforce this?

How?

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "t.petch" <[email-masked]>
Date: Fri, 23 Sep 2011 14:36:30 +0200

----- Original Message -----
From: "Glenn Parsons" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 19, 2011 8:02 AM

Folks,

I am sending this message to make you aware of a policy concern that the IEEE
Registration Authority Committee is currently studying.  The IEEE RAC is
responsible for oversight of the assignment of OUIs that are used to create MAC
addresses -- http://standards.ieee.org/about/bog/rac.html

A "prime directive" of the RAC is to not run out of global MAC48 addresses for
100 years.  In the first ~30 years of assignment, less than 1% of the possible
global MAC addresses have been assigned.  Still, the concern of running out is
driving our study of machine virtualization (aka cloud computing) as it has the
potential to increase MAC48 address usage dramatically.

The RAC Policy on machine virtualization is currently that only one (or at most
a few) global MAC48 addresses can be assigned to a single hardware device.  This
is apparently being violated by existing VM vendors.

As a result, the RAC is seeking input as to if this is a problem and how could
it be solved.  We have been asking these questions to ourselves and to vendors
in the VM space to understand the requirements:
  1. Should a MAC48 be the network identifier for VM, equivalent to a MAC48 on a
physical machine?

<tp>
Not sure I understand the terminology. MAC48 identifies an interface to a
machine and those that use it to identify a (virtual or real) machine usually
come unstuck eventually.
I would expect each VM to require one or more interface identifiers, one for
each interface.  In scenarios like this, interfaces become horribly complex, as
exemplified by SDH and reflected in the Interface MIB Module, and more recently
in discussions on netmod.

  2. If so, should the MAC48 be from the local or global address space?
<tp>
Global.  Local requires management to ensure uniqueness which just does not
happen in a world where the manufacturers (almost) ensure that a MAC48 is
unique.

  3. Should the address be globally unique forever or reusable?
<tp>
Reusable - VMs come and go.

  4. Should the RAC enforce this?
<tp>
To the extent that it can, yes.

Some have suggested that we need to look at the solutions for the VM
requirements (before they have been determined), these include:
  - Just allow assignment of MAC48 to VMs
  - Assign OUI address blocks for VM applications (for either or both of the
local and global address space)
  - Lease, instead of sell, an OUI/IAB address block
  - Create a DHCP-like mechanism to allow dynamic assignment of MAC48 addresses
<tp>
Yes, essential, but keep it very simple.  IPv6 is a case study in how to design
an ease of configuration that ends up much more complicated.

  - Create a new "MAC128" identifier for VMs
<tp>
I always said that the IPv6 address was not big enough and this would prove my
point:-) I wonder what is wrong with EUI64, which would appear to allow 2**16
VMs.

Tom Petch
</tp>
I would appreciate input from the IETF OPS Area and the community in general,
that I will then take back to the RAC.

Cheers,
Glenn Parsons
Chair, IEEE RAC

---

From: sujay gupta <[email-masked]>
Date: Sat, 24 Sep 2011 16:11:14 +0530

Hi,

I would propose a;

>OUI for VM applications.
>Keep Local & Global scope
  - usage possibility: syndication across DC's & transparent VM's transfers.

>Make it re-usable

>Keep it 48bit with RAC enforcement, or move to 64bit.

>And No, to DHCP type of MAC allocation.

Regards,
-Sujay

On Mon, Sep 19, 2011 at 11:32 AM, Glenn Parsons
<[email-masked]> wrote:
> Folks,
>
> I am sending this message to make you aware of a policy concern that the
> IEEE Registration Authority Committee is currently studying.  The IEEE RAC
> is responsible for oversight of the assignment of OUIs that are used to
> create MAC addresses -- http://standards.ieee.org/about/bog/rac.html
>
> A "prime directive" of the RAC is to not run out of global MAC48 addresses
> for 100 years.  In the first ~30 years of assignment, less than 1% of the
> possible global MAC addresses have been assigned.  Still, the concern of
> running out is driving our study of machine virtualization (aka cloud
> The RAC Policy on machine virtualization is currently that only one (or at
> most a few) global MAC48 addresses can be assigned to a single hardware
> device.  This is apparently being violated by existing VM vendors.
>
>   – Just allow assignment of MAC48 to VMs
>   – Assign OUI address blocks for VM applications (for either or both of the
>   – Lease, instead of sell, an OUI/IAB address block
>   – Create a DHCP-like mechanism to allow dynamic assignment of MAC48
> addresses
>   – Create a new “MAC128” identifier for VMs
>
> I would appreciate input from the IETF OPS Area and the community in
> general, that I will then take back to the RAC.
>
> Cheers,
> Glenn Parsons
> Chair, IEEE RAC
>