Subject: (ngtrans) two ideas for tunnel discovery

From: Keith Moore <[email-masked]>
Date: Thu, 14 Oct 1999 16:26:14 -0400

folks,

In looking for better ways to utilize the existing v4 network
as a substrate for deployment of IPv6, I am examining a couple
of approaches which don't seem to be covered by any of the
existing ngtrans internet-drafts.  these are:

1. define a new DNS RR, to be used in the ip6.int space,  
   to advertise an IPv4 tunnel endpoint associated with
   a particular IPv6 address (or a block of IPv6 addresses).  
   such RRs could be returned either by explicit query, or 
   as additional information in DNS responses which included 
   AAAA or A6 records.  IPv6 hosts lacking connectivity to a 
   native v6 network could use the DNS information to automatically 
   construct a tunnel to an arbitrary IPv6 destination, as long 
   as there were a decapsulating router associated with that destination
   and advertised in DNS.

   as I imagine it this would look like:

   <ipv6-address>.ip6.int	TE	<v6-prefix-length> <ipv4-address>

   (ipv6-address could perhaps be wildcarded; TE stands for "tunnel endpoint")

   depending on the api, with clever implementation it looks like the 
   connection setup delay that might result from extra DNS queries
   could often be avoided...i.e. the server DNS software would include
   TE records in responses that contained A6 or AAAA records, the host 
   DNS software would cache any TE records returned as additional 
   information in the response to an application's DNS query, and use
   the cache information (much like an arp cache) in 
   automatically constructing tunnels for outgoing v6 packets
   to those destinations with cached TE records.

   or in a border box the same kind of result could be obtained using
   DNS snooping (unlike DNS ALG, there would be no need to modify the 
   responses in transit)

   there are some security issues involved...in particular you don't
   want to believe a TE record unless it comes from a server known
   to be authoritative for that chunk of v6 space, or unless it is
   signed by a known and trusted party.  so you might end up doing
   the explicit TE query on <ipv6-address>.ip6.int anyway, or maybe
   this will serve as an incentive to deploy DNSSEC.  on the
   other hand if your api is such that you specify a dns name rather
   than an IP address when connecting to a remote host,  that api
   could probably safely trust the TE records returned as additional
   information (for the purpose of that connection only) as long as
   those TE records were not trusted for other connections.

2. using BGP4's MP_REACH_NLRI attribute to associate 
   an IPv4 tunnel endpoint with an IPv6 prefix.  this could 
   then be used by v4/v6 border routers to tunnel v6 packets
   over the v4 network to a border router associated with
   the destination address.

   security issues are different here than in the DNS case,
   but the same security issues exist for any use of BGP.

   (I'm not nearly as familiar with BGP as I am with DNS,
   so I'm not so qualified to talk about the BGP limitations
   or the specifics of how this would be used.  The idea for BGP
   was suggested to me by someone else who might or might not want 
   his name to be associated with this, but will certainly
   be acknowldeged my me if he wishes :)

a few constraints and notes:

both of these should be used only for "real" ipv6 addresses
assigned to networks that are connected to the IPv6 Internet.
the address blocks advertised through DNS and NLRI have to be 
the same address blocks assigned to the site.  neither of these 
proposals provides an excuse to allocate IPv6 address space
in advance of being natively connected to the IPv6 internet.  
6to4 addresses would still be used by those who are not connected 
natively.

#1 is for hosts or low-bandwidth small-scale border routers on the periphery
#2 is obviously for routers with BGP feeds.
when both are available for a destination, #2 should have precedence 
over #1, and native IP routing should have precedence over either #1 or #2.

the way I see this shaping up, a border box could support
NAT-PT, 6to4, and either or both of TE or NLRI.   assuming that
all v6 sites would include these records in DNS (if they wanted
to be reachable), this combination would allow the border box to provide 
end-to-end v6 connectivity to any other v6 host in the world.
if it works, this gets rid of the "dead end" by providing a clean
transition path from 6to4 to native v6.

two questions:

are there obvious showstoppers that cannot be overcome?
(as opposed to technical difficulties that would need further investigation)

are any BGP or DNS experts willing to help draft concrete proposals?

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Oct 1999 17:06:03 -0700 (PDT)

>    over the v4 network to a border router associated with

I think we need to explore using BGP to solve the problem.

But it isn't clear to me that we really want tunnel information
for the destination address - particularely since I don't think
that will work for multicast. (Please correct me if I'm wrong and I'll shut
up.)

But if we could get BGP to pass around (and filtered by policy) possible
tunnel endpoints then the site border routers could select (based on
whatever "metric" BGP provides) a set of "close" tunnel endpoints.

Once that is done the border router needs to establish an IPv6 peering
with the tunnel endpoint(s) and start exchanging IPv6 routing information
over the tunnel.
If we do this we can get both unicast and multicast to work.

The difficult part is that anybody who announces themselves as a tunnel
endpoint needs to somehow be able to reach all of IPv6. If not it becomes
too hard for the border routers to select a finite set of tunnel endpoints.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Oct 1999 17:23:10 -0700 (PDT)

>    as there were a decapsulating router associated with that destination

If the IPv6 host lives in an IPv6-only cloud (with no IPv4 routing - and it
has no IPv4 source address) it clearly can't tunnel the packet itself.
Thus the encapsulating must be done by some special router in the path.

Having a router look for DNS records to determine how to forward a packet
has some problems. Suppose the packet the host is sending is to the IPv6 DNS 
server in the remote site. This will cause the special router to do a DNS
lookup perhaps finding a name server which does not have any IPv4 addresses 
thus it needs to talk to it using IPv6. Seems recursive.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 21:02:51 -0400

