Subject: RE: (ngtrans) 6to4 issues

From: Richard Draves <[email-masked]>
Date: Mon, 22 Mar 1999 19:46:31 -0800

Some misc comments...

1. I intend to implement 6to4 very soon. (If I can stop traveling & start
hacking ;-)

2. I'm not so concerned about incongruent v6/v4 routing leading to traffic
crossing the same links twice... I think an advantage of 6to4 is that it is
less prone to this compared to a network of configured tunnels. (The only
approach even less prone to this is automatic tunneling, and automatic
tunneling has limited applicability.)

3. 6to4 works best when the isolated v6 sites are the majority of the v6
world, communicating end-to-end over a legacy v4 backbone. It fades away
fairly well when isolated v6 sites are a minority of the v6 internet. The
stickiest issues (like incongruent routing) are when the internet backbone
is split between v6 and v4. I hope v6 will have enough momentum, that
when/if that happens, any problems will just be more reasons to move quickly
to a v6 backbone.

4. I don't see how to make multicast routing protocols (or any routing
protocols, for that matter) work with 6to4, or at least not easily. The
beauty of 6to4 is that an isolated v6 site can join up without any
communication with or configuration of relay routers. I think the solution
of multicast is to hash to a v4 multicast address, and let multicast work as
well or as poorly as v4 multicast.

5. Another issue is configuring the isolated v6 site with the v4 addresses
of one or more relay routers. I want 6to4 setup to be extremely simple. I
like the idea of a v4 anycast address. Brian, you expressed skepticism about
this... has anyone ever tried to make a v4 anycast address work? Another
possibility would be to have a dns name like 6to4.ipv6.org that resolves to
v4 addresses of public relay routers.

6. Remember the thread a while back, about demultiplexing protocol 41
packets when the implementation supports configured tunnels, automatic
tunnels, and 6over4? Adding 6to4 to the mix makes this even more
complicated. From the relay router's perspective, it will be hard to
distinguish an incoming encapsulated 6to4 packet from an incoming
encapsulated 6over4 packet. One approach is to use different v4 addresses to
separate things.

Rich

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, March 16, 1999 8:29 AM
> To: [email-masked]
> Subject: (ngtrans) 6to4 issues
> 
> 
> As requested in today's NGTRANS session here are (some of)
> the issues on draft-ietf-ngtrans-6to4-01.txt
> 
> 1. concerns about multicast (see Erik's comment below)- must
>    avoid the NBMA swamp.
> 2. not only does a relay router need a route to a native IPv6 router,
>    but there must be a route in the other direction. This is just
>    the same as a configured tunnel (but it is in effect a tunnel
>    to a whole 6to4 cloud, not to a single site). Also what routing
>    protocol runs between the relay router and the native router?
> 3. need more illustrations and examples in the draft,
>    more worked out examples on routing in particular, and more
>    motivation for why it's a useful tool in the toolkit.
> 4. a possible model is using 6to4 to create a virtual IPv6 ISP, i.e.
>    the relay router is not on a 6to4 user site but ISP-operated.
> 5. concerns about incongruent routing between IPv6 and IPv4 leading
>    to traffic crossing the same path twice.
> 6. objections to specifying address selection algorithm.
> 7. observation that configured tunnels can also co-exist
>    with IPv4 NAT.
> 8. suggestion that IPv4 address used to generate IPv6 prefix should
>    be inverted to completely eliminate risks of v6 routing table
>    pollution.
> 
> The consensus was to expand and develop the draft, so further
> comments are welcome.
> 
>  --  Brian
> 
> Erik Nordmark wrote:
> > 
> > Brian,
> > 
> > In section 6.1 you say there is no setup needed.
> > In section 5 you say that multicast can be provided by e.g PIM-SM
> > (I assume you mean IPv6 PIM-SM.)
> > 
> > PIM needs a unicast routing protocol to provide the base 
> for the RPF.
> > Are you asserting that all 6to4 egress/ingress routers should assume
> > they are directly attached to <FP=001, TLA624>/16 prefix i.e. inject
> > such a unicast route into their "site" for the purposes of 
> multicast routing?
> > That isn't clear from the document.
> > 
> > When it comes to transmitting multicast packets from the 
> egress router
> > I don't see anything in the spec that helps it determine where to
> > send the packets. So short of sending 2^^32 packets to all 
> possible IPv4
> > addresses what do you propose?
> > 
> > In section 6.2 you say:
> >    An IPv6 router willing to act as a relay from native 
> IPv6 to the 6to4
> >    address space advertises a route to 
> {FP=001,TLA=TLA624}/16 into the
> >    native IPv6 routing system, and whatever other native 
> IPv6 prefixes
> >    are appropriate on its 6to4 interface.
> > 
> > In don't understand hpw you can do the second part. You 
> don't have a routing
> > protocol running over the 6to4 interface so how can you 
> advertise routes
> > on that interface?
> > 
> > What am I missing?
> > 
> >    Erik
>