Subject: Re: (ngtrans) shipworm, 6to4 and anycast [...]

From: David Terrell <[email-masked]>
Date: Mon, 4 Feb 2002 13:11:46 -0800

On Thu, Jan 31, 2002 at 12:32:52AM +0200, Pekka Savola wrote:
> RFC3068 uses anycast for two things:
> 
>  1) 6to4 servers for finding closest relay (configuring default route to 
> 192.88.99.1)
> 
>  2) native clients reaching any 2002::/16 addresses (as it's being 
> advertised to the Internet).
>    ==> therefore, 192.88.99.1 is used as a source address for IPv6-in-IPv4 
> encapsulated packets sent to 6to4 servers (and from there, clients).
> 
> You're missing 2), it appears.  I haven't read the draft lately, to see if 
> this is sufficiently clear there.

I do not understand the second assertion here.  How would a native
client use 2002:c058:6301:: to reach anything?  Either someone is
advertising the /48 into the DFZ (of dubious value) or someone is
advertising 2002::/16 into the DFZ or the local IGP and is running
a 6to4 Router, or you're sending 2002::/16 destinations to
2002:c058:6301::/48 via a 6to4 router which is obviously suboptimal.

-- 
David Terrell            | "... a grandiose, wasteful drug war that will never
[email-masked]             | be won as long as so many Americans need to 
Nebcorp Prime Minister   | anesthetize themselves to get through the day." 
http://wwn.nebcorp.com/  |  -Camille Paglia

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Feb 2002 11:11:10 +0100

> 2002:c058:6301::/48 via a 6to4 router which is obviously suboptimal.

But you *always* send to 2002/16 destinations via a relay router, unless
you are on a 6to4 site yourself. 2002/16 will be a default route at any 
native IPv6 site.

   Brian

---

From: David Terrell <[email-masked]>
Date: Wed, 6 Feb 2002 12:48:35 -0800

> you are on a 6to4 site yourself. 2002/16 will be a default route at any 

I guess I'm differentiating between a router that announces 2002::/16
and has a 6to4 pseudointerface, and one that accepts 6to4 traffic
on the IPv4 side and relays into the native IPv6 internet.  Rereading
3056, it makes no such distinction.  I tend to think of these as
"egress" and "ingress" relays respectively (relative to a global
IPv4 cloud and a [possibly fairly large]) IPv6 cloud or island.  I
personally would like to see more people doing 6to4 egress even if
they don't want to do public ingress, since this lets you take
advantage of currently-superior IPv4 routing.

None of which is really relevant to the original discussion, which
has been more thoroughly resolved elsewhere.

-- 
David Terrell           | If a crypto algorithm is cracked in a forest
Nebcorp Prime Minister  | and a tree falls on a mime, does microsoft
[email-masked]            | need to publish an advisory on it?
http://wwn.nebcorp.com/

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Feb 2002 13:25:09 -0800

David Terrell wrote:
> ...

I think you are trying to create a half-ass public relay. On the IPv4
side it will only relay traffic headed toward the native IPv6
environment that originated through it (assuming the other tunnel
endpoint remembers and associates the native address with the incoming
tunnel), but it will relay all native IPv6 traffic close to it across
the IPv4 segment. What is the point in announcing default in one
direction and taking any available traffic, but not being willing to do
so in the other?

BTW: there is nothing that makes IPv4 routing 'currently-superior'. The
only argument that even comes close is 'concatenated link-layer
infrastructure', but even that is a challenging argument as long as the
endpoints believe the IPv6 path is unobscured because in the tunnel
context IPv4 is just another link-layer.

Tony