Subject: transit through an OLSR network

From: Sean Doran <[email-masked]>
Date: 20 Mar 2001 04:44:18 +0100

In the WG meeting there was discussion about using an
OLSR-using MANET for transit, rather than as a stub.

Using any multilevel link-state protocol as an IGP in a
transit MANET is fairly straightforward.

Firstly, consider what happens in any transit network,
independent of IGP, EGP and mobility, but dependent upon
traditional routing architecture:

	 - some set of border routers talk an EGP
	   (e.g. BGP4) with external entities

	 - these border routers must use the moral
	   equivalent of the iBGP hack to remain in synch
	   with one another with respect to route
	   selection

	 - non-border routers need to be able to get to
	   one of these border routers for basic
	   connectivity

	 - border routers must have connectivity
           between them, in case a nonborder router gives
           one BR a packet which must exit an interface on
           another

	 - non-border routers may choose never to learn
	   some or any external routes; acquiring external
	   information has the advantage of optimising the
	   choice of border-router, but acquisition has a cost

         - routers that have external routing information
           will typically do a recursive lookup (or
           generate a table with the results of the
           recursive lookup done in advance)

	         - for external address E, we look through
                   the acquired (by iBGP-equivalent)
                   external routing information for an
                   exit-location X.  Then, to find out the
                   actual next-hop towards E, we have to
                   find the actual next-hop towards X
                   within the routing information learned
                   from the IGP

		 - both E and X may be non-specific within
		   their respective routing information
		   abstraction boundary; that is, a
		   specific E may match a very short CIDR
		   prefix with a specific next-hop X. 
		   X may match a shorter CIDR prefix
		   within the IGP.

		   routers with many interfaces need not
		   advertise each interface to the IGP,
		   and should in general try to introduce
		   a prefix covering all the interfaces.
		   aggregation is good

         - conceptually, non-border routers have only the
           least specific prefix (default) as the only E
           that will be matched, resulting in a specific X,
           which is known from the IGP, and which has more
           specific routing information

	 - BRs may be distant from one another in
           terms of hops, which implies one of three
           options:

		- every intermediate router must be fully
                  able to resolve the appropriate X for
		  every E that actually appears in a
                  destination address of a packet arriving
                  on (or originating on) it

		- a virtual link must interconnect
                  separated BRs

All of this is true independent of IGP (static routes to DV to PV to ARP).

In OSPF-speak (which seems to make sense for OLSR, which
triggered the "transit" issue) BRs and non-BRs with full
global knowledge may form an Area 0; non-BRs that do not
have global knowledge need not be in Area 0.

As BRs in a transit MANET separate spatially, the chance
of an IGP reconvergence leading to a topological
separation of BRs increases.  As long as we have a
notional Area 0 that is fully connected and has the
property that all members have global knowledge, routers
in other areas need not have any nonlocal knowledge.

Again, there are two obvious options for BRs separating
spatially:

	- tunneling (easy (if the "outside" is just IP -- forget MPLS)
	             but has overhead in terms of
	             encap/decap processing at the tunnel
	             endpoints, and in terms of the extra
	             bytes in the "outside" header)

        - migrating non-Area 0 routers into Area 0
		    (extra overhead for acquiring and
		    using global knowledge; e.g. the
		    migrating router suddenly has to
		    handle iBGP, and iBGP-done-unicast
		    does not make this easy! (even if you
		    have software that can speak it))

The cheaper approach is the "virtual link" that fixes
partitions of Area 0 by using a tunnel through a different
area.  This, sadly, is one of the more gross parts of
OSPF, and does not exist in IS-IS.  On the other hand, 
an implementation that works well in a MANET is easily
generalizable to partition-repair in non-mobile networks
using LS-protocols.

	Sean.
- --
Sean Doran <[email-masked]>

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 26 Mar 2001 12:01:33 -0800

Sean,

I was involved in some of the discussion regarding MANETs used
for transit. Although the topic arose during the OLSR presentation,
the subject applies to the MANET model in general; not just to
OLSR - would you agree?

I agree with your observation that there would be two basic
types of routers in a MANET that provides transit:

  - Border Routers (BRs) and non-BRs with full global knowledge
     (Area-0 routers)
  - non-BRs that do not have global knowledge (non-Area 0 routers)

