Subject: Re: Mail from softwire working group about 4rd

From: RJ Atkinson <[email-masked]>
Date: Wed, 12 Dec 2012 11:06:30 -0500

All,

I fully agree with Brian Carpenter's note of Tuesday,
December 11th at 10:55:05 +0000.  I support his
perspective as expressed in that note.

I have read, but am NOT persuaded by, the responses 
from Remi Despres to Brian's notes.

Further, I note that the combination ( U==1 a&& G==1)
already has a well defined meaning -- namely a 
global-scope multicast identifier.  These are not 
widely deployed today, but there are various folks looking
into using precisely those identifiers for global-scope
multicasting -- in a way compatible with IEEE 802 
definitions of the EUI-64 with (U==1 && G==1).

Also, I'll note that the IID portion of an IPv6 address
is carefully designed to be algorithmically translatable,
from an IEEE 802 standard EUI-64 identifier.  That algorithm
is trivial, and is universally deployed today, in a 
wide range of devices.  The definitions of U and G bits
do NOT derive ab initio from IETF documents, but instead
are fundamental parts of the IEEE 802 EUI-64 architecture.
The IETF architectural choice to use a (trivially-modified)
EUI-64 in the IETF's IPv6 addressing formats was foundational, 
correct, and ought not be changed at this point.

Last, according to the IANA web site (URL below),
the IETF *already* has several different ways of
mapping IPv4 addresses into IPv6 addresses.  The
4rd folks need to show that none of these could be
used for their purposes, and also need to show
that none of the mapping techniques already used
could work.  Neither of these have been shown so far.
If the 4rd advocates can't make an existing mapping
(between IPv4 and IPv6) work, they ought to define
a new mapping that does NOT modify the semantics of
either the U or G bits.

Yours,

Ran Atkinson

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Dec 2012 18:14:31 +0100

> from Remi Despres to Brian's notes.

Brian suggested an alternative based on a reserved OUI, but I explained why it wouldn't be sufficient. 
Explaining technical objections you may have, beyond what follows, would be appreciated.

> definitions of the EUI-64 with (U==1 && G==1).

Is there any particular IETF reference that you could suggest to read?
In any case, IIDs for multicast addresses are out of scope for the IPv6 addressing architecture of RFC 4291.

> correct, and ought not be changed at this point.

Same view.

An important point to be noted is that, in the translation direction from EUI-64 of IEEE to modified EUI-64 of IETF, the proposed format implies no change at all.

Also, multicast addresses being recognizable by their binary prefix 1110, they can use IIDs of their own, based on IEEE formats or not, without conflict with RFC 4291 in which the only specified IIDs are those of unicast addresses.
In other words, reserving a /8 IID prefix for 4rd (and possibly some others for new types of unicast addresses) won't prevent from using IEEE-based IIDs with u=g=1 for multicast.

> a new mapping that does NOT modify the semantics of

Reasons why a new format is used for 4rd have been extensively discussed in Softwire.
If you are really interested , we can continue, but offline. 

Where 6man has to be involved is to conclude whether the new IID format is an acceptable new usage of the openness of RFC 4291 to new unicast-address technologies, and if not to explain why. 

Regards,
RD

> 
> Yours,
> 
> Ran Atkinson
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 12 Dec 2012 12:38:11 -0500

> In any case, IIDs for multicast addresses are out of scope for the IPv6 addressing architecture of RFC 4291.

Disagree.  It is clear that RFC-4291 has reserved 
the use of G==U==1 for multicast identifiers.

> An important point to be noted is that, in the translation direction
> from EUI-64 of IEEE to modified EUI-64 of IETF, the proposed format
> implies no change at all.

It *breaks* the reverse mapping, however, whereas today
the *bi-directional* mapping works reliably.

> In other words, reserving a /8 IID prefix for 4rd (and possibly
> some others for new types of unicast addresses) won't prevent
> from using IEEE-based IIDs with u=g=1 for multicast.

Incorrect.  

As a trivial example, one can use a unicast routing prefix 
to specify an RP location, along with a multicast group-id
(so that the RP knows to multicast RPF the packet).  This
has the potential to reduce the state required in inter-domain 
routers, to give an example of why this approach can be useful.

> Reasons why a new format is used for 4rd have been extensively
> discussed in Softwire.  If you are really interested,
> we can continue, but offline. 

Those reasons are directly relevant to the 6MAN WG decision
about this proposal, so those reasons need to be articulated
here, on-list.  Softwire and 6MAN are different WGs.  IETF
rules do not assume every member of one WG also belongs to a
different WG.

> Where 6man has to be involved is to conclude whether the new
> IID format is an acceptable new usage of the openness of
> RFC 4291 to new unicast-address technologies,
> and if not to explain why. 

The language you keep quoting was inserted to leave the
door open for GSE/8+8.  Please don't twist the words to
try to justify something that the text really does not
support.

Further, under IETF rules, the burden of proof/justification 
is entirely on the folks advocating change to the IPv6 specs, 
NOT on the 6MAN WG.

Yours,

Ran

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Dec 2012 16:46:52 +0100

> the use of G==U==1 for multicast identifiers.

Different understanding.

> the *bi-directional* mapping works reliably.

Reverse mapping, whose use I still don't see, cannot work the privacy option of RFC 4941: with it, individual IIDs can have g=1 while remaining those of unicast addresses.

> routers, to give an example of why this approach can be useful.

I suppose you implicitly refer to the ILNS of RFC 6740.
As said in the RFC itself, I-LVs of ILNS and IPv6 addresses are "*not* equivalent". 
In particular, I-LVs contain "Node" IDs where IPv6 addresses contain "Interface" IDs.

In any case, it remains unclear why, in I-LVs starting with the /64 of unicast addresses, it would be useful to permit the group bit to be set in their node IDs.
Explanation welcome.  
 
> ...

Regards,
RD

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Dec 2012 15:05:45 -0500

On 13  Dec 2012, at 10:46 , Rémi Després wrote:
> Reverse mapping, whose use I still don't see,
> cannot work the privacy option of RFC 4941

It still works fine, because the scope bit 
is set to local scope for the RFC-4941 uses
(RFC-4941, Section 3.2.1, Step 3).

Under IEEE 802 rules, as best I understand them,
all bets are off once the scope bit has been set
to local.

If the 4RD folks want to do something special when (U==0),
as far as I know there aren't any issues.  It is the 
apparent insistence upon changing the semantics of 
the (U==1) and (G==1) combination that is problematic.

Yours,

Ran

PS:  I'm now offline due to travel, and expect to be
     offline for several days.

---

From: Rémi Després <[email-masked]>
Date: Fri, 14 Dec 2012 12:02:28 +0100

> all bets are off once the scope bit has been set

In IEEE, g=1 always specifies that the MAC address is a group address, BOTH for universal and local scopes. 

> as far as I know there aren't any issues.  

This wouldn't work because 4rd needs a guarantee that its IIDs differ from those of the privacy option.

> It is the 

The proposal is only to use the u=g=1 pattern (never used so far in IIDs of unicast addresses) as the escape pattern permitting to specify new IID types (for IPv6 unicast addresses):
- u=0 => all other bits have any values (privacy option)
- u=1 and g=0 => all other bits comply with IEEE EUI-64
- u=g=1 => all other bits have an IETF defined format, determined by an IID type whose pattern is registered by IANA.

Regards,
RD

PS: Note that, to simultaneously run ILNP and 4rd in a site with a guarantee that they won't interfere, it is sufficient that ILNP node IDs are without u=g=1. Each experiment thus deals with its exclusive addresses its own way.