Hi Usman, /127 addressing and SLAAC is mutually exclusive, so I think it's out of the scope of the problem, where we discuss if u/g bit should be meaningful also for non-EUI-derived address.
Miya From: Usman Latif <[email protected]<mailto:[email protected]>> Date: Sunday, February 10, 2013 12:43 PM To: Rémi Després <[email protected]<mailto:[email protected]>> Cc: 6man 6man-wg <[email protected]<mailto:[email protected]>>, "Miya Kohno (mkohno)" <[email protected]<mailto:[email protected]>> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Hi Remi, The reason why no readdressing will be needed is tat RFC 6144 only concerns inter-router links. Their /127 IPv6 prefixes are distinct from those used with 64-bit IIDs. So if I understand it correctly, if a PE-CE link already has a /127 prefix assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to assign an additional IPv6 prefix to the CE with 64-bit IIDs? Pls share little detail with me in a scenario where a SP already has /127 with CEs and 4rd is needed from the CE thanks, Usman On 09/02/2013, at 8:16 PM, Rémi Després <[email protected]<mailto:[email protected]>> wrote: Hi, Usman, Thank you for this opportunity to clarify once more an important point. 2013-02-09 03:16, Usman Latif <[email protected]<mailto:[email protected]>> : Hi Remi, A few months ago, I raised some concerns around RFC 6164 which permitted use of /127 prefixes on inter-router p2p links. You mention use of u/g bits and reserved IID range for 4rd Don't you think that network operators who have by now implemented 6164 based addressing in their networks would end up having to readdress portions of their network where they intend to implement 4rd? The reason why no readdressing will be needed is tat RFC 6144 only concerns inter-router links. Their /127 IPv6 prefixes are distinct from those used with 64-bit IIDs. Incidentally, I wrote myself: - "it is a fact that, *for some addresses that aren't concerned with SLAAC*, typically some manually configured addresses, the IID structure of RFC 4291 can be ignored. One example where it is actually ignored is in RFC 6164 which deals with /127 prefixes on inter-router links. (Incidentally, I have been an active supporter of this RFC, as Miya Kohno may remember" (ref. http://www.ietf.org/mail-archive/web/ipv6/current/msg16988) - "For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful." (ref. http://www.ietf.org/mail-archive/web/ipv6/current/msg17023). Regards, RD Rgds, Usman Date: Fri, 8 Feb 2013 16:51:19 +0100 From: R?mi Despr?s <[email protected]<mailto:[email protected]>> To: Havard Eidnes <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] Message-ID: <[email protected]<mailto:[email protected]>> Content-Type: text/plain; charset=iso-8859-1 Le 2013-02-08 ? 11:59<x-apple-data-detectors://41>, Havard Eidnes <[email protected]<mailto:[email protected]>> a ?crit : However, there is nothing which enforces RFC4291-conforming IIDs for (for instance) statically configured IPv6-addresses. So in what way do well defined u/g values for RFC4291-conforming IIDs help you? 1. Users that manually configure their IPv6 addresses should be knowledgeable about what they do. If one configures an address has u=g=1, unless it is for an experiment, it is a human mistake (it conflicts with the IPv6 addressing architecture of RFC 4291). Depending on the context, this mistake will have no consequence or will eventually have to be corrected. What's the operational failure mode? Does it fail in a way which would be obvious to the ones who has made this mistake, or will simply some seemingly-random pairs of hosts fail to communicate? I think it would be an engineering mistake to willfully create hard-to-detect failure scenarios via a modification to already fielded standards. FULL AGREEMENT that we don't want to modify any "already fielded standard". If you believe such a change is needed for 4rd, PLEASE EXPLAIN. If one configures an address that doesn't follow configuration constraints, it may fail in various ways, but under its own responsibility. For instance, if it has the wrong subnet prefix, it won't be reachable from across the Internet, like what may happen if it has a non-RFC4291-complying IID that happens to be in the 4rd reserved range in a site where 4rd is activated. Note that, even if one does such a mistake in a 4rd site, the likelihood of using the 4rd IID prefix 0x0300 remains low. That's a nice handwave... This is a fact, worth noting IMHO, especially since the particular example of a non RFC4291-compliant address Ole gave didn't conflict with 4rd. Your lack of interest for this point doesn't justify, IMHO, a so depreciating comment. 2. On my home network, I know nobody is doing manual configuration. That doesn't really prove anything. It doesn't prove anything, OK, and wasn't BTW claimed to prove anything in particular. Yet, the risk of manual misconfigurations that may conflict with the RFC 4291, which is indeed a risk, is mitigated by the fact that manual address configuration is AFAIK more an exception than a general practice. Regards, RD
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
