nanog mailing list archives

Re: IPv6 routing /48s


From: "Christopher Morrow" <morrowc.lists () gmail com>
Date: Wed, 19 Nov 2008 18:26:15 -0500

On Wed, Nov 19, 2008 at 6:03 PM, Jack Bates <jbates () brightok net> wrote:
Christopher Morrow wrote:

6to4 v6 addrs are just regular v6 addrs as far as the network is
concerned. if you put a 6to4 addr on your server you are saying that
you don't have native v6 transport to that host(s) and that you are
reachable via the 6to4 tunnel your host presumably has configured.


Sure it's just another address, except the anycast portion of it for dealing
with tunnels. It's also usually set to a different label and priority in
windows prefix policies (and at least some linux setups). I was referring to
the matter of if a windows box will even choose to use 6to4.

sure... address selection on new connections, standard ipv6 foo for
end-hosts. routers in the middle don't care, they route to the /16
route for 2002::/16, or they route to 192.88.99.0/24 ... anycast'd on
their respective sides of the version#.


6to4 is just an ip, 128bits long, but an ip... no differentiation is
made in the network for 6to4 vs 'normal v6'... unless someone's
putting up acls, or blackholing 6to4's /16, of course.


Windows and several other end systems use prefix policies to determine if
they use IPv6 or IPv4 and even when using IPv6, if they should use the 6to4
tunnel or not.


right, normal address selection rules.

can you explain this a little more? is it possible your v6 packets hit
something like 6pe inside HE and exit to NTT without hitting a


If a router does not a) know how to encapsulate 6to4 and send it over ipv4

routers in the middle shouldn't/won't do this.. once it's encap'd it
rides (on v4) to the 192.88.99.1 device that does the 4->6 majics,
then on to the v6 destination where it rides back to the 'local'
2002::/16 endpoint where 6->4 encap majics happen then over the v4 to
you again.

to the destination or b) know how to reach a 6to4 anycast address where the
packet can be encapsulated into IPv4, the packet is going to get dropped. Of
course, you could be right. he.net could be purposefully not sending icmp
replies back to 6to4 addresses for other reasons while replying to my
non-6to4 addresses. I hesitate to say filter, as it does push the 6to4
sourced packets on to other networks.

hopefully mike's message gets it worked out :)
-chris


Current thread: