On 5/08/2008, at 4:02 AM, Templin, Fred L wrote:
Right, your assumption is that the customer NAT device changes - my assumption is that the customer NAT device stays the same, which is where we're differing here.The NAT box would be a natural location for the ISATAP router function, and I don't think entirely out of the question for change given the benefit. But, I'm not entirely sure that it is the only location; I will have to study more on what is meant by "Internet Connection Sharing" on Windows, for example.I agree with you - ISATAP is absolutely appropriate inside customer networks that have IPv4-only internal routing equipment, but have an IPv6 capable NAT box and hosts, and at least a single IPv6 /64. It is not clear to me how ISATAP can be used between the ISP and the customer CPE, should that CPE support ISATAP. My understanding is that ISATAP gives hosts single addresses, not a /64 as would be required by a second ISATAP domain, or by a subnet behind the CPE.ISATAP is about *hosts* receiving a single IPv6 address with an embedded IPv4 address.
Yes, I understand that. Your comment here seems contradictory to your previous comment: <snip> The idea is that the cusomter NAT becomes an IPv6 router. It does ISATAP on the customer-facing side and some other IPv6 capability on the SP-facing side. That could be a native IPv6 service, 6to4, or it could even be another ISATAP domain that is distinct and separate from the customer's ISATAP domain. </snip>It sounds here as though you are suggesting that a customer's NAT box/ CPE/whatever is receiving IPv6 connectivity with ISATAP, and then using ISATAP to distribute that connectivity within the customer's network.
VET is about *routers* receiving IPv6 prefixes for sub-delegation on their site-internal interfaces: http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14 The ISP/CPE routing region would use VET, which can be thought of as ISATAPv2.
I will read more about VET tomorrow.While it might be worthwhile for an ISP to consider using for rolling out their v6 service, I'm not sure we're having the same discussion, maybe I have mis-understood the intent of this thread.
I am talking about how to do IPv4 SP NAT in such a way that existing (ie. deployed as of the moment I write this email) IPv6 connectivity mechanisms do not fail, or if they do fail, they do so gracefully so that end users do not notice. While at the same time, preventing IPv4 address network overlaps on both sides of a CPE.
It would be nice if we could tell everyone to upgrade their CPE, OS etc. immediately to support new protocols, but really, our inability to do so is why we are having this discussion.
-- Nathan Ward