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: 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