Subject: Use of 6to4 anycast address.

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 7 Jul 2003 16:50:33 -0700

Hi, 

I am curious on what the implementations on the relay routers do, when encapsulating packets
using 6to4 anycast address (192.88.99.1) ? At least there is the issue of fragmentation at the
IPv4 level where when multiple relay router is sending packets to the same 6to4 router, the 6to4
router may not be able to properly reassemble as the same fragment id could be used by both
relay routers. I saw some discussion in draft-savola-v6ops-6to4-security-01.txt which recommends
that relay routers should use 192.88.99.1. Not sure what implementations do. Does the 6to4 
router implementations verify to make sure that the source address used is 192.88.99.1 in this case ?

-mohan

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jul 2003 09:09:00 +0300 (EEST)

On Mon, 7 Jul 2003, Mohan Parthasarathy wrote:
> I am curious on what the implementations on the relay routers do, when
> encapsulating packets using 6to4 anycast address (192.88.99.1) ? At
> least there is the issue of fragmentation at the IPv4 level where when
> multiple relay router is sending packets to the same 6to4 router, the
> 6to4 router may not be able to properly reassemble as the same fragment
> id could be used by both relay routers. I saw some discussion in
> draft-savola-v6ops-6to4-security-01.txt which recommends that relay
> routers should use 192.88.99.1. Not sure what implementations do. Does
> the 6to4 router implementations verify to make sure that the source
> address used is 192.88.99.1 in this case ?

To be clear, one of the previous versions of 
draft-savola-v6ops-6to4-security stated that all relays using 192.88.99.1 
might be beneficial.  I don't think this is the common practice, though.

It seems to me that the crux of this issue is whether the relay uses 
192.88.99.1 as the source address (when 192.88.99.1 is otherwise used), or 
one of its other addresses.  I've seen relays act both ways.

From the above, I'm not sure if the problem you're describing is a serious
one or not.  AFAICS, it would require that the fragmentation ID's would
collide while defragmenting.  Typically, packets causing defragmentation
arrive only some milliseconds apart, and the probability of collision in
that window seems rather small (but possible, of course).  This could be
considered just one source of L2 errors from IPv6 protocol perspective.

Has anyone collected statistics or analyzed this in detail to see whether 
this is a big issue or not?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings