Remi,
PLEASE STOP making incorrect statements about ILNP.
Perhaps you haven't had time to read the full ILNP
literature, but your (repeated) claims about ILNP
are wrong -- contradicted by published papers, etc.
For those who'd like to read more about ILNP, a reasonably
complete archive of ILNP papers is maintained online at:
http://ilnp.cs.st-andrews.ac.uk
Most papers there are freely available, but a few have
copyright restrictions and link to appropriate access URLs.
I understand your desire to strongly advocate for
your proposal, but please STOP mis-characterising
ILNP as part of your advocacy.
All,
On 21st January, Remi Depres wrote, in part:
> (In particular, they don't conflict with those
> of ILNP.)
This is NOT true.
ILNP has published papers describing the use of
(U=G=1) as a multicast group identifier with ILNP.
As with ALL of ILNP, that use is experimental at
present.
However, the proposed "4rd" is ALSO EXPERIMENTAL.
The Software WG decided to standardise a different
proposal -- not standardise "4rd". Separately,
we have several different IPv6 transition technologies
defined, most of which are NOT used (or not used
in any measurably frequent way).
On 30th January, Remi Depres wrote, in part:
> ILNP, which has u=0.
> Out of scope!
1) The quote above is wrong. ILNP uses the U bit
as defined by RFC-4291 && by IEEE EUI-64 standards.
So ILNP has BOTH U=1 and U=0 support. ILNP also
uses the G bit as defined by IEEE EUI-64 standards
when U=1. This use is consistent with the IESG
2) ILNP does have published papers describing the use
of (U=G=1) as a multicast group identifier with ILNP.
As with ALL of ILNP, that use is experimental at
present. Again, "4rd" is being proposed as experimental
also, because Softwire chose to standardise a different
(competing) proposal.
On 30th January, Ole Troan wrote, in part:
> On 30th January, Remi Depres wrote, in part:
>> ("The use of the universal/local bit in the Modified EUI-64
>> format identifier is to allow development of future technology
>> that can take advantage of interface identifiers with universal
>> scope").
>
> yes, that technology is called ILNP. It does not require
> globally unique interface identifiers, which in any case
> would have required some sort of registry.
(clarification)
I believe that at the time RFC-4291 was written, that phrase
referred to the GSE/8+8 concept from Mike O'Dell. ILNP is
an intellectual descendant/relative of Mike O'Dell's proposals,
as is HIP, but ILNP is more fully specified than GSE/8+8 and
has some technical differences from GSE/8+8. ILNP does
"take advantage of interface identifiers with universal scope".
However, I believe some other protocols by other folks
also seek to do so.
There is the larger topic here. This proposal is not mere
bit twiddling, but in fact makes a significant architectural
change. Reading the discussions here, it is not obvious
to me whether the 6MAN WG wants to make those fundamental
architectural changes to the IPv6 Identifier namespace.
For my own part, I'm not persuaded that such changes are
wise to undertake at this time.
(new topic)
Ray Hunter and others make compelling arguments that
4rd does not need this allocation in order to go forward
*as an experiment* (which is precisely what Experimental
status means in a document) at this time. So it seems
rash and premature to make a large permanent allocation
of a limited resource to the 4rd experiment at this time,
especially since Software WG is standardising an approach
directly competing with "4rd".
I would not object to having some small set aside of
Identifier space for SHARED experimental use under the
RFC-3692/RFC-4727 rules, provided that it were clear that
such experiments could NOT interfere with proper operation
of SLAAC or other basic IPv6 operational functions
(i.e the caveat that Ray Hunter explained on-list in
recent days).
Yours,
Ran Atkinson
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
