2012-12-12 18:38, RJ Atkinson <[email protected]> : > > On 12 Dec 2012, at 12:14 , Rémi Després wrote: >> In any case, IIDs for multicast addresses are out of scope for the IPv6 >> addressing architecture of RFC 4291. > > Disagree. It is clear that RFC-4291 has reserved > the use of G==U==1 for multicast identifiers.
Different understanding. > >> An important point to be noted is that, in the translation direction >> from EUI-64 of IEEE to modified EUI-64 of IETF, the proposed format >> implies no change at all. > > It *breaks* the reverse mapping, however, whereas today > the *bi-directional* mapping works reliably. Reverse mapping, whose use I still don't see, cannot work the privacy option of RFC 4941: with it, individual IIDs can have g=1 while remaining those of unicast addresses. >> In other words, reserving a /8 IID prefix for 4rd (and possibly >> some others for new types of unicast addresses) won't prevent >> from using IEEE-based IIDs with u=g=1 for multicast. > > Incorrect. > > As a trivial example, one can use a unicast routing prefix > to specify an RP location, along with a multicast group-id > (so that the RP knows to multicast RPF the packet). This > has the potential to reduce the state required in inter-domain > routers, to give an example of why this approach can be useful. I suppose you implicitly refer to the ILNS of RFC 6740. As said in the RFC itself, I-LVs of ILNS and IPv6 addresses are "*not* equivalent". In particular, I-LVs contain "Node" IDs where IPv6 addresses contain "Interface" IDs. In any case, it remains unclear why, in I-LVs starting with the /64 of unicast addresses, it would be useful to permit the group bit to be set in their node IDs. Explanation welcome. > ... Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
