Tom, > The examples in my previous note sort of provided backing for my view that > the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus > making the IID fully conformant both to RFC 4291 and to RFC 6052. > > Obviously, the more IPv4 address bits you can stick into the EA bits, the > fewer the number of MAP rules you have to provision. The picture of a MAP > endpoint IPv6 prefix can be drawn like this: > > > +-----------------------------+-------------------+-----------+ > | Rule IPv6 prefix | IPv4 suffix | PSID | > +-----------------------------+-------------------+-----------+ > | | | | > | Common to all CEs sharing | Common to all CEs | Unique to | > | the same BMR | sharing the same | this CE | > | | IPv4 address | | > > > If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more than 8 > bits in length (i.e. CEs get 512 ports each, sharing ratio is 128), limiting > the endpoint IPv6 prefix to 64 bits leaves room for eight bits of suffix. > That in turn means each mapping rule serves 16384 CEs. If the Rule IPv6 > prefix backs off to a /40, we can get two million CEs per mapping rule. > > I think limiting the prefix length to 64 bits is reasonable. Comments?
I don't think that's reasonable. and I don't see what it buys us, given that supporting prefix lengths longer than 64 is simple. IPv6 isn't classfull, there isn't anything magic with the 64 boundary. ;-) cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
