On Thu, Nov 13, 2008 at 1:16 PM, Scott Brim <[EMAIL PROTECTED]> wrote: > I was thinking about unilateral mode. In Unilateral Mode, Six/One > Router does a 1:1 translation at a site boundary, without involvement of > mapping services or a requirement for reverse translation. I get the > feeling unilateral mode may be OBEd by NAT66, but I haven't asked Christian.
Outbound with clients behind the Six/One Router, that looks like plain old client NAT. Client NAT is a fine thing, but it's already widely deployed so it isn't likely to improve the routing table versus what we have today. Inbound with servers behind the Six/One Router, I'm pretty sure it doesn't work. The raw networking part works. The fault isn't obvious until you step back and take a holistic view, but it would require an impractically complex split-horizon DNS system. Hosts on legacy networks must find the provider-assigned address and hosts on Six/One Router-served networks must find the PI address. I say impractically complex because all DNS requests are relayed by a caching resolver, usually on a different machine than the client host. The AAAA DNS query may even come from an IPv4 address! As a result, you can't just build a smart authoritative DNS server that hands out different IPs depending on the request source address. And you can't just err on the side of handing out the provider-assigned address: that address is unreachable to any user behind a Six/One Router because the user's Six/One Router will alter the address in the response! IMO, this isn't deadly to Six/One Router. There is such a dearth of IPv6 deployment that one could reasonably just say that "legacy" IPv6 users are required to add a Six/One Router at their border. >> Maybe that's an engineering compatibility difference like the >> gyrations for PMTU in map-encap rather than an architectural >> difference? What do you think? I'm gonna back off on this assertion and the earlier one about backwards compatibility not being an architectural issue. If I add the following to strategy A, does it cover the strategies you've talked about? Strategy A. Compatibility approaches include: A4a. New IP protocol. Not compatible with IPv4 and IPv6. A4b. Modified IP protocol. Not compatible with deployed IPv4 and IPv6. A4c. Standard IPv4 and IPv6 packets are encapsulated in a tunnel packet while they transit the core. Path-MTU issues are addressed by setting an Internet-wide maximum packet size enforced by the encoders and assuring that all core links support that size. A4d. Standard IPv4 and IPv6 packets are encapsulated in a tunnel packet while they transit the core. Path-MTU issues are addressed by returning packets which breach the MTU while in the core to the encoder who must act as a proxy by returning a sensible packet-too-big message to the originating host. A4e. The IPv6 address space is partitioned into end-user address space and Internet core address space. The address to RLOC map is symmetric. Part of the IPv6 end-user address is swapped for the RLOC when the packet enters the Internet core and then restored when it leaves the core. IPv4 is abandoned. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