I also agree with the premise that these "Area-0" routers
need to stay in touch with each other to maintain consistency.
This could be via some sort of virtual link (as when a fully
connected mesh of iBGP peering sessions are used) or by making
the set of non Area-0 routers NULL. Said another way, the
options are:

  1. Tunnel the exterior routing protocol through the MANET to
     all Area-0 routers in the MANET. (non-Area 0 routers
     need not partake in the global knowledge exchanges)

  2. Redistribute routes learned from the exterior routing
     protocols into the MANET routing protocol, thus pushing
     all MANET routers into Area-0

In a MANET used for transit, it seems to me that the first
order of business should be to get non-local messages OFF
the MANET as early as possible (due to the severe penalties
incurred for multi-hopping through the sorts of radio
networks that typically occur within a MANET.) Therefore,
option 1. above would seem like a poor choice if the number of
non-Area 0 nodes was large. Reason being, these nodes would send
all non-local messages to their "default" Area-0 router, which may
turn around and send it right back through the MANET towards a
"better" Area-0 router for the non-local message. Option 2. has
the disadvantage that the overhead for distributing global knowledge
might be considerable in some cases. But, option 2 would allow a
shortest path off the MANET for non-local traffic. Am I seeing the
picture clearly?

A couple of other points about your message, as it applies to
MANETs:

  1. Regarding the recursive lookups to get to the next hop
     towards X (which is the exit location towards E), in
     current OSs like Linux and FreeBSD I belive the
     recursion stops when a route of the form X->Y is
     encountered such that:

      - the CIDR prefix length for Y in the forwarding table
        is 32
      - Y appears to be "on-link" from the standpoint of one of
        the interfaces attached to the MANET router (in other
        words, Y matches the network prefix assigned to one of
        the MANET router's interfaces

     But, this last condition can be problematic in MANETs in
     which multiple hops through the *same* logical IP subnet
     are required to reach the destination. Said another way,
     a MANET router may have routes of the following form in
     its forwarding table:

           Y(0) -> Y(1)/32
           Y(1) -> Y(2)/32
           Y(2) -> Y(3)/32
           .
           .
           Y(i) -> link-level address

     In other words, only Y(i) is TRULY on-link with respect to
     one of the MANET router's interfaces, but in current OS's the
     recursion bails out too early when multiple hops through the
     same logical IP subnet are required. Is this not an issue for
     the general MANET model if transit configurations are deployed?

  2. The Border routers of a transit MANET need not run a true
     EGP like BGP, correct? Is it not possible that the transit
     MANET would be properly contained within an autonomous
     system (AS), and that the MANET border routers would run a
     traditional IGP like RIP or OSPF? If the BR's in fact run an
     IGP, then would the same business of setting up virtual links
     through the MANET to interconnect the BR's apply? Perhaps a
     better way to ask this is what are the criterion for a transit
     MANET to require its own AS number (ASn)?

Thanks for any additional thoughts on this,

Fred Templin
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 26 Mar 2001 17:39:34 -0800

Hello,

Emerging common practices in many MANET documents seem to advocate
implementation of the multi-hop relay paradigm at the network
layer using IP host routes as opposed to at the data link layer
using MAC addresses. A good argument in favor of this model is
that multiple interfaces are handled gracefully, since the IP
layer provides a generic abstraction for the aggregation of
heterogeneous interfaces. But, the IP model gives rise to an
interesting "twist" on standard Internet routing practices in
MANETs. Namely, if a MANET router has an interface with CIDR
prefix A/n, it is NOT NECESSARILY the case that all active
nodes with prefix A/n are reachable within a single hop.

Instead, multiple hops through the *same* logical IP subnet are
possible in the MANET model. For example, a MANET router with
an interface assigned the CIDR address:
 
  10.0.0.1/24

might have the following entries in its forwarding information
base (FIB):

   10.0.0.2 -> MAC(10.0.0.2)
   10.0.0.3 -> 10.0.0.2/32
   10.0.0.4 -> 10.0.0.2/32
   10.0.0.5 -> MAC(10.0.0.5)
   10.0.0.6 -> 10.0.0.5/32

In this example, nodes 10.0.0.[2,5] would be reachable within a
single hop just as if the nodes shared a common Ethernet link with
10.0.0.1. But, reaching nodes 10.0.0.[3,4,6] would require multiple
hops within the *same* logical IP subnet, and some might argue that
such an arrangement should be handled by data link level bridging
instead of IP-level forwarding. In fact, if multiple hops through
the same logical IP subnet are allowed, some interesting questions
arise:

1) What should be done with messages sent to the limited IP
   broadcast address (255.255.255.255) from the 10.0.0.1
   interface? Given the above FIB entries, some might say that
   such messages should only reach nodes 10.0.0.[2,5] since
   RFC 1812 says that limited IP broadcasts (aka "all-1's
   broadcasts") should NEVER be forwarded. But, others might
   say: "Wait a second; MANY service discovery protocols REQUIRE
   that messages sent to the all-1's broadcast address be extended
   to all nodes that share the same CIDR prefix as the sender."
   After all, this is the way it would work if the MANET were
   implemented using a datalink-level bridging approach, since
   MAC-level bridging spans all-1's broadcasts across the entire
   logical IP subnet even if multiple hops across bridges are
   required.

2) If your answer to the above is:  "All 1's broadcasts must reach
   all nodes in the logical IP subnet", *another* interesting
   question is what should be done with the 'TTL' field in the
   IP header when broadcasts are so multi-hopped? RFC 1812 says
   that the TTL field should be decremented by 1 for every
   forwarding hop. But, since most service discovery protocols
   expect that the all-1's broadcast address will reach all
   nodes with the same CIDR prefix with no IP forwarding hops,
   decrementing the TTL would seem to break this expectation.

