2013-01-27 17:32, Tom Taylor <[email protected]> : > Rémi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 2.5.1 > says: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format.
This sentence, because it applies to ALL unicast addresses that don't start with 000, does apply to MAP addresses. Suggestion: delete any reference to subnet IDs longer than /64. AFAIK, that's enough. Regards, RD > > However, the modified EUI-64 requirement is negotiable. Appendix A of RFC > 4291 says: > > Links without Identifiers > > There are a number of links that do not have any type of built-in > identifier. The most common of these are serial links and configured > tunnels. Interface identifiers that are unique within a subnet > prefix must be chosen. > > The MAP case is an example of "configured tunnels", I'd say. So there is no > requirement on the specific contents of the last 64 bits except that the u > bit has to be zero, since the IID isn't guaranteed to be universally unique. > > This leaves the requirement that the IID be 64 bits long. I can't see how to > get around this one without going to 6man and asking for a change. > > Just a further thought: requiring that the first subnet (the all-zeroes > subnet) be reserved for MAP doesn't mean much if the prefix doesn't contain a > subnet field. Does this provision have to change if the prefix reaches 64 > bits in length? > > Arithmetic example of what I would consider reasonable: > - /56 assigned to the subscriber > - sharing ratio = 64, implying 6 bits for the PSID field > - BMR shared only between CEs sharing the same IPv4 address, hence no address > bits needed in the EA bits field > => 6 EA bits, Rule IPv6 prefix is a /50. > > Here's an alternative example (assuming we can say something sensible about > what gets reserved if there is no subnet ID field): > - /64 assigned to the subscriber > - same assumptions as above on sharing > => Rule IPv6 prefix is a /58 > > Tom Taylor > > > On 26/01/2013 5:50 AM, Rémi Després wrote: >> Hi, Senthil, >> >> 2013-01-25 à 21:20, Senthil Sivakumar (ssenthil) <[email protected]> : >> >>> >>> >>> On 1/25/13 1:09 PM, "Tom Taylor" <[email protected]> wrote: >>> >>>> We have two choices on this one: >>>> >>>> a) prohibit the use of an end user IPv6 prefix of length greater than 64 >>>> bits; >>> >>> I would think that is restrictive. >> >> Why? >> RFC 4291 says "For all unicast addresses, except those that start with the >> binary value 000, Interface IDs are required to be 64 bits long ...". >> Doesn't this imply that MAP subnet prefixes always have 64 bits too? >> >> RD >> >> >>> >>>> >>>> b) simply remove the reference to RFC6052, or qualify it by saying that >>>> the IID conforms to Section 2.2 of RFC 6052 except in the case of end >>>> user IPv6 prefixes of length greater than 64 bits. >>> >>> That would be fine, but it is not clear now in the current draft if we >>> should skip the u bits >>> or overwrite them if the prefix length is greater than 64. >>> >>> Senthil >>> >>>> >>>> Any preferences? >>>> >>>> On 24/01/2013 7:22 PM, Ole Troan wrote: >>>>> Tom, >>>>> >>>>>> I believe that makes the IID non-conformant to RFC 6052. >>>>> >>>>> it uses an IID similar to 6052... any better suggestion? >>>>> (my personal view is that 6052 got things wrong with the U octet, but >>>>> that's another matter) >>>>> >>>>> cheers, >>>>> Ole >>>>> >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
