Le 2012-12-12 à 17:12, Jouni Korhonen <[email protected]> a écrit :
> > Remi, > > > On Dec 12, 2012, at 3:29 PM, Rémi Després <[email protected]> wrote: > >> Hi, Jouni, >> >> >> 2012-12-12 10:04, Jouni Korhonen <[email protected]> : >> >>> >>> Hi, >>> >>> >>> On Dec 8, 2012, at 2:14 AM, Suresh Krishnan <[email protected]> >>> 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). OK. > However, my point is that now we would be stepping into IEEE territory, which > I am not comfortable with. My last answer to Brian answers this concern (I think). RD > > - 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 >>>> [email protected] >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
