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]> wrote: > Hi, Usman, > > Thank you for this opportunity to clarify once more an important point. > > 2013-02-09 03:16, Usman Latif <[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]> >> To: Havard Eidnes <[email protected]> >> Cc: [email protected] >> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt] >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=iso-8859-1 >> >> >> Le 2013-02-08 ? 11:59, Havard Eidnes <[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 --------------------------------------------------------------------
