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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 23 Mar 2001 08:26:40 -0800

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

        /-------\                   /------
        |       | +-+               |      
        |       +-+A+---------------+      
        |       | +-+               |      
        | Site  |                   | Internet
        |       | +-+               |      
        |       +-+B+---------------+      
        |       | +-+               |      
        \-------/                   \-----

Such multi-homing scenarios are not rare, and there are obviously here
for good reasons -- resiliency, load-sharing, etc. In such a site, you
don't want to create a single point of failure for the IPv6 service. It
is quite natural to reserve a single IPv4 address for the 6to4 routing
service, say 123.123.1.23, to construct a single IPv6 prefix for the
site from that single address, and to instruct both A and B to perform
the 6to4 routing service using that address. In the IPv6 plane, both A
and B will be advertising a default route. Packets will naturally be
routed through either A or B, depending on which one is up, or which one
is closest. Where is the problem, exactly?

-- Christian Huitema

---

From: [email-masked]
Date: Sat, 24 Mar 2001 01:37:46 +0900

George: A and B both uses nd 2002:xxxx:xxxx::/48.  A uses x.x.x.x,
		B uses y.y.y.y.
	itojun: it is problematical when B uses y.y.y.y and 2002:xxxx:xxxx::/48,
		due to filtering rule on the other side.
	Vladislav: George's way is hard.  also, A and B both using x.x.x.x
		and 2002:xxxx:xxxx::/48 is hard.
	Christian: A uses x.x.x.x and 2002:xxxx:xxxx::/48, B uses y.y.y.y
		and 2002:yyyy:yyyy::/48.

itojun

---

From: Alain Durand <[email-masked]>
Date: Sun, 25 Mar 2001 11:02:28 -0800

This is indeed the scenario I was trying to describe.
Outgoing packets can use multiple exit routers,
but incoming packets necessarily go through the
designated router.

         - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2001 12:52:13 -0600

> but incoming packets necessarily go through the

This is an explicit change to RFC 3056. It means configuring
all the site's 6to4 border routers to use the same V4ADDR value,
whereas the RFC says "V4ADDR MUST be configured on the IPv4
interface." 

I was initially concerned that the sending rule in the RFC
could loop. It says: 

       "if the next hop IPv6 address for an IPv6 packet
           does match the prefix 2002::/16, and
           does not match any prefix of the local site
               then
               apply any security checks (see Section 8);
               encapsulate the packet in IPv4"

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.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Mar 2001 15:03:21 -0500

> when someone wants to

provided, of course, that native IPv6 service is available at 
reasonable cost and that it has good connectivity with 6to4.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Mar 2001 15:33:09 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:
    >> when someone wants to multihome their IPv6 site, it's time to move to
    >> a real native IPv6 prefix.

    Keith> provided, of course, that native IPv6 service is available at
    Keith> reasonable cost and that it has good connectivity with 6to4.

  Something which I'm not convinced of.
  I attempted to fill in the "new" ARIN paperwork to get my ISP a block.
Well, this ISP doesn't even do BGP peering at this time, so I suspect we will 
never get a block, which means that I can't get one. I have two v4 links
(not multihomed).
  
  My question is, assuming that one got the block, couldn't one configure
a 6to4 address at each connection point in that connection points' native
IPv4 prefix, and advertise a route to a proper IPv6 prefix via two different
2002: prefixes?

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
]     [email-masked]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Mar 2001 16:38:27 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    mcr> My question is, assuming that one got the block, couldn't one configure
    mcr> a 6to4 address at each connection point in that connection points' native
    mcr> IPv4 prefix, and advertise a route to a proper IPv6 prefix via two different
    mcr> 2002: prefixes?

    Brian> I don't see why not. In an IPv6 routing domain, 6to4 prefixes behave like
    Brian> any /48 prefix.

  So, the problem that sites who did 6to4 because of lack of v6 ready ISPs