3) Same two questions as 1) and 2) for the low-numbered IP
   multicast addresses (224.0.0.0 thru 224.0.0.255). The IANA
   Assigned Numbers document for Internet Multicast Addresses
   says:

     "The range of addresses between 224.0.0.0 and 224.0.0.255,
     inclusive, is reserved for the use of routing protocols and
     other low-level topology discovery or maintenance protocols,
     such as gateway discovery and group membership reporting.
     Multicast routers should not forward any multicast datagram
     with destination addresses in this range, regardless of its
     TTL."

   So, this legislation would seem to present the same set of
   challenges described in 1) and 2).

4) If the low-numbered IP multicasts should be multi-hopped to
   all nodes in the logical IP subnet, this presents a challenge
   to the MANET routing protocols themselves. For instance, some
   MANET routing protocols may wish to send neighbor discovery
   messages that are heard by ONLY their single hop neighbors;
   *not* nodes that are multiple hops away. If a decision is
   made to allow multi-hopping for the low-numbered IP multicast,
   then one or more low-numbered IP multicasts should first be
   reserved with the stipulation that they NEVER be multi-hopped
   beyond a node's single-hop neighbors. 

5) Not related to the "multiple hops through the same logical
   IP subnet" issue, but if the MANET multi-hop paradigm is
   implemented at the IP layer, how should non-IP protocols be
   handled? e.g. in a bridged Ethernet environment, native IPX
   and AppleTalk messages would span the entire network thus
   reaching every node. But, in a MANET, such non-IP messages
   would only reach single-hop neighbors since multi-hopping is
   done at the IP layer. One possible answer is to tunnel the
   non-IP messages through IP, but a new standard for such
   automatic tunneling would be necessary.

My take on the above questions is that implementing the MANET
paradigm such that multiple hops through the same logical IP
subnet may occur is *not* the same thing as IP forwarding in
its traditional sense, since true IP forwarding occurs between
*distinct* logical IP subnets. Instead, the MANET paradigm is an
interesting variant that lives within the gray area between true
IP forwarding and data link level bridging. (I prefer to call it
"RELAYING" instead of "forwarding" or "bridging".) As such, I
believe MANET as a group needs to take a stand on the above
questions (among others) to define just how things should work in
a MANET environment. Whatever decisions are made should perhaps
trickle back into the appropriate IETF documents on router
requirments; at the very least, perhaps a MANET-specific
document should exist that tells how things work.

Comments?

Fred Templin
[email-masked]

---

From: Kevin Grace <[email-masked]>
Date: Fri, 30 Mar 2001 09:06:21 -0500

