Subject: (ngtrans) questions about 6to4

From: Paul Francis <[email-masked]>
Date: Thu, 20 Jul 2000 11:29:30 -0700

I'm having a hard time understanding the notion of the "6to4 exterior
routing domain" in the 6to4 document.  In particular, I don't see why
you need it.  Considering that misconfiguration in this area can result
in routing loops, it seems it would be useful to get rid of it if that
is possible.

The thing I can't understand is why a 6to4 router, once it has a path to
a relay, would not simply adopt a native IPv6 prefix from the same
prefix that the relay uses.  It seems to me that once a 6to4 router has
gone through the process of configuration required to know how to reach
a relay (some configured tunnel, for instance), it is for all practical
purposes "directly" connected to the IPv6 world.  Having achieved this
connectivity, why wouldn't it just get an IPv6 native prefix and become
a "full" member of the IPv6 world?  If this were required for all 6to4
routers that had relay connectivity, then you could get rid of the 6to4
exterior routing domain altogether, simplify the 6to4 transition
scenario, and get rid of this nasty routing loop.

Speaking of the routing loop, the 6to4 spec makes it sound like the loop
can come about from the result of a single misconfigured 6to4 router
(i.e., misconfigured to leak 2002::/16 into the 6to4 exterior).  But
presumably the relays are also configured to only accept 2002::/16
routes from other relays.  So the loop would require misconfiguration on
the part of at 2 boxes, not just one.  (If this is not the case, then
you have a serious DoS problem.)  In other words, the loop that can come
from this misconfiguration is no different than the loop (or black hole)
that would result from a standard IPv4 BGP router advertising an IPv4
prefix that it in fact cannot reach.  The defense against this is simply
careful configuration of BGP peers and the prefixes they can validly
advertise...

Finally, one other question just to make sure I understand something
right.  Section 5.2 says that poor route filtering policy for 
advertised by relays into native IPv6 routing can result in potential
unreachability.  Is this simply because a prefix advertised too far will
result in a lot of traffic directed to the prefix resulting in
unreachability due to congestion (as opposed to some actual routing
black hole)?  Also, is this filtering any different qualitatively from
the filtering one might do within IPv4 today to spread traffic to a give
IPv4 prefix among a number of routers that have connectivity to that
prefix in order not to overload any one of them with traffic?

Thanks,

PF

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jul 2000 17:30:07 -0500

Hi Paul,

> in routing loops, it seems it would be useful to get rid of it if that

The reason is that it allows you to exploit the power of BGP4+ policy
to engineer the traffic paths and regions of reachability. If you don't
want to do that, you don't use BGP4+ and the exterior routing domain
is pretty much a no-op.

> prefix that the relay uses.  

Then it would effectively be using a configured tunnel to talk to the
relay, rather than using the implicit tunnel created by the 6to4
address mapping. 

> It seems to me that once a 6to4 router has

I'm not convinced it works in all cases. Being in a hotel room without
a whiteboard, I can't do the analysis. Certainly, there is a degenerate
mode of 6to4 where *all* you get from it is a free IPv6 prefix without
asking a registry, and everything else is bog standard. But I think this
requires manual configuration, whereas the original 6to4 model should
be essentially plug and play.
> careful configuration of BGP peers and the prefixes they can validly

I think I agree. But I was asked to provide a description of potential
routing loops by our respected AD, so I did ;-)
> black hole)?  

No, I think that if you screw up the BGP4+ policy you can have
genuine unreachability. This was hard to illustrate in ASCII art
but I did some PowerPoint pictures once that seemed fairly convincing.

> Also, is this filtering any different qualitatively from

...or to implement ISP peering and transit agreements and the lack thereof.

   Brian

---

From: Paul Francis <[email-masked]>
Date: Fri, 21 Jul 2000 08:34:47 -0700

> relay, rather than using the implicit tunnel created by the 6to4

I don't see how a 6to4 router can talk to a relay without *some* kind of
explicit configuration...either a tunnel, a direct link to the relay, or a
direct link to a router that is in this 6to4 exterior routing domain.

> asking a registry, and everything else is bog standard. But I think this

bog?

> be essentially plug and play.

But this is just my point...I don't see how you can avoid some manual
configuration (if you want to be able to exchange packets with hosts with
native IPv6 prefixes).  Let me go back over my understanding:

Basic 6to4 consists of a 6to4 router with an interface to the IPv4 backbone.
This allows the 6to4 router to forward packets to all other 6to4 routers
with no configuration, because it can pull the forwarding IPv4 address out
of the IPv6 address.  So far so good.

The problem is that the 6to4 router does not know how to forward packets to
routers with native IPv6 addresses *without some additional connectivity or
configuration information*.  Specifically, it has to know how to forward a
packet with a native IPv6 address to some relay.  One way is for it to know
the 6to4 address of the relay's IPv4 interface, which amounts to a
configured tunnel (right?).  Another way is to have another (non-6to4)
interface to connects directly to a relay or to a router in the 6to4
exterior routing domain.  But this is also a form of manual configuration.

So you seem to need some kind of manual configuration.  Assuming this is
right, and getting back to my original point, once you've done this
configuration, why not just get a native IPv6 prefix from the relay?

> routing loops by our respected AD, so I did ;-)

Well, you really need to make the document more clear then.  As it reads
now, it sounds like the routing loop is trivial for a single 6to4 router to
create, and therefore an obvious DoS attack.

> but I did some PowerPoint pictures once that seemed fairly convincing.

Again, is this somehow different from screwing up any BGP4 policy (say, in a
pure native IPv6 environment), or is there something special about the mixed
6to4/native environment?

You need to make all this more clear in the document.  As it now reads, it
gives the impression that qualitatively new routing failure modes are
introduced by 6to4.  But I can't see what those new failure modes are, which
leads me to believe that there are none...just the usual failure modes that
come from mis-configured routing.  But I'm still not sure one way or the
other!

PF

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jul 2000 14:09:32 -0400

> configuration, why not just get a native IPv6 prefix from the relay?

a) we're working on tools for automatic relay discovery, they're just
   not part of the core 6to4 proposal.  but we don't want to preclude
   such tools from existing.

b) getting a native v6 prefix from the relay would presume that the
   6to4 site is always using the same relay.  we'd like to avoid
   this for a variety of reasons.  e.g. at least at first, a relay 
   might well be fairly distant from many of the leaf networks that 
   it serves.  later on, relays might be more common, so it might be
   possible to find a closer one.  since addresses need to be somewhat 
   stable, the use of a prefix borrowed from the relay would discourage
   the creation of more relays (not as much benefit to be derived)
   and encourage the establishment of permanent long tunnels.

   in effect, always getting a native prefix from a relay would defeat 
   topological address assignment.

c) when using 6to4 addresses, traffic between 6to4 sites flows more-or-less
   'optimally' or at least, according to the ISPs routing policies for v4 
   packets.  6to4 is so easy to deploy that we can expect this case to be 
   fairly common.  traffic between 6to4 sites and native sites flows 
   suboptimally if the relays aren't close to the 6to4 sites.  but 
   we're working on ways to help 6to4 sites find relays that are close.

   however, if all sites were to use native prefixes, traffic would
   flow suboptimally in almost all cases, because either the relay
   used by a site would have to be "close' to that site (effectively 
   requiring sites' ISPs to implement native v6 before they use it - 
   the very hurdle we are trying to avoid), or the relays would use 
   long tunnels.  

Keith