Hello Brian,
Brian E Carpenter wrote:
Fred,
Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.
PDF is fine for me; thanks. If it's OK with you, I'd rather not
try to tackle all of the points from your message below in one
fell swoop, but rather see if we can establish things through
an iterative dialogue.
The first aspect I would like to call to attention is the "Admin.
Domain B" portion of the PDF figure. Note that we see what
appear to be nested sub-domains within a parent domain. This
might present something of a challenge to the traditional notion
of what constitutes a "site", in that sites need not be viewed as
disjoint. Rather, sites can be seen as recursively nested one within
another. Moreover, it seems to me that such recursive nesting of
sites can extend outwards or inwards from a given point as far
as one would like (within practical limitations, that is).
In comparison to the natural order of things, such a view
makes perfect sense:
- our universe is a "site" for which all known entities are
a member (it's probably best to leave the discussion of
parallel universes aside for now...).
- the universe comprises a number of galaxies; each of which
is an autonomous "site" unto itself, yet a sibling of others.
- each galaxy comprises a number of stars/solar systems that
are, again, autonomous "sites" yet siblings to others.
- each star/solar system (presumably) comprises a number
of planets/planetiods that are, again...
and so on, until the desired degree of granularity is reached.
Now, if we could rig a ubiquitous naming system to match up
with this natural order, we could assign a ".universe" TLD to
the center of mass of the universe and recursively assign
sub-domains going outward. For example (neglecting for
now finer granularities) I could be reached via this naming
system at:
fredtemplin.california.usa.earth.sun.milkyway.universe
More relative to the subject topic of this thread, we can consider
each node "xyz.foo.bar.com" in the Internet as a site unto itself,
and consider its default router as the "center of mass" for its parent
site "foo.bar.com". But then, this default router is yet again
(the head of) a site unto itself with its *own* default router as
the center of mass for *its* parent site "bar.com". If we allow
each such default router to delegate the addressing scheme for its
constituents, then we have a way of tying addresses with sites
that matches the natural order of things.
As the main point of this note, if we further equate the term
"site" with the term "domainname", we have a way of tying
addresses to domainnames that matches the natural order of
things in such a way that we have a ready-made, natural
routing engine in the form of the global DNS.
As I said, I'd like to take this discussion in iterative fashion,
so I'll stop here for now and await comments. What I've said
so far might appear as obvious and/or off-topic to a portion
of this list readership, but I'm hoping that the relation to the
6to4/ISATAP/etc discussion will become more evident as
we drill down into details from this 30k+ foot vantage point.
Thanks - Fred
ftemplin@iprg.nokia.com
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