Subject: Re: 4rd IID range & IPv6 addressing architecture

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Feb 2013 08:54:57 -0500

On 31  Jan 2013, at 13:11 , Rémi Després wrote:
> What ensures 4rd doesn't conflict with ILNP isn't at all
> that ILNP only uses u=0.  
> 
> It is that, in ILNP, no u=g=1 is used in *unicast* addresses
> (those whose IIDs are specified by RFC 4291). 

This is still inaccurate.  

I REALLY would be greatly obliged if you would not speculate 
about ILNP on IETF/IRTF mailing lists, primarily because 
any speculation is likely to be wrong -- and create needless
confusion amongst other folks on those lists. 

Some published ILNP papers talk about a form of multicast
addressing/routing that we believe is novel and are exploring.  
This combines a unicast routing prefix in the high-order 
64-bits with an IEEE EUI-64 compliant (and RFC-4291 
compliant) multicast group ID (i.e., U=G=1) in the low-order 
64-bits.  Because of existing IETF standards-track work 
where U=0, for example CGAs or "privacy" addresses, the 
U=0 identifier space (i.e., U=0 and G=1) can NOT be used 
for multicast identifiers.

So the proposed 4rd reservation of all (or most) uses of 
addresses with the combination of (A) U=G=1 identifier space 
and (B) unicast routing prefix is a direct conflict with
published ILNP papers and active ILNP work.

Both ILNP and 4rd are Experimental, at least today.  
This is why I tabled the possibility of allocating 
a small portion of the U=G=1 space under RFC-3692 shared 
experimental use rules.  That would permit multiple 
experiments to proceed, and is the usual IETF custom
for experimental work when a limited protocol-registry
resource is involved.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2013 14:37:55 +0000

Ran,

I looked at the ILNP RFCs while we were preparing draft-carpenter-6man-ug-00,
and it seemed to me that ILNP doesn't in fact use IIDs, but rather
a redefinition of the bottom 64 bits as a Node Identifier [RFC6741].
Doesn't that separate the use of the u/g bits for ILNP completely
from their use in plain IPv6?

Please have a look at the draft and suggest corrections if it seems
wrong to you.

Regards
   Brian

On 01/02/2013 13:54, RJ Atkinson wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Feb 2013 10:26:39 -0500

On 01  Feb 2013, at 09:37 , Brian E Carpenter wrote:
> I looked at the ILNP RFCs while we were preparing
> draft-carpenter-6man-ug-00, and it seemed to me that
> ILNP doesn't in fact use IIDs, but rather a redefinition
> of the bottom 64 bits as a Node Identifier [RFC6741].

ILNPv6 changes the *semantics* of the lower 64-bits 
*from the view of the transport-layer and above*, 
but is quite careful to keep the syntax unchanged.

Keeping the syntax unchanged is crucial to ensuring
that ordinary IPv6 routers can/will forward ILNPv6 
packets -- without even needing to know that they are 
ILNPv6 packets.

In turn, the ability of ILNPv6 to incrementally-deploy
within an already extant IPv6 deployment is crucial.
Flag-day transitions are broadly unacceptable for
very good operational reasons, so ILNPv6 must remain 
backwards-compatible with existing IPv6.

A great deal of time was spent engineering both ILNPv4
and ILNPv6 to ensure that each would be backwards-
compatible with IPv4 and IPv6 infrastructure (respectively).

> Doesn't that separate the use of the u/g bits
> for ILNP completely from their use in plain IPv6?

No, as explained above.

> Please have a look at the draft and suggest corrections
> if it seems wrong to you.

I haven't done yet, due to lack of time,
but will put reviewing that onto my to-do list.

Thanks,

Ran

---

From: Rémi Després <[email-masked]>
Date: Fri, 1 Feb 2013 16:30:23 +0100

Ran,

Going directly to your conclusion, it appears we have a clear common interest!

Each of the designs we are interested in depends, to be complete, on reservation of a subset of the IID space left unused by RFC4291 (that having u=g=1).

Since you talk about "a small portion" of this space for ILNP, and since 4rd only needs only 1/2^14 of this space, I rather see convergence than conflict.

Hoping we can agree on it,
Regards,
RD

A few secondary comments inline.

> confusion amongst other folks on those lists.

Contributing on IETF mailing lists, including on what concerns existing ILNP RFCs, is a right anyone has AFAIK.  

> 64-bits.

> Because of existing IETF standards-track work 

This is precisely the point I have actively contributed to make in 6man!

> published ILNP papers and active ILNP work.

The currently proposed IID prefix is 0x0300. It only uses 1/2^14 of the u=g=1 space of RFC-4291.

This can't be characterized as " reservation of all (or most) uses" of this space. (Your turn to misrepresent, by mistake, the situation. Your apologies after mine will be welcome.)

> for experimental work when a limited protocol-registry

As said at the top of this mail, this shows we have converging interests.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2013 15:34:25 +0000

> but is quite careful to keep the syntax unchanged.

Right, that was how I understood it. I'm hoping that what
the draft proposes is compatible with ILNP, so I await
your comments.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Feb 2013 15:57:32 -0500

On 01  Feb 2013, at 10:30 , Rémi Després wrote:
> Each of the designs we are interested in depends, to be complete,
> on reservation of a subset of the IID space left unused by RFC4291
> (that having u=g=1).

Both are *experiments*.  Neither is a standard.

With respect to Softwire, they decided to standardise
something other than 4rd.  Had they decided to 
standardise 4rd, my views would be different, 
but that wasn't the decision actually made in Softwire.

For *experiments*, a small shared use experimental 
allocation *under RFC-3692 rules* should be both 
sufficient and an appropriate approach -- and also
can be used with any other experiments that might arise 
in future.

I haven't asked for any ILNP-specific allocation,
in part because my reading of the standards-track RFCs, 
for example in RFC-4291, is that the (U=1 and G=1) space 
is ALREADY designated for Multicast Identifiers.

Yours,

Ran

---

From: Rémi Després <[email-masked]>
Date: Sat, 2 Feb 2013 11:40:04 +0100

> can be used with any other experiments that might arise 

Different understanding.

Making the reservation for one design, experimental or not, is a guarantee that no future design with conflict with it, experimental or not.

A central registry is the appropriate tool for this.

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Sat, 02 Feb 2013 12:02:19 -0300

> Making the reservation for one design, experimental or not, is a guarantee that no future design with conflict with it, experimental or not.

The point is that if't an experiment, you don't really want to
permanently-asign any resources to it. -- that's probably why run
suggested a "shared allocation".

If the experiment turns out to be successful, you get the actual assignment.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Rémi Després <[email-masked]>
Date: Sat, 2 Feb 2013 16:09:32 +0100

> If the experiment turns out to be successful, you get the actual assignment.

As answered to Ran:
- Making the reservation for one design, experimental or not, is a guarantee that no future design will conflict with it, experimental or not.
- A central registry is the appropriate tool for this.

Besides reserving 1/2^14 of the unused space, for which there hasn't been any request in more than 6 years now, shouldn't be considered a big deal (IMHO).

Regards,
RD