Subject: Re: Last Call: <draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt> (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Sep 2011 09:19:59 +0300

This draft is being last called for the second time, as it was discovered late that we had missed an IANA requirement. Suresh Krishnan (author of the RFC 5453 registry for interface identifiers) noted that any allocations need to be made in Proposed Standard RFCs, and I had taken the draft through as Informational. Thank you Suresh for noticing this error!

The draft is now being last called as Proposed Standard and will be brought back to IESG processing when the last call completes. In addition, given that we missed this earlier and RFC 5453's call for careful allocations, perhaps some further review is necessary. I hope that the 6MAN working group would also be able to review this.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Sep 2011 09:35:10 +0300

Following up with a personal comment.

The draft allocates an interface ID and an EUI-64 MAC identifier from the IANA block. These are two separate, unrelated allocations.

The main criticism in RFC 5453 for making additional interface ID allocations is that old implementations do not know about them and may collide when making an allocation. I'm wondering if it would be better to allocate an interface ID that is based on the allocated EUI-64 identifier per RFC 2464? Then we would at least use the same format as other interface IDs and a collision would likely mean inappropriate use of the IANA EUI-64 identifiers. Note that privacy and cryptographic addresses set the u/l bit to zero, whereas EUI-64 interface IDs usually have it at one. Sri's draft is silent on what kind of number should be allocated for the interface ID, perhaps some guidance here would be useful.

Not that collisions are likely in 2^64 space anyway, maybe I'm worried about nothing.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Sep 2011 10:29:54 -0700

Hi Jari:

In case of PMIPv6, we need the interface ID allocation for PMIv6
domain-wide usage. We may not be able tie this to a specific EUI-64
identifier derived from a MAC identifier of any individual MAG hosting this
configuration. 

But, if your recommendation is to tie the IPv6 interface identifier to the
reserved link-layer identifier (the other IANA action), that should be fine.
But, the reserved block that Suresh has in his spec is not tied to any
EUI-64 block ? That implies, we need an interface ID allocation from a new
block ? Or, recommend the node to generate the interface ID based on the
reserved Mac address and not allocate from the block Suresh created ?

Hope, I'm not missing the point.

Regards
Sri

On 9/18/11 11:35 PM, "Jari Arkko" <[email-masked]> wrote:

> The draft allocates an interface ID and an EUI-64 MAC identifier from the IANA
> block. These are two separate, unrelated allocations.
> 
> The main criticism in RFC 5453 for making additional interface ID allocations
> is that old implementations do not know about them and may collide when making
> an allocation. I'm wondering if it would be better to allocate an interface ID
> that is based on the allocated EUI-64 identifier per RFC 2464? Then we would
> at least use the same format as other interface IDs and a collision would
> likely mean inappropriate use of the IANA EUI-64 identifiers. Note that
> privacy and cryptographic addresses set the u/l bit to zero, whereas EUI-64
> interface IDs usually have it at one. Sri's draft is silent on what kind of
> number should be allocated for the interface ID, perhaps some guidance here
> would be useful.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 21 Sep 2011 18:09:00 -0400

Hi Jari,

> The main criticism in RFC 5453 for making additional interface ID allocations is that old implementations do not know about them and may collide when making an allocation. I'm wondering if it would…

This sounds like a great idea. I am not sure that IANA has a reserved
EUI-64 block like you suggested, but they certainly have a ethernet
address block (MAC-48). We can instruct the IANA to assign a MAC address
that maps straight into the IID. e.g.

00-00-5E-00-03-00

and the IID

0200:5eff:fe00:0300

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 21 Sep 2011 18:32:29 -0400

Hi Sri,

> reserved Mac address and not allocate from the block Suresh created ?

There are two ways by which you can get a stable reserved IID. One by
reserving an IID block using an IANA registry and the other by getting a
stable MAC48 that can be used to create an IID. The only danger with
getting a stable MAC48 is that if you happen to have 2 MAGs in the same
broadcast domain, it will lead to issues.

Thanks
Suresh

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 21 Sep 2011 17:44:16 -0700

Hi Suresh,

> broadcast domain, it will lead to issues.

Two MAG's in the same broadcast domain can be ruled out, as there is no
mechanism for the nodes to decide on who should support the attached MN.
More over, we still have the P2P link assumption and so multiple MAG's in
the same broadcast domain is not possible. So, we are fine on this aspect.
Stepping back a bit, IMO, 5453 issue is not applicable for the P2P link and
given that its a managed mobility domain. So, I wonder, if the concern is
valid in PMIPv6 context ?

Regards
Sri

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 21 Sep 2011 21:54:05 -0400

See below,

> that maps straight into the IID. e.g.

The IANA Considerations for the allocation of EUI-48 and EUI-64
addresses are spelled out in RFC 5342. There is no reason for any
special action to "direct" IANA.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> 00-00-5E-00-03-00
>
> and the IID
>
> 0200:5eff:fe00:0300
>
> Thanks
> Suresh
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 22 Sep 2011 17:30:52 -0400

Hi Sri,

> valid in PMIPv6 context ?

I don't think that the concern is applicable in the PMIPv6 P2P link
context. That is why I was fine with either of the methods for getting
the IID.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 22 Sep 2011 18:19:08 -0400

Hi Donald,

> special action to "direct" IANA.

Not sure about this. There are two registries in play here. One at

http://www.iana.org/assignments/ethernet-numbers

and another at

http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml

The first one lists the allocations from the IANA ethernet address block
for unicast use and the second one lists the IIDs to avoid. Even though
there is a one to one correlation between a MAC address allocated from
the IANA block and an IPv6 IID, the second registry is where the
reserved IIDs are listed (as it is possible to have IIDs that are not
based on MAC addresses).

Thanks
Suresh

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 22 Sep 2011 19:49:33 -0400

Hi Suresh,

> http://www.iana.org/assignments/ethernet-numbers

The registry web page is very messy. One thing I'm supposed to do is
to produce an edited version as a suggestion to IANA. Only a couple of
small parts of that page relate to IANAN EUI assignments.

> http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml

The two entries currently in that registry are clearly not derived
from IANA allocated EUIs and, in fact, don't look like they are
constructed from any EUI.

> for unicast use

It also lists the more extensive allocations under the IANA OUI for
multicast use.

> and the second one lists the IIDs to avoid. Even though

It's absurd for these registries to be operated so that they can get
out of sync and so that conflicting uses can be allocated for the same
EUI / derived-IID. The IANA Considerations for these registries should
be updated, if necessary, so that can't happen. I believe that the EUI
registry is, in some vague small sense, more fundamental because you
can do a variety of different things with an EUI, not just create an
IID.

Maybe the IID registry should also be updated to show the ranges of
IIDs automatically available to EUI holders...

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Fri, 23 Sep 2011 08:21:26 -0400

> can do a variety of different things with an EUI, not just create an

They are separate registries, serving different purposes. It is not
immediately clear to me what it means for them to "get out of
sync". Can you elaborate a bit more?

Thanks!

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 23 Sep 2011 19:41:16 -0400

Hi Donald,
  Changing subject as this issue is orthogonal to the draft being last
called.

On 11-09-22 07:49 PM, Donald Eastlake wrote:
> ...

  I agree that the IID registry should list the IID ranges automatically
available to holders of reserved EUIs from the IANA range. We can
probably put together a short draft just to do that.

Thanks
Suresh

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 24 Sep 2011 11:27:25 -0400

A separate draft to fix this up sounds reasonable. Presumably this
would be an update to RFC 5453.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 24 Sep 2011 11:28:13 -0400

Hi Thomas,

> sync". Can you elaborate a bit more?

IPv6 Interface Identifiers  (IIDs) are 64 bit quantities. Various RFCs
say you can use a Modified EUI-64 for an IID on the basis that you
control the base EUI-64. And control of some EUI-64s can derive from
control of an EUI-48 (i.e., a MAC address) or IPv4 address. It would
seem unfortunate if someone specified some IID for special use when
someone else could start innocently using it, believing it was theirs,
due to their control of an EUI-64 or EUI-48 or IPv4 address.

Thanks,
Donald

---

From: Thomas Narten <[email-masked]>
Date: Mon, 26 Sep 2011 09:57:12 -0400

> due to their control of an EUI-64 or EUI-48 or IPv4 address.

IPv6 address with modified EUI-64 IIDs have (in some cases) special
properties. Maybe. But not all of them do, depending on the u/g bit
setting.

To date, no one really takes advantage of those properties. The
original purpose for them was always speculative, and in the 15 years
since then, I've only become less convinced that those properties are
useful in practice.

For one thing, because there is no way to force the properties to be
valid, any implementation/use that depended on such properties would
end up being a potential denial of service vector from Bad Guys that
deliberately generate IIDs in violation of the assumption.

Also, it was always assumed that these properties might not actually
be available in practice, depending on what implementations actually
did, etc.

Given that, I don't see the point in worrying a whole lot about EUI-64
IIDs or expending much effort on them. Not unless we have a credible
proposed usage for them.

Thomas