-------------------- Marcelo Bagnulo (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001117.html 3. The previous point brings me to this point, which is about ingress filtering compatibility. There is no mention to ingress filtering comaptibility here. As you know, when multiple addresses are available, packets may be dropped by incompatibility between ingress filters and the selected source address. This document does not considers this as a problem. Becuase of ingress filters, many unidirectional paths may result (packets are dropped when flowing in one direction). However, as i understand it, mobike does not supports unidirectional paths (since the same address pair is used in both directions). So, my point is that in a case where no ingress filtering compatibility mechanism is provided and because no unidirectional paths are supported, the mobike protocol is likely to perform poorly in this scenario. I guess that at least you should mention this, if not fix it. -------------------- Tero Kivinen (2005-10-13): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > 3. The previous point brings me to this point, which is about ingress > filtering compatibility. There is no mention to ingress filtering > comaptibility here. As you know, when multiple addresses are available, > packets may be dropped by incompatibility between ingress filters and > the selected source address. This document does not considers this as a > problem. Becuase of ingress filters, many unidirectional paths may > result (packets are dropped when flowing in one direction). However, as > i understand it, mobike does not supports unidirectional paths (since > the same address pair is used in both directions). So, my point is that > in a case where no ingress filtering compatibility mechanism is provided > and because no unidirectional paths are supported, the mobike protocol > is likely to perform poorly in this scenario. I guess that at least you > should mention this, if not fix it. There should not be problems with the ingress filters, as we always use the source address associated to the given interface when sending packets out. I.e. if we have two interfaces A and B, having IPa and IPb, when we send packets out using IPa we always select interface A. The network connected to the interface should allow IPa to pass through it as it is IP address given by the network to the host for that interface. Implementations might need to do specific things to bypass routing of those packets (using default route or similar) to make use they are really sent out from the host using proper interface. -------------------- Marcelo Bagnulo (2005-10-15): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > There should not be problems with the ingress filters, as we always > use the source address associated to the given interface when sending > packets out. I.e. if we have two interfaces A and B, having IPa and > IPb, when we send packets out using IPa we always select interface A. > The network connected to the interface should allow IPa to pass > through it as it is IP address given by the network to the host for > that interface. Implementations might need to do specific things to > bypass routing of those packets (using default route or similar) to > make use they are really sent out from the host using proper > interface. > yes in this case there shouldn't be problems with ingress filters. However, as i understand it, it is expected that a common multihoming scenario is that multiple PA address blocks are assigned to a multihomed site (one per isp serving the site), so that there will be multiple global addresses assigned to each interface connected to the multihomed site. In this case, selecting the egress interface doesn't help you selecting among the multiple addresses assigned to that interface. However, you still may have problem with ingress filters because each address has been assigned by a different ISP, implying that if ingress filters are in place, each isp will only route those packets that contain the prefix delegated by the particular isp in the source address of the packet. hence, we may have ingress filters incompatibility issues, so unidirectional paths may be quite frequent if no ingress filters compatibility mechanisms are in place (for more about this check draft-huitema-shim6-ingress-filtering-00.txt -------------------- Tero Kivinen (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001121.html > yes in this case there shouldn't be problems with ingress filters. > However, as i understand it, it is expected that a common multihoming > scenario is that multiple PA address blocks are assigned to a > multihomed site (one per isp serving the site), so that there will be > multiple global addresses assigned to each interface connected to the > multihomed site. I do not think that will be the case of the roaming laptop case, i.e. the GPRS, WLAN and fixed ethernet links all give out exctly one IP-address to the connected interface, and you are only supposed to use that IP-address through that interface to which it was given to. > In this case, selecting the egress interface doesn't help you selecting > among the multiple addresses assigned to that interface. > However, you still may have problem with ingress filters because each > address has been assigned by a different ISP, implying that if ingress > filters are in place, each isp will only route those packets that > contain the prefix delegated by the particular isp in the source > address of the packet. hence, we may have ingress filters > incompatibility issues, so unidirectional paths may be quite frequent > if no ingress filters compatibility mechanisms are in place (for more > about this check draft-huitema-shim6-ingress-filtering-00.txt This could be the case in the multihomed VPN case. Note, that MOBIKE should still work perfect, if that unidirectional path does not work (i.e. packets does not get back when IP-addresses are reversed), then that address pair is not used, and we finally end up selecting address pair which does not have that problem with ingress filters. -------------------- Jari Arkko (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001122.html >I do not think that will be the case of the roaming laptop case, i.e. >the GPRS, WLAN and fixed ethernet links all give out exctly one >IP-address to the connected interface, and you are only supposed to >use that IP-address through that interface to which it was given to. > > In IPv6 it is indeed possible that you have multiple addresses and prefixes on a single interface. Then the issues that Marcelo refers to become possible. But from what I understand we can deal with that in an orthogonal way, i.e., this is an issue in MOBIKE usage, in SHIM6 usage, and even when no multihoming protocol is used at all. -------------------- Marcelo Bagnulo (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001125.html > This could be the case in the multihomed VPN case. Note, that MOBIKE > should still work perfect, if that unidirectional path does not work > (i.e. packets does not get back when IP-addresses are reversed), then > that address pair is not used, and we finally end up selecting address > pair which does not have that problem with ingress filters. > right, if such path exists It maybe the case, that only disjunct unidirectional paths exists, because of ingress filters. In this case, mobike protocol wouldn't achieve to communicate, even if a path exists, and it would be possible to communicate if the mobike protocol supported different addresses in the different peers of the communication > If it has multiple IP addresses associated to the IKE SA (even before > it is created) then it should try all combinations of them through the > normal IKE SA retransmission policy. does the IKE SA retransmission policy tries different source addresses? -------------------- Marcelo Bagnulo (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001124.html right, but supporting unidirectional paths in the protocol makes the protocol to perform better in such scenarios I mean, as i see it, or you assume that there is something that will take care of ingress filtering compatibility, in which case, supporting unidirectional connectivity support doesn't brings you much, or you don't assume some ingress filtering compatibility mechanism and then supporting unidirectional paths does buy you some extra performance. but the mobike protocol doesn't seems to do none of them afaict (or at least it doesn't state anything about this) -------------------- Jari Arkko (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001126.html > right, but supporting unidirectional paths in the protocol makes the > protocol to perform better in such scenarios That's right. But such support is hard (as we have found out in shim6... which only supports this partially). Perhaps more importantly, MOBIKE had a discussion about the unidirectional paths some months ago and made a decision in the WG that we're not doing it. Reasons behind this included toughness of supporting it with NAT traversal, among others. I'd rather not re-open that discussion unless we find a serious problem. We are already aware that we can't support some scenarios due to this - that's fine. -------------------- Tero Kivinen (2005-10-18): https://www.machshav.com/pipermail/mobike/2005-October/001128.html > right, if such path exists Yes. We do assume there is working IP-pair that allows us to get packets in both direction. This does not really matter if this consists of two unidirectional paths, as long as it is routers who take care of that (i.e. not MOBIKE). > It maybe the case, that only disjunct unidirectional paths exists, > because of ingress filters. > In this case, mobike protocol wouldn't achieve to communicate, even if > a path exists, and it would be possible to communicate if the mobike > protocol supported different addresses in the different peers of the > communication If I understand correctly TCP would not work in that case too (i.e. TCP also assumes you can send and receive packets using same IP-pair in both ends, just reverse the IP-addresses). Both TCP or MOBIKE can be made so that they do not really cares which interface was used to send packet out and from which interface it was received, but that is operating system issue, not protocol issue. MOBIKE does not try to work in cases where you need to use different IP-address pair in one direction and another pair to the other direction. > > If it has multiple IP addresses associated to the IKE SA (even before > > it is created) then it should try all combinations of them through the > > normal IKE SA retransmission policy. > > does the IKE SA retransmission policy tries different source addresses? MOBIKE section 4.4. tells what to do if IKEv2 request has been re-transmited several times with no reply, and when initiator decides new address, he should go through all possible address combinations before giving up. -------------------- Tero Kivinen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001233.html Actually I think the design draft should have enough text about this (see section 5.1.2. Connectivity). I do not think we need more than what is now in the protocol draft already i.e: ---------------------------------------------------------------------- MOBIKE follows the IKEv2 practice where a response message is sent to the same address and port from which the request was received. This implies that MOBIKE does not work over unidirectional paths. ---------------------------------------------------------------------- but I would change that to: ---------------------------------------------------------------------- MOBIKE follows the IKEv2 practice where a response message is sent to the same address and port from which the request was received. This implies that MOBIKE does not work over unidirectional address pairs. ---------------------------------------------------------------------- i.e change "unidirectional paths" to "unidirectional address pairs", as we do not really care about paths but address pairs. MOBIKE will work perfectly if even if there is 2 unidirectional paths (if we use the definition of path that includes the route of the packet), which form one bidirectional address pair for MOBIKE to use... -------------------- Francis Dupont (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001236.html => in fact this is more a requirement than a practice... Francis.Dupont at enst-bretagne.fr PS: I am okay for the proposed change. -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001271.html Hmm, you're right... but it's not really the address pair that has the direction. How about this? This implies that MOBIKE does not work over address pairs that provide only unidirectional connectivity. -------------------- Tero Kivinen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001276.html That is fine by me. --------------------