Subject: RE: (ngtrans) Sites with multiple 6to4 border routers

From: George Tsirtsis <[email-masked]>
Date: Fri, 23 Mar 2001 08:53:28 -0500

Brian,

Are you saying that 6to4 deployment should only be using one 6to4 router per
6to4 prefix advertised? I am not sure if this is clear in the spec but I
think it is a reasonable assumption at least to start with...

In this case the 6to4/DSTM proposal will work as follows:

An IPv4 packet can be encapsulated in an IPv6 packet with destination
address the anycast address for the 6to4 gate (2002:IPv4::). The 6to4 gate
will remember the IPv6 source address of the outer header and the IPv4
source address of the inner header, will decapsulate and forward to the IPv4
node. The returning packet will reach the same gateway which will have to
encapsulate in IPv6 using the retained mapping.

What is the source address that should be used for the IPv6 header? The
anycast address can not be used of course so the unicast IPv6 address of the
6to4 gate should be used instead....I think that should work; it is just
that the destination of the outgoing tunnel from the end node will an
anycast address but the source of the incoming tunnel from the 6to4 gate
will be a unicast address.

George

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 2:13 PM
To: NGTRANS List
Subject: (ngtrans) Sites with multiple 6to4 border routers

The final point that Tony Hain made at the microphone is correct. The 6to4
model 
is that if a site is connected by two 6to4 border routers, it will inherit
two
6to4 prefixes (one from each border router). Then hosts can have two
addresses,
one under each prefix, if they want. But the outbound default IPv6 route
for a host needs to point to the appropriate border router, since if its
packets end up at the wrong one, I think the standard 6to4 sending rule
is broken.

I wouldn't recommend this. I think a site that needs multiple connectivity
should (a) wait for MULTI6 to do its job and (b) use native prefixes,
not 6to4. Multiple connectivity doesn't seem required for 6to4's role
as an early transition tool.

   Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 23 Mar 2001 23:58:14 +0900

>think it is a reasonable assumption at least to start with...

	from what I understand from the presentation, the technique can be
	troublesome if your peer site is using security protection listed in
	RFC3056 section 9, second paragraph.

	(outgoing traffic from secondary 6to4 router will be from
	2002:xxxx:xxxx::/48, where xx.xx.xx.xx is an IPv4 address of
	primary 6to4 router)

itojun

   By default, 6to4 traffic will be accepted and decapsulated from any
   source from which regular IPv4 traffic is accepted.  If this is for
   any reason felt to be a security risk (for example, if IPv6 spoofing
   is felt to be more likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied.  A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address.  If this check is
   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).  2002:: traffic must also be excepted from
   checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2001 09:21:37 -0600

I'm going to look at this more carefully next week when my brain 
has cooled down from the IETF. This simply wasn't a secnario that
I walked thorugh during the design of 6to4.

   Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 23 Mar 2001 09:40:28 -0600

George

> think it is a reasonable assumption at least to start with...

I believe that's what Brian Carpenter, Tony Hain, and Dave Thaler were
saying the meeting.   You have to use a globaly IPv4 address to
create a 6to4 prefix.  I don't beleave you can assign the same IPv4
address to 2 independent devices...

I also have a few notes about you draft.  
	1.  You use a submnet router anycast address format 
	(EUI64 is all 0s) for the return path.  I don't think you
	can do that since you can't send from an anycast address...

	2.  I think you can simplify the sending of the original
	packet as follows.
		Inner Source = DHCPv6 assigned temporary V4 address
		Inner Dest   = The IPv4 destination from DNS
		Outer Source = 6to4 address assigned to the node
		Outer Dest   = 6to4 anycast address of the 6to4 gateway
			       (in the format 2002:V4ADDR::)
	
In this case, the 6to4 gateway will not have to do any
special processing since the outer packet is addressed to it.
It will, by default, decapsulate the packet and forward the inner 
IPv4 to the destination.  At this point the gateway can
also associate the V4 Source address with the 6to4 source
address.

The the case of the returning packet would do the following:
	If the destination IPv4 address is in the
	association cache, encapsulate the packet with
	the destination being the 6to4 address from the cache
	and the source being the 6to4 address unicast address
	of the gateway.
	Otherwise, it will do whatever IPv4 demands.

I am not sure of the security implications (haven't thought
that far).

-vlad