Keith,

This is a great idea.  Would be very valuable to transition too.
We could use this for DSTM via AIIH immediately too.

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 21:44:32 -0400

>that will work for multicast. (Please correct me if I'm wrong and I'll shut

Because something for a "temporary" transition mechanism does not work
with multicast but only unicast is not a reason to not use it or have it
for IPv6 customers.  But you could send a packet to a tunnel endpoint that
then is the point where the multicast packet explodes.  I can think of
ways where responses could be tunneled back from multiple receivers if
anyone wanted to do such dangerous things.

I can think of many IPv6 customers that will never run multicast other
than for ND, Addrconf, or DHCPv6.

I agree if we were building an Ipv6 feature that did not support
multicast that would be taboo.  But not for transition solutions.

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 21:48:03 -0400

>Thus the encapsulating must be done by some special router in the path.

Use DSTM dti interface.

>thus it needs to talk to it using IPv6. Seems recursive.

These are special routers to get transition going.
Most likely UNIX servers that will do the job.

/jim

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Oct 1999 20:01:01 -0700

> whatever "metric" BGP provides) a set of "close" tunnel endpoints.

this is comprehensible to providers.  and feels loop-free.

> If we do this we can get both unicast and multicast to work.

not really.  but at least you won't have made multcast any more unworkable.

randy

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Oct 1999 00:39:52 -0700 (PDT)

> for IPv6 customers.  

Yes, but there are different degrees of temporary.
I don't have a problem with e.g. automatic tunneling not supporting multicast
since I don't think it will be widely used.
But here we are discussing something that would make it possible to
do global IPv6 without requiring a complete ISP IPv6 infrastructure.
If this is successful then "temporary" could be more than 5 to 10 years.

  Erik

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Oct 1999 08:21:48 -0400

>If this is successful then "temporary" could be more than 5 to 10 years.

Thats a good point.  If its 5 to 10 years that is not temporary.  I
agree.

I view 6to4 as a coexistence tool not a way to deploy IPv6. The way to
deploy IPv6 is to use native IPv6.

I need to go look at 6to4 in that light.

I am a bit concerned about the draft too.  We have had a lot of input in
the last few days and I would like to understand where we are.  I am not
clear we need a complex yet another src address selection scheme.

If it gets too complex with too many changes for the host node that is
just using IPv6 I will withdraw my support of this proposal as far as a
thing to implement now.

/jim

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 13:56:16 -0400

> Thus the encapsulating must be done by some special router in the path.

Sorry, I tried to make this clear.

ONLY those nets which are natively connected to the global IPv6 Internet
should advertise tunnel endpoint addresses through BGP or DNS.  So for 
any packet sourced by a host in an IPv6-connected world (including the 
IPv6-only world), the packets are routed directly to the destination and
tunnels aren't used.   The tunnels are only for packets sourced by 
hosts and nets which have IPv4 connectivity but do not have connectivity
to the global IPv6 network.

> thus it needs to talk to it using IPv6. Seems recursive.

good point.  any net that wants v4-connected v6 hosts to be able to talk to
it would probably have to provide v4-access to its DNS servers.  I think 
this is easily accomplished by getting someone with v4 connectivity (perhaps 
your ISP) to be a secondary.  I don't see this as a huge limitation
but it's certainly worth pointing out in the specification.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 14:17:24 -0400

> that will work for multicast. (Please correct me if I'm wrong and 
> I'll shut up.)

Obviously, multicast needs a different kind of solution.   Either you 
build an IPv6-over-IPv4 mbone (where the links are configured tunnels), 
or you figure out some way to dynamically map between (temporary or 
site-local) IPv4 multicast addresses and IPv6 multicast addresses.  Both
approaches seem doable, but fairly ugly.  

My view is basically the following:

- traditional IP multicast is in flux anyway.  the current model
  doesn't efficiently do what is wanted, and is difficult to justify
  economically.  it's likely to be replaced/supplanted by something new.
  anything we design for v6-over-v4 before this is done is likely to
  be rendered obsolete.  better we get the multicast guys to think
  about v6 and v6-over-v4 in their planning, than to try to anticipate
  a solution in ngtrans.
  
- IPv4 multicast is not widely enough deployed to be used as an
  effective substrate for any IPv6-over-v4 multicast scheme.

- folks who want to create v6-over-v4 mbone are free to do so,
  but I would expect considerably less interest than has been shown
  for the v4 mbone.

- we don't need to be trying to push this particular rock up the hill.

> endpoint needs to somehow be able to reach all of IPv6.

I don't see why this is the case; in fact, just the opposite.  the tunnel
endpoint certainly doesn't want to accept traffic for non-customer sites.
it just has to be able to reach the portion of IPv6 served by the
tunnel endpoint's customers.   of course, hosts on the v6 nets served
by those tunnels will still need global v6 reachability.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Oct 1999 14:50:30 -0700 (PDT)

> to the global IPv6 network.

I missed your implicit assumption that the native IPv6 world is well-connected.
 I think there are scenarious where this is not the case.
For instance, large clouds could deploy IPv6 internally for various reasons
(e.g. address space if the cloud contains lots of mobile phones etc).
This might be benefitial internally even if the cloud is not connected to
the rest of the native IPv6 Internet.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Oct 1999 20:04:08 -0400

> (e.g. address space if the cloud contains lots of mobile phones etc).

I think such clouds could use 6to4.  (if they're not connected to the
global v6 Internet, how did they get addresses assigned to them?)
but I agree that the "fragement v6 world" case is worth further
consideration.

Keith