Fred, Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged. Fred Templin wrote: > > Brian E Carpenter wrote: > > > Can somebody draw me a picture? [Emphasis on the word "useful."] > > > > > Brian, > > Attached, please find a rough-cut and incomplete picture. It depicts > two administrative domains (A and B), each with a node that is > engaged in a peer-to-peer session (a.com and b.com). Domain A > uses a native IPv6 prefix space and has delegated a portion of the > space to a (b)router upstream from the node "a.com". Domain B > uses a 6to4 prefix space and has delegated portions of the space > to a hierarchically nested pair of (b)routers upstream from node > "b.com". > > If the DNS entries for 'a.com' and 'b.com' are populated with AAAA > resource records as shown in the picture, one could view the presence > of the ISATAP-format link local addresses Well, I wouldn't expect those AAAA records to be visible outside the originating sites. They would typically be suppressed by a 2-faced DNS setup. I don't think the link local address you have for b.com is correct, anyway. Inside site B, link locals are formed using Ethernet addresses or whatever. The hosts inside a 6to4 site have no knowledge of 6to4. > as an unambiguous > indication that the nodes "support the protocol", I regard it as highly unlikely that site B would contain logic to identify fe80::0200:5efe:0506:0708 as a foreign ISATAP-like address. Site B is running 6to4; why would it have any ISATAP-related code active? > and could use > the ISATAP link-local address as the IPv6 next-hop toward > the final destination. > > The picture shows a stream of packets emanating from a.com towards > b.com (and, similarly, for packets emanating from b.com towards > a.com). These outbound packets would be encapsulated using ISATAP > and it would appear from IPv6's perspective that they are being > "bridged" up to the edge of the remote peer's domain (although there > would still need to be some flavor of NDproxy in operation). Once the > inbound packets hit the edge of the remote peer's domain, the packets > would be decapsulated and steered towards the final destination > within the domain via the delegated IPv6 prefix information. > > The question comes when we consider the inbound packets > arriving at the edge of administrative domain B. Does the edge > node use 6to4 or ISATAP to decapsulate the packets. (And, does > it even matter?) Well, as noted, I don't see any reason that site B would have an ISATAP interface active. It won't know that 3ffe:1::1 is anything unusual. Similarly, site A won't have any 6to4 code active. It won't know that 2002:0506:0708::1 is anything unusual. They will both send as if these are native addresses, and receive in their normal way (native at site A and 6to4 decapsulation at site B). At least that's what I think. Brian
Attachment:
6to4tap.pdf
Description: Adobe PDF document