Hi Xu, > -----Original Message----- > From: Xu Xiaohu [mailto:[email protected]] > Sent: Wednesday, September 02, 2009 7:16 PM > To: [email protected]; 'Behave WG' > Subject: [Softwires] Some Thought about the Automatic Tunnel Address > > Hi all, > > As quoted from "IPv6 Transition Mechanism" [RFC1933], "...The tunnel > endpoint is the node to which the IPv6 packet is addressed. Since the > endpoint of the tunnel is the destination of the IPv6 packet, the tunnel > endpoint can be determined from the destination IPv6 address of that packet: > If that address is an IPv4-compatible address, then the low-order 32-bits > hold the IPv4 address of the destination node, and that can be used as the > tunnel endpoint address." > > Unfortunately, the usage of IPv4-compatible address may cause routing > scalability issue for IPv6 in practice when multiple sites use such > addresses. > > 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. Indeed, ISATAP and SLAAC already fit together naturally, and I see no reason to change that. > 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
