Subject: (ngtrans) Sites with multiple 6to4 border routers

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2001 14:13:20 -0600

The final point that Tony Hain made at the microphone is correct. The 6to4 model 
is that if a site is connected by two 6to4 border routers, it will inherit two
6to4 prefixes (one from each border router). Then hosts can have two addresses,
one under each prefix, if they want. But the outbound default IPv6 route
for a host needs to point to the appropriate border router, since if its
packets end up at the wrong one, I think the standard 6to4 sending rule
is broken.

I wouldn't recommend this. I think a site that needs multiple connectivity
should (a) wait for MULTI6 to do its job and (b) use native prefixes,
not 6to4. Multiple connectivity doesn't seem required for 6to4's role
as an early transition tool.

   Brian

---

From: [email-masked]
Date: Mon, 26 Mar 2001 07:57:25 -0600

hi vlad,

fyi..I got much input from several to provide multiple TEPs.  We have to
figure out ports too for the shin proposal.  I think it will be an extension
as we don't want to hold up base dstm but we may need to get it in base
dhcpv6...........
/jim

> -----Original Message-----
> From: ext Vladislav Yasevich [mailto:[email-masked]]
> Sent: Friday,March 23,2001 12:39 PM
> To: George Tsirtsis
> Cc: NGTRANS List
> Subject: Re: (ngtrans) Sites with multiple 6to4 border routers
> 
> 
> Well, that just shows how much I know... :)
> 
> However, I still don't see a need for a special address for
> 6to4 routers.  The DSTM mechanism can provide the TEP and
> it might as well provide the 6to4 address of the router (not
> any speciall address).
> 
> May be DSTM might be extended to privide multiple TEPs and
> let the implementation choose one (or cycle through them)?
> Just a thought.  This way we don't have to reserve a speciall
> address.
> 
> -vlad
> 
> George Tsirtsis wrote:
> > 
> > -----Original Message-----
> > From: Christian Huitema [mailto:[email-masked]]
> > Sent: Friday, March 23, 2001 10:50 AM
> > To: [email-masked]
> > Cc: Vladislav Yasevich; George Tsirtsis; NGTRANS List
> > Subject: RE: (ngtrans) Sites with multiple 6to4 border routers
> > 
> > > >> I believe that's what Brian Carpenter, Tony Hain, and 
> Dave Thaler
> > were
> > > >> saying the meeting.   You have to use a globaly IPv4 address to
> > > >> create a 6to4 prefix.  I don't beleave you can assign 
> the same IPv4
> > > >> address to 2 independent devices...
> > > >Uh? There is nothing impossible there. Suppose that we have a
> > > >multi-homed site that connects to the Internet through multiple
> > routers,
> > > >both of which advertise the same IPv4 prefix, say 123.123.1/23.
> > >
> > >       i guess you are talking about different thing from Vladislav
> > said:
> > >
> > > >        /-------\                   /------
> > > >        |       | +-+               |
> > > >        |       +-+A+---------------+
> > > >        |       | +-+               |
> > > >        | Site  |                   | Internet
> > > >        |       | +-+               |
> > > >        |       +-+B+---------------+
> > > >        |       | +-+               |
> > > >        \-------/                   \-----
> > 
> > No. When I say that "It is quite natural to reserve a single IPv4
> > address for the 6to4 routing service", I mean that A and B both use
> > 2002:xxxx:xxxx::/48; both A and B use x.x.x.x. They 
> advertise different
> > addresses in the IPv6 cloud; they advertise the same IPv4 
> prefix (say
> > x.x.x/24) to the Internet; the routing of outward bound packets is
> > determined by IPv6 routing inside the site, e.g. RIPng; the 
> routing of
> > packets from the Internet is determined by Internet routing 
> protocols
> > (e.g. BGP).
> > 
> > GT> Indeed! The requirement for 2 or more 6to4 gates to be 
> able to use the
> > same 6to4 prefix is that they advertise the same ipv4 
> prefix in the IPv4
> > Internet. Up to now it has been assumed that they only 
> advertise a single
> > IPv4 address but this is clearly not necessary.
> > 
> > GT> In this case, mechanisms that require outgoing and 
> incoming paths to be
> > using the same 6to4 gate could make use of Alain's 6to4 
> designated address.
> > 
> > George
>

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 26 Mar 2001 11:04:18 -0500

Jim,

If we find that the 6to4&dstm idea works we might also need a flag in the
DHCPv6 message about TEP; When the flag is SET, the TEP address would be
zero (or missing or whatever) and thus the end node would know to use the
6to4 router as a gateway...i.e.: one less piece of state to be configured
manually (=> good for renumbering!)

George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 26, 2001 8:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: (ngtrans) Sites with multiple 6to4 border routers

hi vlad,

---

