Remi,
On Dec 12, 2012, at 3:29 PM, Rémi Després <despres.r...@laposte.net> wrote: > Hi, Jouni, > > > 2012-12-12 10:04, Jouni Korhonen <jouni.nos...@gmail.com> : > >> >> Hi, >> >> >> On Dec 8, 2012, at 2:14 AM, Suresh Krishnan <suresh.krish...@ericsson.com> >> wrote: >> >>> Hi all, >>> >>> The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04) >>> describes a solution for providing IPv4 connectivity over IPv6. The >>> draft describes the method for mapping 4rd IPv4 addresses to 4rd IPv6 >>> Addresses. It uses a 4rd specific mark called the V octet in the first 8 >> >> V-octet was AFAIR first time discussed within the Softwire MAP design team >> and I had/expressed my concerns already that time. My argumentation was that >> we cannot just redefine the u & g bit use without actually having it verified >> against and reflected in RFC4291. Glad to see it happening now ;) >> >> IMHO the current language in RFC4291 does not give enough freedom to use >> u=g=1, since such combination is not specifically left unused/reserved >> (although u=g=1 makes no sense for the current IPv6). > >> IEEE allows MAC >> addresses that have I/G set to 1 and U/L set to 0, which makes me rather >> uncomfortable with IETF using u=g=1 for their own purposes. > > IEEE indeed permits group addresses for multiple interfaces that share a > common address but, as we are in the context of IPv6 UNICAST addresses, > interface all our IEEE-address derived IIDs have g=0. IETF can take advantage > of this fact without risk to interfere with IEEE, As I said above the u=g=1 (U/L=0, I/G=1) makes no sense to current IPv6 use (thus it looks like it could be used for other purposes). However, my point is that now we would be stepping into IEEE territory, which I am not comfortable with. - JOuni > > For more details, please see my last answer to Bob. > > Regards, > RD > > > > >> - Jouni >> >> >>> bits of the Interface Identifier. There were some concerns raised in >>> softwire about whether such addresses are actually compatible with the >>> IPv6 addressing architecture. Whether this is actually compatible with >>> the IPv6 addressing architecture is outside the scope of the softwire >>> wg. Hence we would like to hear the 6man wg's perspective on this. I >>> would like to request the wg to please go over the NOTE in Section 4.5 >>> page 18, which explains the issue, and over IANA Considerations Section >>> 6, and chime in on whether this is acceptable from a 6man perspective. >>> >>> Thanks >>> Suresh >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
