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

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. 


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

 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.


2) with anycast, there is no opportunity for default
   router selection (when there are multiple)


Yes. But what is the practical problem?


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.
All the complexity of deciding which customer sites should receive which unicast addresses is avoided. 



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. 



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

Regards,

RD