Pekka Savola wrote: > However, there are potentially issues with transition mechanisms, > especially those using some form of automatic tunneling (which is one > reason why this, automatic bridging systems etc. may get to be a > headache). Automatic bridging systems are ha headache, and completely orthogonal to IPv6.
> Suppose IPv4/6 router is also a 6to4 router for a subnet, so it must > accept IPv6-in-IPv4 packets from everywhere. This is not a requirement. > Suppose someone sends in a packet with: > > src=1.2.3.4 > dst=<ipv4 of the router> > protocol=41 > src6=fec0::1 (or 3ffe:ffff::1 or whatever) > dst6=ff05::1 (or ff02::1 or whatever) > ... > > With varying levels of different src6/dst6 values. > > It's possible that implementations use a "same-zone" check > with non-global > addresses, but this may or may not be the case. It was my belief that this was discussed in Dave Thaler's ID on multicast over 6to4. It appears that the document expired due to an oversight by the chairs... :( I just talked to Dave and he will resubmit. > This is especially nasty if hosts would listen to ff0e::1 (global > all-hosts) address (even though it would not be globally > routable); there > would not be such restrictions on same zone. According to 2373 your choice of multicast address is reserved to begin with, but why wouldn't that be routable? You appear to have a model for multicast over NBMA that assumes the lower layer is not global. I understand there may be a problem with scaling the number of tunnels, but this is not a protocol problem. > The issues with automatic tunneling are discussed a little bit in: > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4- security-00.txt (by the way, comments would be welcome ;-) Your discussion about a 6to4 host seems to be implementation specific, and there are implementations that do have the host aware of 6to4. Your discussion about what should not happen are already in RFC 3056 security issues. Your discussion of the disallowed addresses is in RFC 3056, specifically the point that RFC 1918 addresses are not valid. I have to go now, but the document seems to be based on some misunderstanding of the existing 6to4 RFC, and the existing address architecture RFC. If those are sufficiently unclear that several people this document is needed to help, we should either revisit the text in those, or move your document to a high priority work item to reduce the confusion. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