In the traditional wired world, the raison d'etre for IP subnets is to
enable route aggregation. Rather than having routes to a bunch of IP
interfaces which are all connected to the same media, a single network
route suffices; a big win for reducing the size of forwarding tables
as well as the amount of information exchanged by routing protocols.

But, the underlying requirement is that all IP interfaces for a subnet
appear to be directly reachable from each other (ie. appear to IP to
be one hop neighbors). If this requirement does not hold, then the use
of subnets is not possible and it appears likely that MANET's will not
meet this requirement. It's probably wise to assume that subnet
addressing can not be used within a MANET cloud and that routes to
MANET interfaces will need to be host routes (ie. netmask =
255.255.255.255).

Kevin

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 30 Mar 2001 08:59:53 -0800

Kevin,

Then, from what you are saying, it should be OK for nodes with
addresses which come from what appear to be *different* logical
IPv4 subnets to join together and form a MANET, right? So, for
example, if three nodes (each having a single IEEE 802.11 interface)
come into close proximity with one another and their addresses
are:

    140.173.1.55
    128.18.1.2
    10.2.3.4

then they should be able to form a MANET by establishing host
routes to one another - right? Or, would you require that some
sort of address renumbering occur? (If so, how do you decide
who renumbers and to what common IPv4 prefix?)

If it's OK for nodes from disparate IPv4 network prefixes to
form a MANET, what would this do to the broadcast/multicast
questions? It seems like the expectations for broadcast/multicast
on traditional logical IPv4 subnets would no longer apply. But,
where would this leave service discovery protocols (such as DHCP)
for such heterogeneous MANETs?

Also, if it turned out that one of the nodes has a *second*
interface - perhaps an Ethernet interface that touches down on
the hardwired Internet - you would ideally like to allow the MANET
to form a stub netork reachable from the rest of the Internet. But,
what kind of routing info could you advertise out of such a MANET
to provide reachability information for all of the nodes?

Anyway, I'm not trying to disqualify your comments here; your
viewpoint is certainly one way to look at the MANET picture. In
terms of MANET convergence, I see flexibility in what you are
proposing. But, in terms of providing a full-service network I
see limitations.

Thanks,

Fred Templin
[email-masked]

---

From: Kevin Grace <[email-masked]>
Date: Fri, 30 Mar 2001 13:59:53 -0500

"Fred L. Templin" wrote:
> IPv4 subnets to join together and form a MANET, right? 

It doesn't appear to me that subnets in the traditional sense will
exist in a MANET. We may have a bunch of interfaces whose addresses
come from the same block of address space, but to call them a subnet
is misleading.

> So, for
> routes to one another - right? 

Correct.

> Or, would you require that some
> sort of address renumbering occur? 

Don't think renumbering is required nor desirable.

> on traditional logical IPv4 subnets would no longer apply.

Again, I don't see that MANET interfaces will reside on traditional
subnets. If you find it hard to let go of the term subnet then
assuming that every subnet has exactly one address may be
helpful. Then the expectations for broadcast are: 255.255.255.255 is
received by all directly connected interfaces and is not forwarded by
IP and since there are no subnets ( or all subnets have exactly one
address ) then subnet broadcasts on MANET interfaces are meaningless.

> But,

The MANET interfaces will be router interfaces...DHCP is for host
interfaces. But, if you are concerned about hosts connected to a MANET
router, certainly the MANET router can "own" some addresses and
dynamically lease them to its hosts via DHCP. 

> to provide reachability information for all of the nodes?

It depends. If all you care about is letting MANET nodes get access to
the outside world, then all you need is for the box with the wired
interface ( let's call this the border router) to advertise a default
route into the MANET. You can do this with MobileMesh...see:
http://www.mitre.org/tech_transfer/mobilemesh for details. The border
router can perform NAT so that the MANET addresses can come from any
address space including the private spaces like 192.168.X.X.

If instead, you also want to enable hosts outside the MANET to
initiate contact with servers within the MANET, then you will need
those server addresses to be well known and advertise routes to them
using the "wired" routing protocol running on the border router's
wired interface.

Kevin

---

From: "Phil Neumiller" <[email-masked]>
Date: Fri, 30 Mar 2001 15:19:38 -0600

This may seem like an incredibly naive question and it may have
been shot to pieces before, but should MANET's have their own
IP address space?  At least in IPv6 the flow label field could be
put to some different uses since MANETs will be "living on the
edge" anyway.

Thanks,

Phil

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 30 Mar 2001 14:43:35 -0800

Kevin,

> come from the same block of address space, but to call them a subnet

I think there are a number of different viewpoints of how a MANET
will be organized. Yours is certainly one possibility, but it's
not clear that it is the best choice for all cases.
 
> address ) then subnet broadcasts on MANET interfaces are meaningless.

