Ran, Oops!
I must really apologize for having given a wrong reason why 4rd doesn't conflict with ILNP as specified by RFCs. (I didn't check yesterday what I had understood, some time ago, after reading some of the ILNP RFCs, and definitely mischaracterized the reason). 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). Thank you for having pointed out the mistake. RD Le 2013-01-31 à 16:54, RJ Atkinson <[email protected]> a écrit : > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