From: [email-masked]
Date: Mon, 26 Mar 2001 10:53:21 -0600

ack..
/jim

> From: ext George Tsirtsis [mailto:[email-masked]]
> Sent: Monday,March 26,2001 11:04 AM
> To: [email-masked]'

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 28 Mar 2001 08:20:48 -0800

> > This therefore requires that each 6to4 border router must
> > know *all* 6to4 prefixes in use on the local site; otherwise
> > it might send a local packet outside (i.e. right back to itself
> > or one of its peers). It's much safer to only use one 6to4
> > prefix per site, which means Christian's model and the above
> > noted deviation from RFC 3056. But then we have to fix
> > itojun's concern about filtering. My personal preference is
> > to keep things simple, as I said: when someone wants to
> > multihome their IPv6 site, it's time to move to a real native
> > IPv6 prefix.
> 
> so, the v6 site wanting reliability and load-balancing through
> multi-homing will wait for the deployment of native v6 backbones?

The reliability and load-balancing you get from any 6to4 solution is
really the combination of two factors, the reliability of the underlying
IPv4 connectivity, and the reliability of the 6to4 gateways.

This group should realize that there is not much we can do to enhance
the reliability of the underlying IPv4 service. It may or may not be
multi-homed, to a single ISP using several independent connections or to
multiple ISPs. In the vast majority of cases, IPv4 multi-homing is
achieved by advertising a single IPv4 prefix through multiple address
lines. We could try to build several 6to4 prefix out of that single IPv4
prefix, but the dependency on the IPv4 routing would not be lessened:
multi-homing and load balancing would be exactly what is provided by the
IPv4 infrastructure.

The reliability of the 6to4 gateways is obviously increased if we remove
any single point of failure, or more precisely if we don't add any
single point of failure to the existing failure points in the underlying
IPv4 infrastructure. The best solution would be to have the 6to4
function being performed by the very same routers that provide IPv4
connectivity. If there is a single IPv4 router, then we have a single
point of dependency for both IPv4 and 6to4; any other solution just
degrades the overall reliability. If there are several routers, we want
them to perform the 6to4 relay function in a coordinated manner, just
like they perform IPv4 routing of a single prefix in a coordinated
manner.

There are obviously cases in which the existing IPv4 routers cannot
perform the 6to4 relay function. In such cases, the routers must be
supplemented with additional 6to4 "servers." These servers become
additional failure point in the system; having a single such server
creates a single point of failure; this is the rationale for having
several servers performing 6to4 translation in a parallel manner. In
this parallel configuration, we have two basic choices: that the servers
each handle their own prefix, or that they all advertise a single 6to4
prefix in a coordinated manner. Having a prefix per server is a markedly
inferior solution, since it creates a dependency between applications
using this particular address and the single server. 

Having a coordinated prefix requires that the 6to4 servers all advertise
a "host route" to the same IPv4 address. This requires that the servers
participate in IPv4 routing; this is easy if the 6to4 function is
implemented in IPv4 routers; it can be hard when the function is
implemented in 6to4 hosts. This leads to a practical roadmap: pick a
single IPv4 address as the basis of the 6to4 prefix; start with a single
host based server for the site; as soon as the function is available in
dual IPv4/IPv6 routers, instruct them to intercept the packets bound to
that address and perform the 6to4 relay function. 

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 28 Mar 2001 11:24:04 -0800

> From: Nathan Lutchansky [mailto:[email-masked]]
> On Wed, 28 Mar 2001, Stig Venås wrote:
> > On Wed, Mar 28, 2001 at 09:45:48AM +0100, Tim Chown wrote:
> > > On Wed, 28 Mar 2001, Jun-ichiro itojun Hagino wrote:
> > >
> > > > >provided, of course, that native IPv6 service is available at
> > > > >reasonable cost and that it has good connectivity with 6to4.
> > > >
> > > > be very sure to ask your upstream ISP to provide one,
repeatedly.
> > > > if there's no visible demand they won't even consider.
> >
> > And BTW, if one has a static IPv4 address, 6to4 is a better choice
than
> > tunnelbrokers.
> 
> Is it?  6to4 has many advantages, such as easy configuration and an
entire
> guaranteed /48 for your use, but last time I used 6to4 (which was
> admittedly way back in January), the lack of relay routers made the
packet
> paths crazy.  For example, to connect to www.kame.net, I routed from
here
> in New York to Microsoft's 6to4 relay which routed on the 6bone back
> across the U.S. and across the pacific.  The return packets came back
over
> the ocean, across the U.S., through Cisco's 6to4 relay, back across
the
> U.S., and to me.

That is precisely why we have been working on the "6to4 anycast"
proposition. Presumably, once this is ready, it will be easy to run more
relays, and that will take some load off the Microsoft relay.