Subject: Re: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways

From: Brad Huntting <[email-masked]>
Date: Fri, 03 Nov 2000 23:36:02 -0700

> I've thought about this a bit, and would like it slightly better
> if the v4 anycast address were used as the link layer address
> for a variant of router discovery (rather than assuming a default
> route to the anycast address).  It's more versatile that way.

I guess I dont see the added versatility...  What did you have in
mind?

brad

---

From: Keith Moore <[email-masked]>
Date: Sat, 04 Nov 2000 14:53:06 -0500

> I guess I dont see the added versatility...  What did you have in

what I'd like to do is to work out a way in which there could
be boxes answering to the anycast address that would accept 
something akin to ND requests for arbitrary v6 prefixes 
(outside of 6to4 space) and return NA-like answers to indicate 
the v4 tunnel endpoint corresponding to the v6 prefix.
so instead of relay routers having to route traffic for all of 
v6 space each v6 network could have one v4 address of a router
which would only have to handle incoming traffic for its v6 prefix.
(we could advertise those tunnel endpoint addresses using a BGP4
option, or DNS (yeech), or both)

ideally router and neighbor discovery could be re-used without (much) 
change for this kind of tunnel discovery - and perhaps this would be 
acheived by defining an algorithm for use on a "6to4 tunnel" interface, 
for mapping from certain kinds of v6 destination addresses to v4 
"link layer" addresses.  

for example, now we have the rule that if the destination has prefix 
2002::/16 then the corresponding v4 link layer address is taken from 
the next 32 bits of the v6 address.  we might add the rule that if 
the destination is the v6 "all routers" address then the corresponding 
v4 link layer is the well-known anycast address X.X.X.X.

this probably applies more to hosts with a 6to4 interface than to 
6to4 routers, but it might be useful for border routers also

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Nov 2000 09:39:05 -0600

Hmm. One of the ideas behind basic 6to4 was to minimize special case
treatment, so that as far as possible both hosts and routers
would "just work " with 6to4 once the 6to4 pseudo-interface
was implemented.

Seems to me that we are drifting away from that in this discussion
(not too badly with Christian's proposal, but this is beginning to
look like lost of special case handling for 2001::/16)

  Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Nov 2000 13:52:41 -0500

> look like lost of special case handling for 2001::/16)

(I assume you meant "lots of special case handling")

My goal is still to have things "just work".  But 6to4 really only
makes things "just work" between hosts in the 6to4 TLA - the solution
that 6to4 proposes for interoperation between 6to4 hosts and v6 hosts 
outside of that space still leaves a lot to be desired, especially
in a world where there are significant numbers of both 6to4 hosts
and native IPv6 hosts.

But I don't see how trying to improve the situation through some
sort of tunnel discovery protocol implies more special case handling
for the 6to4 TLA - since we're not talking about how to route to 6to4 
space, but rather how to route to everything *except* 6to4 space.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Nov 2000 13:38:32 -0600

I agree that completely automating the discovery of 6to4 relay
routers would be a good thing to do, but trying to find the best
relay for a given v6 prefix is close to designing a new routing
protocol, and there I have doubts.

BTW are you proposing to replace the solution proposed in 
draft-hain-6to4-scaling-00.txt with yours?

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Nov 2000 15:39:08 -0500

> draft-hain-6to4-scaling-00.txt with yours?

in a word: yes.

The two mechanisms are similar except that where Tony's draft uses
a well-known DNS name to find the nearest 6to4 relay, I would vastly
prefer to use an anycast address for this purpose.   

Using a well-known DNS name to find a nearby relay strikes me as 
terribly wrong for several reasons - first, it is putting a network 
layer service at the application layer; second, to make it reach the 
"right" relay it would either require a very smart central server 
(and thus a central point of control/failure for such mappings),
or it would encourage ISPs to implement hijacking DNS proxies so
that the routing lookups will go to their lookup servers, in order
to implement their routing policies. (which would be *really* evil)

The DNS model is that information in DNS is globally scoped 
(any information which is publically available is presented 
identically to everyone) and federated (each zone maintains its 
own information).  This is the argument made in RFC 2826 against
having multiple DNS roots, but it applies equally well to having
a DNS "root" for ipv6 tunnel discovery.  I don't want to see us 
break this model. 

If we really wanted to use DNS for automatic tunnel discovery then I'd 
prefer a scheme that looks up the destination address in DNS
(e.g. querying <prefix>.ip6.arpa).  Each native IPv6 net would then
advertise its IPv4 tunnel through DNS.  It doesn't break the DNS
model (either in terms of consistency of views or of federation), and 
it has good deployment properties - v4-only ISPs don't have to do 
a thing, and the only burden to make things work is placed on v6 
networks that presumably have an interest in being reachable from v4 
domains.

But for various reasons including the extra overhead and relative 
unreliability of DNS, I'd far rather the relay router be 'discovered' 
at the network layer using anycast.   Why should we go to the trouble
of setting up and maintaining DNS servers to handle the lookup when
BGP alone will do the job more quickly, more reliably, and with less 
overhead?

To me, using anycast also has the essential deployment property: 
a v4-only provider doesn't have to do anything to make it work.
It also has a higher probability of finding the "nearest"
(according to policy) tunnel endpoint discovery server.

Now it may be that the peers of IPv4-only provider X won't like
X's customers using their tunnel discovery servers.  But to me it
seems that the identical concern exists for the tunnel discovery 
servers in the draft-hain-6to4-scaling-00.txt scheme. except that 
the DNS servers have more overhead (and presumably their use by
other ISPs' customers is more objectionable).  I realize I'm
not an ISP, but to me it seems like what would matter to an ISP is
that someone else is using your tunnel discovery servers without
paying you, not whether someone is using DNS or anycast to 
find those servers.

And if an IPv4 provider wants to prevent folks from tunneling to
v6 sites, or if an IPv6 provider wants to prevent non-customers 
from using its tunnel discovery servers, they can do that in either
scenario.  But I'd far rather them do so by filtering a BGP route 
advertisement to a well-known anycast address (or by filtering the 
traffic to that address) than by intercepting DNS traffic.

Keith