Hi Templin, > > The ISATAP (RFC5214) solves the above routing scalability issue with > the > > automatic tunneling address by concatenating a /64 LIR prefix and an > ISATAP > > interface ID (which is constructed in the Modified EUI-64) to generate > an > > IPv6 Global unicast address. I wonder whether it is better to directly > > concatenate a /96 LIR prefix (which can be learnt from the prefix > > information option in the RA message) and a 32-bit IPv4 address to > generate > > an IPv6 address. One obvious benefit of this method is IPv6 prefix > resource > > can be allocated in a more efficient way. > > I floated the idea of a /96 for ISATAP during either an > intarea or ipv6 meeting several years ago (can't remember > which) but there was no uptake. Looking back, I don't see > any advantages, and in fact it goes against the model in > which IPv6 addresses beginning with other than '000' use > a 64-bit prefix.
Yes, I also noticed the above specification defined in RFC4291 as "... 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, I don't know what the real meaning of such constraint is in practice. Can anybody kindly help me understanding this? > Indeed, ISATAP and SLAAC already fit > together naturally, and I see no reason to change that. Yes, I agree with your opinion to some extent. It seems too early to consider how to use the IPv6 address resource in an efficiently way. However, the Internet history is, at the initial stage of the Internet deployment, seldom people thought about CIDR since most people believed the IPv4 address is most enough for use in the future. Unfortunately, the reality is beyond most people's expectations. Maybe the same problem will not happen on IPv6. Xiaohu > > By the way, the IPv6 DAD action > > can also be avoided since the IPv4 address is already guaranteed to be > > unique. > > This was left as a silent assumption in RFC5214, but it > is called out explicitly in VET. > > Thanks - Fred > [email protected] > > > > > Xiaohu > > > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