now face is that of getting:
    1) getting an AS #    (if they didn't have one already)
    2) getting a v6 block (given that their ISPs aren't cooperating)

  These are political issues. 
  (The situation where a site has multiple connections, but isn't officially
multihomed due to internal use of rfc1597 and NATs is rather common. They may
want to be deploying IPv6 to get rid of this headache. So, IPv6 may in fact
cause *more* multihoming to appear!!!)

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Mar 2001 18:26:50 -0500

> So, IPv6 may in fact cause *more* multihoming to appear!!!

IPv6 and multihoming are orthogonal.  

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2001 14:36:39 -0600

> IPv4 prefix, and advertise a route to a proper IPv6 prefix via two different

I don't see why not. In an IPv6 routing domain, 6to4 prefixes behave like
any /48 prefix.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 Mar 2001 16:59:13 -0500

> multihome their IPv6 site, it's time to move to a real native

so, the v6 site wanting reliability and load-balancing through
multi-homing will wait for the deployment of native v6 backbones?

randy

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 28 Mar 2001 16:20:59 +0900

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

	or move to Japan and you have a couple of options :-)

itojun

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Mar 2001 09:45:48 +0100 (BST)

> 	if there's no visible demand they won't even consider.

... in which case someone should shut down freenet6...

tim

---

From: Stig Ven�s <[email-masked]>
Date: Wed, 28 Mar 2001 14:17:07 +0200

> ... in which case someone should shut down freenet6...

And BTW, if one has a static IPv4 address, 6to4 is a better choice than
tunnelbrokers. Now that also Linux has 6to4 support there should be even
less need. Of course if one offers a public 6to4 relay one might want to
have some control with who uses it, so one might want some kind of tunnel-
broker like interface for modifying filters on the 6to4 relay.

I agree with Itojun though, even though 6to4 is very nice, users must
make the ISPs understand they want IPv6 services. The big question I
guess, is whether users will pay extra for it, or are willing to switch
ISPs to get it.

Stig

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2001 09:49:49 -0600

> multi-homing will wait for the deployment of native v6 backbones?

I said what my preference is, and itojun has raised a legitimate
concern about a spoofing risk. But if the ISPs don't offer
native v6, then 6to4 will indeed be used by multi-homed sites.

   Brian

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 28 Mar 2001 13:30:08 -0500 (EST)

On Wed, 28 Mar 2001, Stig Venås wrote:
> 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.

Since getting a static tunnel from Sprint in Maryland (I think), the
latency to kame.net has been cut by 2/3.  I assume that using an automated
tunnel broker that was topologically close would give equal performance
gains over 6to4.

And why should it make a difference whether your IPv4 address is static?
Dynamic IPv4 addresses work just as well, provided you have the tools to
reconfigure your "router" automatically when your address changes.

> guess, is whether users will pay extra for it, or are willing to switch

I've always assumed that there wouldn't be any real (customer) demand for
IPv6 service until we were completely out of IPv4 addresses, and only then
if it was just as easy to run IPv6 with NAT-PT as it was to run IPv4 with
NAT and private addresses.  I don't see any significant advantage of IPv6
over IPv4+NAT in the foreseeable future.

Of course, the demand will have to come from the customer side.  ISPs will
never, ever be able to force anybody into IPv6, and for a few years, they
probably won't be able to charge for it.

ISP:      "I'm sorry, but we're out of IPv4 addresses.  But how about a
           nice, big IPv6 block?"
Customer: "Can I still connect to IPv4 sites on the Internet?"
ISP:      "Sure, if you use NAT-PT."
Customer: "But couldn't I use NAT with private IPv4 addresses and not have
           to pay you for an IPv6 block?"
ISP:      "Um..."

I can't imagine there will be any customers who will be willing to pay
extra for IPv6 in the near future.  -Nathan

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Mar 2001 19:49:18 -0500

> tunnel broker that was topologically close would give equal performance

The two are not mutually exclusive.  If you have both an IPv4 connection
and an IPv6 connection via configured tunnel, you can use 6to4 for routing 
to other 6to4 sites and the configured tunnel for other IPv6 sites.
Either way, you have all of the limitations (and advantages) of a default 
route.  Which one is better for you probably depends on whether your
default 6to4 relay router has better connectivity overall than your
configured tunnel endpoint.

Keith