Re: New Version Notification for draft-jiang-v6ops-incremental-cgn

[Mark Townsley <[e-mail]>]

Indeed, 6rd is targeted to ISPs who have the ability to specify the 
residential gateway's functionality. This certainly does not apply to 
all ISP offerings, but it does apply to quite a few.

As Remi points out, he and I (and others) have been working together 
recently on a new 6rd spec which includes some of the things discussed 
here (DHCP options, etc). Current plan is to have that out in the next 
week or so.

- Mark

Templin, Fred L wrote:
> Remi,
>
>   
>> -----Original Message-----
>> From: Rémi Després [mailto:[e-mail]]
>> Sent: Tuesday, May 19, 2009 2:19 AM
>> To: Templin, Fred L
>> Cc: Sheng Jiang; [e-mail]; [e-mail]; [e-mail]; Fleischman,
>> Eric; Russert, Steven W
>> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
>>
>> Templin, Fred L  -  le (m/j/a) 5/14/09 5:17 PM:
>>     
>>> Dear authors,
>>>
>>> The document is clean and concise, which is appreciated.
>>> However, section 3.2 seems to be showing preference
>>> toward a particular tunneling technology, and I'd like
>>> to understand that better.
>>>       
>> As explained in the 6rd draft (soon to become an RFC), 6rd solves the
>> major problem of 6to4: the lack of guarantee that paths exist between
>> all IPv6 sites and all 6to4 sites, and that these paths have ISP
>> controlled QoS.
>>     
>
> Yes, so is VET soon to become an RFC. But, 6rd is not solving a
> 6to4 problem with its open relays; it is solving an intra-site
> problem with ordinary IPv6 routers just like VET.
>  
>   
>>> To understand this, we must first observe that the 6rd
>>> approach relies on anycast for CPE router accessing of
>>> IPv6 routers within the IPv4 ISP network.
>>>       
>> The important point is that the 6rd-relay address MAY be anycast. If
>> there is only one relay at this address, there is no difference with an
>> anycast address.
>> Reasons for permitting  anycast are SCALABILITY and AVAILABILITY of the
>> solution:
>>     
>
> Just for the record, ISATAP/VET can use anycast just
> the same as for 6rd but chose not to specify it. This
> choice was based on deliberations between authors and
> working group alike that identified the stated problems.
>
>   
>> - if available relays seem to be soon insufficient for the traffic, just
>> add one more, at the same anycast address. While ISATAP is intra-site,
>> 6rd relays, like those of 6to4 which also use an anycast address, have
>> to support all the IPv6 traffic of an ISP that uses 6rd.
>> - if a 6rd-relay fails, the traffic goes to another one.
>>     
>
> No; 6rd is intra-site. The site is the ISP operator's
> network.
>
>   
>>   The idea of
>>     
>>> anycast was entertained and abandoned by the ISATAP
>>> team in the 2001/2002 timeframe when ISATAP was still
>>> being developed in the ngtrans working group. This came
>>> after much discussion among authors and guidance from
>>> the working group. Reasons include:
>>>
>>> 1) if the tunnel fragments, fragments of the same packet
>>>    may go to different anycast-addressed routers.
>>>       
>> If the ISP supports an IPv4 MTU long enough for IPv6 packets of 1280
>> octets (as it should) and discards longer ones, no fragmentation is ever
>> needed.
>> This is common with 6to4, which uses anycast addressing for its relays.
>>     
>
> 1280 is an unsatisfactory MTU for customer devices that
> would prefer to use 1500. The CPE is an in-the-network
> tunnel endpoint such that customer devices on a 1500
> segment would be constantly inconvenienced with ICMP
> PTB messages were the CPE to deploy with only 1280.
>
> But, if you want to push the CPE tunnel endpoint to
> 1500, you have to allow for the possibility of
> fragmentation. VET and SEAL solve this problem.
>
>   
>>> 2) with anycast, there is no opportunity for default
>>>    router selection (when there are multiple)
>>>       
>> Yes. But what is the practical problem?
>>     
>
> If there are multiple PE routers in the ISP network,
> the CPE should have the ability to distinguish them
> and choose between them - just as for any link where
> there may be multiple routers.
>
>   
>>> 3) with anycast, there is no opportunity for traffic
>>>    engineering
>>>       
>> Different source zones may be oriented toward different relays, or relay
>> farms with internal load balancers.
>>     
>
> Traffic engineering is the ability for a CPE router
> to direct some traffic through PE router A and other
> traffic through PE router B. With anycast, the CPE
> router can't discern A from B.
>
>   
>> All the complexity of deciding which customer sites should receive which
>> unicast addresses is avoided.
>>     
>
> I don't see anything having to do with complexity, really.
> And, it's the very same consideration as to which customers
> should receive which DNS suffixes.
>
>   
>>> 4) with anycast, IPv6 neighbor discovery over the
>>>    tunnel may yield unpredictable results
>>>       
>> Neighbor discovery doesn't apply more over 6rd tunnels than it does on
>> 6to4 tunnels.
>>     
>
> Neighbor discovery is useful in many ways. NUD, default
> router preferences and more specific routes, SEND, and
> many more. 6rd is not really comparable to 6to4, however;
> 6rd is intra-site just as ISATAP/VET.
>
>   
>>> 5) with anycast, there is need for a manual provisioning
>>>    of IPv6 prefixes and IPv4 anycast address on the CPE
>>>    router.
>>>       
>> As explained in the draft, Free deployed 6rd with their 6rd parameters
>> included in their downloaded CPE software (IPv6 prefix and relay anycast
>> address).
>>     
>
> This is unnecessarily marrying the CPE devices to the
> ISP in a way that CPE vendors might not appreciate. It
> also makes renumbering and discovery of new prefixes
> quite cumbersome.
>  
>   
>> For independently supplied CPEs , tools to convey these parameters have
>> to be specified. As far as I know, Mark Townsley is working on a
>> proposal for this.
>>     
>
> If Mark Townsley is working on a proposal for this, he is
> re-inventing ISATAP PRL discovery. See also my proposal
> for stateless DHCP prefix delegation for the 6rd prefix.
>
> Fred
> [e-mail]
>
>   
>> Regards,
>>
>> RD
>>     
>
>
>