[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6-v4 transition scenarios, take 2



On 5/08/2008, at 3:26 AM, Templin, Fred L wrote:

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.

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.

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.

If the SP can't provide an IPv6 service of any kind,
then there is always the possibility to use Teredo.

Yes - however Teredo is selected after 6to4 on Windows. There are two ways a customer might use, for example, an ADSL service:
1) Have a NAT box. Teredo will work fine.
2) Plug their Windows PC in to an ADSL device that lets the ISP assigned IPv4 address exist on the PC ("modem"). The PC tries to bring up 6to4, as in my recommendation RFC1918 addressing is not used by the ISP for customer assignments to avoid address conflicts. Teredo will not come up, as a Windows host will assume 6to4 is functioning.

The two ways to avoid (2) being a problem are in my initial post in this thread, under "There are two work-arounds for this that I can see, and I think it is a good idea to do both.".

--
Nathan Ward