Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09 .txt] ]

[Brian E Carpenter <brc@zurich.ibm.com>]

Fred,

>   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.

Well, Gurusprasad among others have proposed ideas along these
lines in the past. However, that isn't how the Internet works today;
the naming structure and the addressing structure and the routing
structure are not congruent. IPv6 has some degree of congruence
between the addressing and routing structures, but any congruence
with the naming structure is (mathematically) coincidental.

   Brian

Fred Templin wrote:
> 
> 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
> >

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM