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

[Mark Townsley <[e-mail]>]

Templin, Fred L wrote:
> Mark,
>
>   
>> -----Original Message-----
>> From: Mark Townsley [mailto:[e-mail]]
>> Sent: Wednesday, May 20, 2009 6:17 AM
>> To: Templin, Fred L
>> Cc: Rémi Després; Sheng Jiang; [e-mail]; [e-mail]; [e-mail];
>> Fleischman, Eric; Russert, Steven W
>> Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
>>
>>
>> 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.
>>     
>
> I must apologize to you and to the list for inappropriate
> non-technical content directed toward you in an earlier
> message. That said, I believe the following technical
> content merits consideration.
>   
No problem.
> For the 6rd prefix discovery, what you are suggesting is
> simply a stateless IPv6 prefix delegation. It is stateless
> in the sense that the customer need only discover the
> operator's /32 or larger prefix, and then the customer
> can self-assign its own IPv6 prefix based on its IPv4
> address.
Yes, that's a significant part of it.
>  This can be done as a DHCPv4 option,
Yes.
>  or if
> link-local IPv6 is available it can also be done as a
> DHCPv6 option. But, stateless IPv6 prefix delegation
> is really what it is
>   

The transition mechanism is targeted to provide IPv6 to a residential 
internet user over an access network that is currently only able to 
provide IPv4. If the RG has any IPv6 address on its SP-facing interface, 
and DHCPv6 is deployed in the SP network, then the SP is probably well 
on its way to not needing 6rd anyway.
> For 6rd router unicast/anycast address discovery, that
> function would be identical to the potential router list
> (PRL) discovery mechanisms of ISATAP/VET. Indeed, 6rd is
> nothing more than ISATAP/VET with many of the features
> removed. 
Everything under the sun has already been invented. I think of 6rd as 
more a modification to 6to4, but I suppose it depends on your perspective.
> A worthwhile idea to consider is to combine
> the 6rd stateless prefix delegation (which AFAICT is
> its primary contribution) with the already defined
> mechanisms of ISATAP and VET.
>   
On the face of it, I fail to see what that would provide given what 6rd 
sets out to achieve. Perhaps we can better have this discussion once the 
-00 is available though.

- Mark
> Fred
> [e-mail]
>
>   
>> - 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
>>>>
>>>>         
>>>
>>>       
>
>
>