Subject: Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Apr 2004 16:07:55 +0200

Fred Templin wrote:

> Karen,
>  
> OK, if you must know it then I believe it is possible to run both 6to4 and
> ISATAP from a single interface. Let's say a node wants to send a packet
> to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
> is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
> for the moment that 192.1.2.3 is non-global and used only as example).
> If the node has, e.g., a route in its routing table such as:
>  
>    2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
>  
> then the packet will go out the isatap0 interface using ISATAP encapsulation
> based on the link-local ISATAP address from the routing table as the next-hop
> toward the 6to4 router, and the 6to4 router will be unable to tell whether the
> encapsulator used 6to4 or ISATAP.

Well, I've read this and the followups, and I am still confused.

The intended domain of utilisation of 6to4 is for giving sites that don't
have an IPv6 SP a backdoor into the IPv6 world (and a free /48 to go with it).
[In the degenerate case, the site is a single host connected to an IPv4 SP.]

As I understand it, the intended domain of utilisation of ISATAP is
to provide internal connectivity within a site that has an IPv6 SP but
doesn't have a dual stack internal network.

That being so, I just can't see a useful scenario where what Fred describes
can happen. Can somebody draw me a picture? [Emphasis on the word "useful."]

   Brian

>  
> In other words, if we view each 6to4 router as also an ISATAP router with a
> link-local address on the "site" that includes the global IPv4 Internet, then it
> really makes no difference whether we use a 6to4 interface or an ISATAP
> interface for sending the packet.
>  
> In terms of receiving packets, if we view every global IPv4 address as a
> "Potential Router", then the ISATAP decapsulation checks amount to
> exactly the same (optional) checks suggested for 6to4 and, again, either
> interface could be used to receive the packet with no differences.
>  
> The difference comes when operational deployments will begin to use
> non-6to4 global IPv6 prefixes, in which case sending nodes will need to,
> e.g., add routes such as:
>  
>    3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0)
>  
> Then, the ISATAP router at 192.1.2.3 will appear the same as
> if it were a 6to4 relay router that relays from the 6to4 domain to the
> 3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use
> the DNS to discover the IPv6 prefix to global IPv4 address mappings for
> destinations of interest, and so there really would be no need for running
> a BGP-style routing protocol between the ISATAP routers (that are really
> acting as 6to4 relay router equivalents). In this case, however, the only
> choice would be to use an ISATAP interface, since 6to4 interfaces only
> encapsulate packets sent to a 2002:EXAMPLE::48 prefix.
>  
> So, I guess that would make the ISATAP interface as the LCD that
> needs to be there in any case, and configuring a 6to4 interface also
> on the same node (and over the same IPv4 address) could be viewed
> as optional. This is not by way of saying that ISATAP is in any way
> obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can
> be consolidated into a single automatic tunnel interface footprint
> (instead of two) if desired.
>  
> Fred

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

---

From: Fred Templin <[email-masked]>
Date: Thu, 01 Apr 2004 16:01:12 -0800

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 as an unambiguous
indication that the nodes "support the protocol", 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?)

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Apr 2004 10:42:47 +0200

Fred,

Thanks. I've PDF'ed the picture in case anyone here is PPT-challenged.

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

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 13 Apr 2004 13:34:17 -0700

Hello Brian,

>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
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2004 19:16:52 +0200

Fred,

>   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

---

From: Fred Templin <[email-masked]>
Date: Fri, 16 Apr 2004 09:50:45 -0700

Hi Brian,

The subject that got this thread started (when to use ISATAP vs.
6to4 when both are configured over the same IPv4 address) seems
to have reached conclusions under a related thread on the list. I'm
tempted to ask what you mean by "(mathematically) coincidental"
below, but  perhaps it's better to let the 30k+ foot viewpoint
discussion rest for now.

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 16 Apr 2004 17:21:59 -0700

Hello,

A new draft of the above name has been submitted to the
I-D registrar and is also available for early review to:

      www.geocities.com/osprey67/isatap/iemmei-00.txt
    
The purpose of this submission is to provide informational
and/or Best Current Practices input to the community. The
author requests that this document be adopted as a v6ops
wg document. The abstract appears below: 

Fred L. Templin
[email-masked]

--- cut here ---

Abstract

   The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
   IPv6 hosts/routers over IPv4 networks via automatic tunneling using a
   link abstraction similar to the Non-Broadcast, Multiple Access (NBMA)
   model. This document describes operational extensions for ISATAP that
   enable a dynamic tunnel interface management abstraction similar to
   the ATM Permanent/Switched Virtual Circuit model. Nodes can use these
   extensions to realize mobility, multihoming and efficiency
   improvements not available via the ISATAP base specification alone

---

From: Fred Templin <[email-masked]>
Date: Fri, 16 Apr 2004 17:21:43 -0700

Hello,

A new version of the ISATAP specification (isatap-21) has
been submitted to the I-D registrar and is also available
for early review at:

      www.geocities.com/osprey67/isatap/isatap-21.txt
    
The purpose of the -21 version is to satisfy the clear requirement 
for documenting the widely-deployed implementations. We request that
the -21 version now be adopted as a v6ops wg document.

Fred L. Templin (for the ISATAP co-authors)
[email-masked]