Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt
"Changming Liu" <[email protected]> Mon, 3 Jan 2005 15:13:07 -0800
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F1E9.C8D16E38 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 =20 Juniper Networks 1194 N. Mathilda Ave.=20 Sunnyvale, CA 94089-1213 Http: www.juniper.net <http://www.juniper.net/>=20 =20 =20 Arifumi Matsumoto wrote:=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Internet | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 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] +------+ =09 =09 =09 =09 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. =09 =09 =09 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. =09 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? =09 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 =09 =09 =09 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. =09 =09 =09 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. =09 =09 =09 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. =09 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 protected] ________________________________ Changming Liu =20 Juniper Networks 1194 N. Mathilda Ave.=20 Sunnyvale, CA 94089-1213 Http: www.juniper.net <http://www.juniper.net/>=20 Tel: (408) 936-8010 =20 ------_=_NextPart_001_01C4F1E9.C8D16E38 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial> <P><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20 class=3D365480523-03012005>A</SPAN>nother <SPAN=20 class=3D365480523-03012005>case</SPAN> that SAS <SPAN=20 class=3D365480523-03012005>may be</SPAN> useful is <SPAN=20 class=3D365480523-03012005>for</SPAN> the firewall tranversal. In = case <SPAN=20 class=3D365480523-03012005>that </SPAN>the ISP deploys some kind = of <SPAN=20 class=3D365480523-03012005>stateful </SPAN>firewall (like in managed = firewall=20 services), the forwarding traffic and returning traffic should go = through the=20 same firewall or the return traffic may be blocked. If ISP1's assigned = address=20 is used as the source address and the traffic is forwarded via ISP2 and = the=20 traffic will <SPAN class=3D365480523-03012005>routed</SPAN> = back <SPAN=20 class=3D365480523-03012005>through</SPAN> ISP1<SPAN = class=3D365480523-03012005> (the=20 destination is now the source address assigned by ISP1)</SPAN>, the = firewall in=20 ISP1 will belcok the traffic.<SPAN class=3D365480523-03012005> SAS will = ensure=20 that traffic go through each ISP will have the correct source address so = that=20 return traffic can come back from the same ISP.</SPAN></FONT></FONT></P> <DIV align=3Dleft><FONT face=3DArial size=3D2>Changming Liu</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Juniper = Networks</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>1194 N. Mathilda Ave. = </FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Sunnyvale, CA = 94089-1213</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Http: <A=20 href=3D"http://www.juniper.net/">www.juniper.net</A></FONT></DIV> <DIV align=3Dleft><FONT face=3DArial = size=3D2></FONT> </DIV><!--X-Head-Body-Sep-End--><!--X-Body-of-Messa= ge--></FONT></DIV> <DIV><FONT face=3DArial size=3D2><TT></TT></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><TT>Arifumi Matsumoto wrote: = </TT></DIV> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em = solid"><PRE style=3D"MARGIN: 0em">Hi Brian, thank you for comments.</PRE><BR><PRE style=3D"MARGIN: 0em">On = 2004/11/05, at 21:29, Brian E Carpenter wrote:</PRE><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em = solid"> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee = 0.2em solid"><PRE style=3D"MARGIN: 0em">3.1 Multihome Site with = Global-Closed Mixed Connectivity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Internet | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 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] +------+ </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR></PRE><BR><PRE = style=3D"MARGIN: 0em"><BR>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. </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR></PRE><BR><PRE = style=3D"MARGIN: 0em">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. </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR>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.</PRE> <DIV><BR></DIV><PRE style=3D"MARGIN: 0em">Walled Gardens are bad things = anyway, so I wonder if we should solve this? </PRE> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em = solid"><PRE style=3D"MARGIN: 0em"><BR>Anyway, I agree that this case may = not be the scope of multi6.</PRE><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em = solid"><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee = 0.2em solid"><PRE style=3D"MARGIN: 0em">3.2 Host with Multiple Home = Addresses and Connectivity to Two Global Networks </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR></PRE><BR><PRE = style=3D"MARGIN: 0em">This is the case of interest to = multi6.</PRE><BR><PRE style=3D"MARGIN: 0em">...</PRE><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee = 0.2em solid"><PRE style=3D"MARGIN: 0em"> 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. </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR></PRE><BR><PRE = style=3D"MARGIN: 0em">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. </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR></PRE><BR><PRE = style=3D"MARGIN: 0em">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. </PRE></BLOCKQUOTE><PRE style=3D"MARGIN: 0em"><BR>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.</PRE> <DIV><BR></DIV><PRE style=3D"MARGIN: 0em">Therefore, I still think that = SAS policy is a secondary component for multi6.</PRE> <DIV><BR></DIV><PRE style=3D"MARGIN: 0em"> Brian</PRE> <DIV><BR></DIV> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em = solid"><PRE style=3D"MARGIN: 0em">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.</PRE><BR><PRE style=3D"MARGIN: 0em">It may be = useful to define a new DHCP option for Solicit message that explicitly requests for multiple routes for the same destination network.</PRE><BR><PRE style=3D"MARGIN: 0em">-- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: [email protected]</PRE><BR></BLOCKQUOTE><PRE = style=3D"MARGIN: 0em"><BR></PRE> <DIV><BR></DIV><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Foll= ow-Ups--> <DIV> <HR> </DIV><!--X-Follow-Ups-End--><!--X-References--> <UL></FONT></UL> <DIV align=3Dleft><FONT face=3DArial size=3D2>Changming Liu</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Juniper = Networks</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>1194 N. Mathilda Ave. = </FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Sunnyvale, CA = 94089-1213</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Http: <A=20 href=3D"http://www.juniper.net/">www.juniper.net</A></FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Tel: (408) = 936-8010</FONT></DIV> <DIV> </DIV></BODY></HTML> =00 ------_=_NextPart_001_01C4F1E9.C8D16E38--