Greg O'Shea writes: Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default, but this behavior MUST be configurable to enable it; [10.4.2] Why is it a good idea for site-local to be configurable? Text elsewhere states that we don't know how to deal with site-local in MIPv6 [4.6, 10.4.2] and I agree with that so for a change I won't bother to point out examples of entanglement. How can we specify configurable use of site-local when we can't specify what could or should happen when it's enabled? Especially when you're multi-homed. For now I think site-local should be out. It can be reviewed e.g. at DS time or better still as a separate doc when we understand what it means. ----------------- Ed Remmell responds to Greg O'Shea: I have identified the following MN use case for site-local scope: "Access Internal System behind Corporate Firewall In some cases, the user wants to communicate with an internal system behind the corporate firewall. The internal system in this case has a site-local scope address. The user has configured (either auto- or manually) a site-local scope address with a matching prefix on their virtual home interface. When they send to the site-local address of the internal system, we will find a prefix match on the virtual home interface, and because the address is site-local scope we will always use the MN-to-HA tunnel to send to that destination. Alternatively, if we don’t find a prefix match but if they specify a source address which is configured on the virtual home interface, that will cause us to select the virtual home interface as the outgoing interface, and then in the virtual device send function on that interface we will see that the destination address is site-local scope and so we must send it using the HA tunnel in this case." So, I think that being able to participate in site-local scope communication with nodes on its home network while the mobile node is on a foreign link is a potentially useful feature that should not be removed. BTW, "virtual home interface" is what we use to store/configure the MN's home addresses on when it is attached to a foreign link. This is associated a virtual device driver, which uses the MN-to-HA tunnel to tunnel packets sent to site-local destination addresses that originate on that interface. We use the source IP address of the packet in our routing decision to select the correct outgoing interface, when mobile node functionality is enabled. Probably more than you wanted to know ;-) ----------------- Jari Arkko responds to Greg O'Shea: This issue too is something that has been debated in the group during the last half a year; a scaled down version of the discussion that was started in the IPv6 working group. We attempted multiple times to try to formulate the spec so that site-locals would work well. This proved quite hard, almost as hard as defining where and how site locals should be used in IPv6. In the end, we decided to make site locals a SHOULD NOT, but still left the door open for adventurous implementors to try it at their own risk. But the text that you quoted is funny -- we would we build support for something that is a SHOULD NOT? I would change the text "... SHOULD NOT be tunneled to the mobile node by default, but this behavior MUST be configurable to enable it ..." to "... SHOULD NOT be tunneled to the mobile node ..." This still leaves the door open to those who want to go there, but doesn't burder the spec with details about what to do for site-locals. Ok? Jari P.S. Ed, you must be an adventurous implementor ;-) P.P.S. Be careful with same addresses in home and visited networks. ----------------- Hesham Soliman responds to Greg O'Shea: What is the operational problem with the text above? We had a long discussion on SLs and this was the conclusion, is something going to break because of this text? ----------------- Greg O'Shea responds to Ed Remmell: Yes, that looks reasonable. I guess more thought on site local is required. Multi-homed with multiple sites using same site-prefix is the challenge. ----------------- Ed Remmell responds to Jari Arkko: > "... SHOULD NOT be tunneled to the mobile node ..." I'm not in favor of this change. I'd like the specification to call for this behavior to be configurable on the HA, which is currently the case: "but this behavior MUST be configurable to enable it". I don't care that the default is to disable tunneling of site-local scope traffic to the MN, just that it is configurable so that it could potentially be enabled later. The rest of the specification seems to permit the usage scenario I described. Section 10.6.1 "Aggregate List of Home Network Prefixes" does not prohibit the home agent from including site-local scope home prefixes in the list of prefixes that it advertises to the mobile node using the ICMP Mobile Prefix Advertisement Message. I do believe the use case I presented is a valid real-world scenario that it would be nice for MIPv6 to support, that of communicating with nodes on your home network over the MN-to-HA tunnel while away from home and those nodes are protected behind a corporate firewall so they can only be accessed using a site-local address. As a MN away from home, you still belong to the site that your home network belongs to, at least it would be nice if you could belong to that site (i.e. over the MN-to-HA tunnel). > P.S. Ed, you must be an adventurous implementor ;-) We want to provide a robust impementation. I think this is a valid use case. One of the reasons given for why L=1 (in the BU) is needed is because in some cases (MLD, DHCPv6) there is link-local scope traffic tunneled over the MN-to-HA tunnel. So, you want to allow link-local scope tunneling but prohibit site-local scope tunneling? It seems like the use of site-local scope home addresses to communicate with peers on your home network is something we should try to support over the MN-to-HA tunnel. > P.P.S. Be careful with same addresses in home and visited > networks. We restrict the MN to using the MN-to-HA tunnel when sending packets that have a site-local scope source address. The intent is to support site-local communication with peers on their home network through the HA. ----------------- Greg O'Shea responds to Jari Arkko: Okay, I had not realized that significant energy had already been spent. But out of curiosity, and without trying to solve the generality of site-locals, I wonder if we can make some simplifying assumptions for MIPv6: 1) we ignore Site-Local foreign nets for purposes of forming CoA, i.e. we only have to consider home SL zones 2) the HA serving the home site-local zone uses its global HA addr to serve SL registrations i.e. the addresses (HA,HoA) known to the MN have scope (global,site-local) respectively. From (2) the MN knows an association between a global prefix and the home SL zone. This allows the MN to disambiguate the home SL zone from a foreign zone using the same SL prefix, which the MN must do in order to known whether it is at home or abroad for its SL HoA. (An IF attached to the home zone will see RA for the HA's global prefix and an IF attached to a different zone with same SL prefix as the home SL zone will not see RA for the HA's global prefix.) This also allows the MN to detect that multiple IF are attached to the home SL zone. It seems that (2) is legit for the HA from 10.3.1 because the SL and global prefix are both onlink to the HA. I guess that was deliberate. But it would alter the current handoff logic to do the (global,site-local) comparison and it would need testing. Personally I hate to see something as loose as the current text in a spec, but I guess you had better leave things as they are until the adventurous have more to report. ----------------- Ed Remmell responds to Greg O'Shea: > 1) we ignore Site-Local foreign nets for purposes of forming CoA, i.e. > we only have to consider home SL zones Section 4.6 already says: "Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses." > 2) the HA serving the home site-local zone uses its global HA addr to > serve SL registrations i.e. the addresses (HA,HoA) known to the MN have > scope (global,site-local) respectively. I'd hesitate to create this artificial restriction. Actually, the home agent address is one of the few addresses in Mobile IPv6 that it makes sense to implement as a site-local scope address. For example, consider wireless service provider that wants to deploy Mobile IPv6 on their network. All of their wireless links could be considered to belong to the same site. In that case, if they make their home agents only accessible via site-local scope addresses in that site, this affords them greater security and control over that part of their network. The site-local scope address prefix has been or is in the process of being redefined to be more like the global scope address prefix, in fact the intent is that the site-local scope prefix for a given link exactly match the global scope prefix assigned to that link (except for the first 16 or so high-order prefix bits, in the site-local scope case "fec0"). > >From (2) the MN knows an association between a global prefix and the > home SL zone. This allows the MN to disambiguate the home SL zone from a > foreign zone using the same SL prefix, which the MN must do in order to > known whether it is at home or abroad for its SL HoA. (An IF attached to > the home zone will see RA for the HA's global prefix and an IF attached > to a different zone with same SL prefix as the home SL zone will not see > RA for the HA's global prefix.) This also allows the MN to detect that > multiple IF are attached to the home SL zone. Please let's avoid trying to solve site-local scope in this draft. Let's wait until implementors have more experience with it. > Personally I hate to see something as loose as the current text in a > spec, but I guess you had better leave things as they are until the > adventurous have more to report. This is my opinion too, although the current looseness w/ regards to site-local doesn't bother me as much. ----------------- Jari Arkko responds to Ed Remmell: > This is my opinion too, although the current looseness w/ regards to > site-local doesn't bother me as much. Yeah. So why don't we stick to SHOULD NOTs in the places that I suggested... that leaves the spec pretty clear and still allows folks to go do their site local stuff if they really need and they understand what they are doing? ----------------- Greg O'Shea responds to Jari Arkko: Okay with me. ----------------- Jari Arkko writes: An additional clarification to the issue. So what we are proposing is *not* to remove the ability to configure the tunneling of site-local addresses. We are removing the *requirement* to do so. Implementors can still use site-locals; just that they have to understand the full implications and carefully weigh the case (see RFC 2119). I think implementors will understand the need to make the forwarding and other aspects of site-locals configurable in their products, right Ed? So, the proposed text change was: "... SHOULD NOT be tunneled to the mobile node by default, but this behavior MUST be configurable to enable it ..." to "... SHOULD NOT be tunneled to the mobile node ..." ----------------- Ed Remmell responds to Jari Arkko: This is (from a purist standpoint) exactly the change I was hoping you would not make to the spec... but: I'm OK with you removing as many features from the specification as you want, it just makes my work (as an implementor) easier because then there is less to implement. I still think I identified a valid use case, but then VPN should allow you to communicate with site-local scope peers on your home network while you are away from home so use VPN w/ IPv6 instead of MIPv6 if you need that functionality. > I think implementors > will understand the need to make the forwarding > and other aspects of site-locals configurable in > their products, right Ed? I'm doing a generic implementation of the MIPv6 protocols, we sell source code not hardware. We don't go off into proprietary-land, so if there is no requirement for a config switch on the HA to enable site-local scope tunneling to the MN we certainly won't bother to have our MN implementation support site-local scope home addresses since that will just increase code size w/out any apparent benefit. I'll update my design document accordingly. ----------------- -----------------