If you allow each node in the MANET to act as if it is a subnet
unto itself with a /32 netmask, then a node's MANET interface
will appear to have a one-to-many connection with other networks,
whereas in existing host and router implementations there is a
one-to-one assumption. So, an all-1's broadcast sent from a MANET
router's interface would be delivered to MANY networks instead
of just one.

Normally, the smallest CIDR prefix used for Internet interfaces
is /30 (for use on endpoints of a point-to-point link) but recent
IETF works have suggested the possibility of using a /31 prefix
(see RFC 3021, which seems to provide good discussion regarding
this subject.) As to using a /32 prefix, RFC 3021 says:

  A third option is to use host addresses on both ends of a point-to-
  point link.  This option provides the same address space savings as
  using a 31-bit subnet mask, but may only be used in links using PPP
  encapsulation [RFC1332].  The use of host addresses allows for the
  assignment of IP addresses belonging to different networks at each
  side of the link, causing link and network management not to be
  straight forward.

Anyway, I'm not saying that the approach you are suggesting is
invalid; I'm just saying that it bends the existing rules for
host and router implementations. It seems to me that some rules
will have to be bent in order for MANETs to play in the global
Internet. But, I think we need to look at the "pain vs. gain"
tradeoffs for the various alternatives.  

> dynamically lease them to its hosts via DHCP.

DHCP is actually not the best example. A better example would
be Mobile IP Agent Advertisement and Agent Solicitation messages.
If a node from a foreign network joins a MANET of the form you
are describing, grafting onto the network should be straightforward.
But, service discovery for a Mobile IP foreign agent - coupled with
communications back to the home agent - seems challenging.

> address space including the private spaces like 192.168.X.X.

I agree with your conclusion that NAT will be required if you
want to connect a MANET which has no notion of a common "subnet"
as a stub network to the global Internet. Using NAT is an
unfortunate consequence of the design, because all you have really
done is pushed the subnet abstraction up one level to the hardwired
network. There *still* needs to be some notion of an aggregatable
subnet prefix at some level if you want to connect the MANET to
the global Internet.  

> using the "wired" routing protocol running on the border router's

What if you wanted to use the MANET as a transit network that
resides somewhere within the global Internet routing infrastructure?
Then, there would be two or more border routers that connect the
MANET to the global Internet; all of which should advertise the
same server addresses out their wired interfaces. This means that
the border routers would need to be carefully synchronized to do
the same NAT translation for service requests tht come in from the
outside. Not saying that this can't be done, but it seems like
an unfortunate network administration headache.

Just a general observation: your view seems to advocate the notion
that MANET routers are true internet routers in the traditional
sense. In order to support this view, you seem to advocate relaxing
the traditional notion of aggregatable IP subnets. My view is that
the MANET should look just like a connected Ethernet segment; every
node on the network uses the same logical IP subnet prefix but there
may be multiple hops through the same logical IP subnet required to
reach some nodes. In order to support this view, I advocate relaxing
the notion that MANET routers are "routers" in the traditional sense.
Instead, they do something that is not quite routing and not quite
bridging but something in between. Perhaps the truth lies somewhere
in the middle of these two viewpoints -  or perhaps there is no one
universal truth?

Thanks for the additional thoughts,

Fred Templin
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 30 Mar 2001 15:09:19 -0800

Phil,

I think it's a good question, but I don't think MANETs will
always necessarily live on the edge. In some cases, a MANET
may be the only alternative for transit between disconnected
portions of a larger network.

Fred Templin
[email-masked]

---

From: Kevin Grace <[email-masked]>
Date: Sat, 31 Mar 2001 00:27:14 -0500

"Fred L. Templin" wrote:
> My view is that
> bridging but something in between. 

