Pekka Savola wrote: > > On Wed, 26 Mar 2003, Michel Py wrote: > > > Brian E Carpenter > > > That's correct as long as the RFC3056 code is only enabled in > > > the site border router. If it's enabled in any internal routers, > > > the packets will get black holed internally. > > > > I don't think so. They will be blackholed only if the traffic crosses a > > 6to4 tunnel interface, not if the 6to4 address is treated/configured as > > a regular IPv6 address. > > True. (But this was already stated.)
It's exactly what I said: RFC 3056 code is the only code that will blackhole these packets. > > > If the routing table contains IGP or connected > > routes with a mask of /64 as it should be the longest match route will > > prevail over the 2002::/16 route associated with the tunnel interface > > and traffic should flow. > > You're making an assumption that all nodes implementing 6to4 > pseudo-intefarce take part in the IGP to get the more specific 2002:FOO > routes, or the topology is simple enough that there is only one subnet (, > and the site admin expects the default route to do the job). > > I do not believe this is realistically the case for what's being proposed. I'm confused. When one is inside the border at which an RFC 3056 router is placed, 6to4 addresses are exactly like any other native IPv6 address. No host inside that border should have a 6to4 pseudo-interface. > > > If there is no match in the routing table then > > traffic will indeed be blackholed and that's a feature not a bug. > > True. True, but not specific to 6to4 addresses. Again, they are only special in one place: a border router that has RFC 3056 switched on. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
