[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comment on unmanaged analysis presentation/doc



> 	if a node in 6to4 site A (2002:xxxx:xxxx::/48) tries to talk to a node
> 	in 6to4 site B (2002:yyyy:yyyy::/48), 6to4 router for site A
> 	will directly contact 6to4 router for site B.  therefore, any 6to4
> 	routers will need to accept tunnelled packet from anybody.

Yes, but they can verify that
 - The IPv4 source is identical to the IPv4 part of the IPv6 source 
   address (same xx.xx.xx.xx)

The first check ensures that spoofing the IPv4 source requires spoofing
the IPv6 source, hence there is no loss of information by removing the
IPv4 source address when decapsulating the packet.
Stated differently, if you apply IPv4 ingress filtering in the network
and IPv6 ingress filtering in the IPv6-native parts of the network, the
use of encapsulation doesn't create additional holes in your filtering.

The use of relays to allow IPv6-native hosts to send to 6to4 domains
make this impossible, because any relay needs to be able to encapsulate
packets towards a particular 6to4 router. Thus the router will
receive packets where the IPv4 source and IPv6 source are unrelated.
Even if ingress filtering is applied as above, is it impossible to tell
whether a given relay is allowed to forward packets from a given IPv6 prefix.
Hence the use of encapsulation creates a hole in the ingress filtering being 
used.

> >6to4 routers should only accept tunneled packets from their configured
> >relay(s).
> 
> 	if you've done the first sentence, packets from other 6to4 sites will
> 	get (mistakenly) rejected.

Sorry, I forgot to mention the case when 6to4 router communicate directly
(the case above).

> 	the problem is not just relays, but all 6to4 routers.

If we discard the need for IPv6-native to communicate with 6to4 sites
i.e. there is no need for relays, then the use of encapsulation doesn't
create any new holes in an ingress filtering setup.

   Erik