Forwarding packets below the IP layer in an attempt to hide the fact
that not all interfaces on a subnet are directly connected will create
problems when the subnet becomes partitioned. No longer will it be
true that the subnet interfaces can be reached via a single network
route, though this was the original goal of utilizing subnets.

Just because the subnet is partitioned by a lack of connectivity below
IP does not mean that the MANET is necessarily partitioned. Yet the
attempt to try to hide the topology of the subnet from IP precludes
the possibility of healing the partition by leveraging connectivity at
the IP layer (unless the thingy below IP provides reachability
information, but, this would require IP to use host routes so then
there'd be little reason to do subnets since route aggregation will
not be realized). Had all forwarding been done at the IP layer, there
would not be this accidental partitioning.

It does not appear to me that subnets are appropriate for MANET's. And
if the purpose of doing forwarding below IP is solely to support
subnets, then I don't see a need to forward below IP.

I hope I have not offended anyone with these comments...these are just
my humble opinions...

Kevin

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 31 Mar 2001 00:37:10 -0800

Hello Fred and Kevin,

> > bridging but something in between.

It seems to me that manet nodes have links, and that using manet
routing protocols we can join those links into routing paths between
nodes that are not directly connected.  That sounds a lot like
internetworking to me, even if we don't have aggregation.  In fact,
when aggregation is available, it can be fit into manet routing just
by handling prefixes instead of full-length IP addresses (which are
the aggregations of one node, described by a /32 prefix).
We have had this feature in AODV for quite a while; for
simplicity, we require a designated router to handle RREPs
for every node in the aggregate (when the prefix is shorter
than /32).

If you allow the natural model of (often) singleton nodes
with links between them, then I don't see why a mobile ad hoc
network node shouldn't be viewed as a router.  TTL should
be decremented across every hop.  What are the advantages
of considering the whole (inter-)network to be a subnet?

> > > > routes to one another - right?

This certainly matches my understanding of things.

> > > address ) then subnet broadcasts on MANET interfaces are meaningless.

I'd be just as happy if 255.255.255.255 were forwarded to all manet nodes.
Either that, or maybe we should change AODV so that some sort of
"all-nodes-multicast" address should be used for propagating RREQ
messages.

> > router's interface would be delivered to MANY networks instead

 But this just reflects reality.  Many assumptions about the way nodes
sit on networks are changing with wireless and mobility, and this looks
like another thing that naturally should change.

> > tradeoffs for the various alternatives.

Agreed, and I think that typically the tradeoff is best if we can
identify and conform to natural models of operation.  Here,
recognizing the natural differences between wireless and Ethernet
could easily lead to the conclusion that indeed wireless links
DO enable one-hop connectivity to multiple different subnets.

> > subnet prefix at some level if you want to connect the MANET to

But NAT _is not_ required.  One could (probably much better) run
Mobile IP from interior nodes through border routers, when the latter
act as foreign agents.  NAT involves too many bad tradeoffs to be
seriously considered here -- I think that nodes behind NATs are
automatically consigned to being second-class citizens.  That's great
for users who don't care, but it shouldn't be our first choice since that
would constrain ALL manet users to be second-class citizens.

> > an unfortunate network administration headache.

It should also be possible to do "normal" route advertisement by the
border routers, if they know about the routing prefixes that should be
advertised to indicate connectivity to the "other side" of the manet.
Doesn't this conform to the natural model of route advertisement?
We have some specification for this in the AODV Internet Draft,
but it needs to be checked out better to make sure it really works.

> > in the middle of these two viewpoints -  or perhaps there is no one

The truth is that wired network links have a much more restricted
kind of connectivity than wireless network links do.  We should try
to remodel subnet (including /32) connectivity in order to find the
most natural way to fit into the IP internetworking scheme.

Regards,
Charlie P.

---

From: "Phil Neumiller" <[email-masked]>
Date: Sat, 31 Mar 2001 04:08:56 -0600

Fred,

At the slight risk of getting off on a rant, at least with IPv6's
implict tunnelling capability (as used in MIP), you could tunnel
directly over/through these MANET private IPv6 address space
bubbles right?    So even if MANETS float about on the edge
or Interconnect portions of the global Internet they could in
theory work the same with these private IPv6 address spaces
while tunnelling other traffic over/through them.

Thanks,

Phil
----- Original Message ----- 
From: "Fred L. Templin" <[email-masked]>