Subject: Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt

From: "Changming Liu" <[email-masked]>
Date: Mon, 3 Jan 2005 15:13:07 -0800

Another case that SAS may be useful is for the firewall tranversal. In
case that the ISP deploys some kind of stateful firewall (like in
managed firewall services), the forwarding traffic and returning traffic
should go through the same firewall or the return traffic may be
blocked. If ISP1's assigned address is used as the source address and
the traffic is forwarded via ISP2 and the traffic will routed back
through ISP1 (the destination is now the source address assigned by
ISP1), the firewall in ISP1 will belcok the traffic. SAS will ensure
that traffic go through each ISP will have the correct source address so
that return traffic can come back from the same ISP.

Changming Liu
 
Juniper Networks
1194 N. Mathilda Ave. 
Sunnyvale, CA 94089-1213
Http: www.juniper.net <http://www.juniper.net/> 

Arifumi Matsumoto wrote: 

	Hi Brian,
	thank you for comments.

	On 2004/11/05, at 21:29, Brian E Carpenter wrote:

			3.1 Multihome Site with Global-Closed Mixed
Connectivity
			                  ==============
			                  |  Internet  |
			                  ==============
			                       |
			         2001:db8::/32 |         3ffe:1800::/32
			                  +----+-+   +-+----+
			                  | ISP1 |   | ISP2 | (Closed
Network)
			                  +----+-+   +-+----+
			                       |       |
			       2001:db8:a::/48 |       |
3ffe:1800:a::/48
			         (DHCP-PD')   ++-------++   (DHCP-PD')
			                      | Gateway |
			                      +----+----+
			                           |  2001:db8:a:1::/64
			                           |  3ffe:1800:a:1::/64
			                           |        (RA'/DHCP')
			                 ------+---+----------
			                       |
			                     +-+----+
2001:db8:a:1:[EUI64]
			                     | Host |
3ffe:1800:a:1:[EUI64]
			                     +------+

		
		I'm afraid I don't see why this case is of interest to
multi6.
		It is a case where the user site is connected to one ISP
and
		to one WGP (walled garden provider). This is not site
multihoming
		in the sense of multi6. As far as I can see, a longest
match is
		sufficient to tell the host which source prefix to use.

	Actually longest match isn't sufficient.
	If a packet is destined for a closed network,
	an appropriate source address is chosen
	automatically by longest match.
	On the other hand, a packet is destined for
	somewhere in the Internet, it is not always
	true. For example, when a packet is destined for
	3ffe:1801::1 in the Internet, the source address
	will be the one delegated by ISP2(WGP). In the
	end, the reply packet for it never returns because
	of the wall.

Yes, correct. It needs to be a bit more complex than
longest match - it's exact match on the /32 for ISP2
and you *will* need a priority policy to achieve that.

Walled Gardens are bad things anyway, so I wonder if
we should solve this?

	Anyway, I agree that this case may not be the scope
	of multi6.

			3.2 Host with Multiple Home Addresses and
Connectivity to Two Global
			   Networks

		This is the case of interest to multi6.

		...

			     Note that the end nodes are notified of an
address-selection policy
			     that includes prefix ::/0 by both ISPs,
hence a specific source
			     address for ::/0 can't be determined in the
Label-Rule judgment
			     phase described in RFC3484. So, these
entries for prefix ::/0 won't
			     actually be stored in the policy table, and
this policy table won't
			     have any effect on source-address selection
for packets that match
			     ::/0. The source address in these cases
will be determined by
			     following rules listed in RFC3484, such as
longest match with the
			     destination address.

		Exactly. And it is this case - when two ISPs both offer
connectivity to
		::/0 - that multi6 has to solve. That seems to be the
case you don't
		help with.

	Though I didn't include them in this version of my I-D,
	we are thinking of some other solutions. For those hosts
	that can support ECMP(equal cost multi-path) or some
	other special mechanisms for multihoming, it would
	be helpful to notify all the default routes and all the
	SAS Policies for default routes as I mentioned in I-D.

Well, I think the multi6 conclusion is that we need active
reachability checking anyway. The most that SAS policy can
do is decide the order in which reachability is checked.

Therefore, I still think that SAS policy is a secondary
component for multi6.

   Brian

	For normal hosts, however, it would be better not to
	notify multiple routes for the same destination network.
	So, it should be configurable on routers not to announce
	multiple routes but to choose one. The configuration will
	be like prioritizing ISPs.

	It may be useful to define a new DHCP option for Solicit
	message that explicitly requests for multiple routes for
	the same destination network.

	--
	Arifumi Matsumoto
	    Ubiquitous Computing Project
	    NTT Information Sharing Platform Laboratories
	    E-mail: [email-masked]

________________________________

Changming Liu
 
Juniper Networks
1194 N. Mathilda Ave. 
Sunnyvale, CA 94089-1213
Http: www.juniper.net <http://www.juniper.net/> 
Tel:  (408) 936-8010