Subject: RE: (ngtrans) questions about 6to4

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Jul 2000 12:09:20 -0700

> -----Original Message-----
> From: Paul Francis [mailto:[email-masked]]
> Sent: Friday, July 21, 2000 8:35 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: RE: (ngtrans) questions about 6to4
> 
> >
> > 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.
> 
> 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.
> 

Whenever it finally pops out look at
http://www.ietf.org/internet-drafts/draft-hain-6to4-scaling-00.txt

> >
> > 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
> 
> bog?
> 
> > requires manual configuration, whereas the original 6to4 
> model should
> > 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?
> 
> 

This is another artifact of the point I will be talking about in
Pittsburgh; The IPv4 Internet is simply an NBMA link from the
perspective of 6to4 nodes. Given that it is a link, all that is needed
is an ARP mechanism (manual config is one solution to that) to find
other nodes.  The basic premise of 6to4 is that on-link ARP is built-in,
so the only problem is finding the routers (relays) that attach to the
off-link (native) networks. Once the routers are known, all
non-multicast link-layer functions MUST be applicable (including
redirect). This points out a basic problem with 2461 in that it assumes
a node will always want a single default route to get off-link, and that
the media is always multicast capable. Neither of those is true for a
6to4 connected site router.

> >
> > I think I agree. But I was asked to provide a description 
> of potential
> > 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.
> 
> 

The failing assumption is that all the 6to4 routers are participating in
a common routing conversation. What is more likely is that they will
participate in a local routing domain, and be configured for external
routes. Despite the discussion in 5.2-2.2, is it really likely that the
ISP community will want-to/allow/be-capable-of enabling all site 6to4
routers as BGP  participants? A few multi-homed ones maybe, but that is
no different than today. My proposal addresses this and suggests that a
few well-known relays participate in that BGP, and redirect the masses
of 6to4 routers. Tunnel brokers also work for finding an initial
default, but they break down if the native IPv6 networks are
partitioned. 

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

There is no attempt to mix the environments so there shouldn't be any
new failure modes. There may be a high number of players newly exposed
to the known failures though, which I assumed to be the reason for
discussing it here. It might work better to use a pointer to any
existing documentation on BGP failure modes and defense mechanisms, than
to try and summarize it here.

Tony

---

From: Richard Draves <[email-masked]>
Date: Mon, 24 Jul 2000 20:40:04 -0700

> I cannot take seriously the idea that an ISP would go through the
> tremendous expense of putting in an IPv6 infrastructure for 
> the purpose
> of saving 20 bytes per packet.

It's their call. At some point, I think if the ISPs see their customers
using IPv6 then they will want to support it more directly (surely
supporting your customers needs directly is better than indirectly?) but if
this doesn't happen soon, that's fine too.

> > => *personally* I don't like 6to4 because this is far too close to
> > automatic tunnel / compatible address stuff which was proved to
> > be a bad idea.
> > 
> 
> What, in a nutshell, was the problem?

The problem with IPv4-compatible addresses is that every machine needs an
IPv4 address. (Otherwise they work great.) If you can get that many IPv4
addresses, the major advantage of IPv6 is moot. Whereas with 6to4, you just
need one IPv4 address for your entire site.

Rich