Brian E Carpenter - le (m/j/a) 3/25/09 2:23 PM:
On 2009-03-26 08:25, Rémi Després wrote:
Rémi Denis-Courmont - le (m/j/a) 3/25/09 10:16 AM:
On Wednesday 25 March 2009 18:05:36 james woodyatt wrote:
[moving discussion into V6OPS from 74attendees]
On Mar 25, 2009, at 08:03, Rémi Després wrote:
RFC 3068 (An Anycast Prefix for 6to4 Relay Routers) does more harm
than good. IMHO, it should be deprecated.
I would support that, providing first that 6RD is A) adopted as a
proposed standard, and B) comes to see more widespread deployment than
6to4. I also believe the latter is very likely to happen contingent
on the former, so I would vigorously support taking up 6RD as a
working group activity.
Anycast 6to4 has problems. I guess Nathan Ward will present some of those. 6RD
solves many of the shortcomings of 6to4, _assuming_the_ISP_deploys_it_.
But lest we deprecate the entire scenario of automatic IPv6 setup without ISP
support, I fail to see how 6RD can replace anycast 6to4.
Thanks for your comment.
Using 6to4 between two 6to4 user sites is NOT a problem, and indeed MUST remain
possible.
But using a source 6to4 address to reach a non-6to4 destination IS a problem,
and IMHO MUST be deprecated ASAP.
I'm sorry but this makes no sense. 6to4 users (they exist) need to
reach the IPv6 Internet, and a 6to4 relay is the only way to do that,
so they have to exist too. Otherwise we are creating IPv6 islands, which
is a bad idea for encouraging adoption.
The fact that the anycast technique leads to black holes is well known;
I've been a victim of it myself. I'd be much happier if 6to4 had been
deployed as described in RFC3056, but we have to deal with reality.
Once again, see draft-nward-6to4-qualification for one way to
do that.
Agreed (a partial backtrack): if a 6to4 host first checks that it has a
return path from a native v6 site, then it may proceed rather than
giving up v6 and falling back to v4.
Note however that, for still some time, falling back to v4 when the
quality of v6 paths is not guaranteed is not a bad choice.
Note also that Nathan's proposal checks only connectivity. Uncertainty
on QoS remains, due to the lack of control on which 6to4 relay routers
are used in return paths.
6to4 to non-6to4 being the only reason for 6to4 relay routers, and for the 6to4
anycast address to reach them, they are what needs being deprecated.
I guess RFC 3484 should also be updated to say that a 6to4 address MAY be used
if both source and destination are 6to4, but ONLY in this case.
Absolutely not. That would make the black hole problem global instead of
localised.
In my understanding, backing up to v4 when v6 is not fully reliable
doesn't create black holes. It prevents them.
At least where 6to4 qualification is not available yet (and substantial
host modifications don't come overnight), avoiding 6to4 to non-6to4
remains IMHO a good way to avoid people to be disappointed with IPv6
and complain.
Regards,
RD
|