Hi Suresh,
> 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
> 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.
It certainly makes me nervous. The proposed format misuses the "g" bit,
which is supposed to flag multicast. Can it be proved beyond doubt that
such an address will never escape a context in which the V octet will
only be interpreted 4rd-style? This is not clear to me from the draft.
I would be less nervous if you could also set the OUI bits to a reserved
value for this purpose.
For this, the V octet has its "u" and "g" bits of
[RFC4291] both set to 1, so that they differ from "u" =
0, reserved for Interface IDs that have local-scope, and
also differs from "u" = 1 and "g"= 0, reserved for
unicast Interface IDs using the EUI-64 format. Bits
That should be "modified EUI-64 format"
other than "u" and "g", are proposed to be 0, giving V =
0x03. 4rd is thus the first "future technology that can
take advantage of interface identifiers with universal
scope" [RFC4291].
I find that sentence hard to swallow. It's recycling the u and g bits
but I don't see how it takes advantage of universal scope. I would
just delete the sentence.
As such, it needs to be endorsed by
the 6man working group and IANA (Section 6).
This sentence too can be deleted before RFC publication.
o An IPv6 Interface-ID type reserved for 4rd (the V octet of
Section 4.5). For this creation of new registry is suggested for
Interface-ID types of unicast addresses that have neither local
scope nor the universal scope of Modified EUI-64 format
[RFC4291]). This registry is intended to be used for new
Interface-ID types that may be useful in the future.
I don't get this. The possible ug combinations are all theoretically
valid today, aren't they? 11 means globally unique multicast. The only
way you can protect them as a 4rd flag is by using a dummy OUI value,
as far as I can see. I think that is what you should ask for (from
IEEE, not IANA).
Regards
Brian Carpenter
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
