RE: v6-v4 transition scenarios, take 2

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Nathan, 

>-----Original Message-----
>From: Nathan Ward [mailto:v6ops@daork.net] 
>Sent: Monday, August 04, 2008 10:02 AM
>To: Templin, Fred L
>Cc: v6ops WG
>Subject: Re: v6-v4 transition scenarios, take 2
>
>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.

Taken literally you are right, but I was meaning to refer
to ISATAP behind the customer's NAT and VET (ISATAPv2)
within the CPE/ISP network. Think of VET as just ISATAP
plus support for router-to-router tunneling and multicast. 

>> 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.

OK.

>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.

Right, and I don't see the disconnect.

>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.

I'm not sure any upgrade is needed; only configuration.
I don't know enough about CPE to comment, but I believe
OS support is there already.

Fred
fred.l.templin@boeing.com

>
>--
>Nathan Ward
>
>
>
>
>