Hi, Usman, Thank you for this opportunity to clarify once more an important point.
2013-02-09 03:16, Usman Latif <osma...@yahoo.com> : > 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 <despres.r...@laposte.net> > To: Havard Eidnes <h...@uninett.no> > Cc: ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] > Message-ID: <7c04fb57-d1b8-42c5-803f-79bf58925...@laposte.net> > Content-Type: text/plain; charset=iso-8859-1 > > > Le 2013-02-08 ? 11:59, Havard Eidnes <h...@uninett.no> 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
