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.
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
