Greg O'Shea writes: I can't see any way of automating selection of L bit or writing reasonable instructions for users who want to set HoA manually. Aside from the multi-homed issue a user might swap PCMCIA or CF adapters, yielding different IFIDs, and yet wish to keep the same HoA e.g. because IPSec is keyed on on HoA. (Maybe that's a good reason for *not* choosing a stateless config addr as your HoA.) But I can't see that v20 says anything about *not* setting L apart from the RFC3041 provision (whose "MUST" strikes me as unecessarily harsh). Therefore one possible tactic might be to set L bit on *all* home bindings. Is that legit, or a swamp? ---------------------- Ed Remmell responds to Greg O'Shea: Very interesting. There appears to be a slight disconnect. From MIPv6 draft 20: " o If the mobile node's link-local address has the same interface identifier as the home address for which it is supplying a new care-of address, then the mobile node SHOULD set the Link-Local Address Compatibility (L) bit. o If the home address was generated using RFC 3041 [18], then the link local address is unlikely to have a compatible interface identifier. In this case, the mobile node MUST clear the Link-Local Address Compatibility (L) bit." RFC-3041 says: "Note: because multiple temporary addresses are generated from the same associated randomized interface identifier, there is little benefit in running DAD on every temporary address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier." I thought the whole point of the L bit is to have your HA defend the link-local scope address associated with your home address (i.e. they both share the same interface ID), just in case some other node on your home network optimizes DAD and only tests the link-local address for duplication and then goes and configures your home address w/out doing DAD. If that is the purpose of the L bit, then from the above RFC-3041 text it is clear that a node that generates a random interface ID per RFC-3041 is likely to optimize DAD, and therefore if you register a RFC-3041 home address with the HA you should set the L bit so it will protect/defend you from this scenario. I was hoping to avoid BED entirely, and just never set the L bit in our MN implementation - since for the other type of interface ID (i.e. a globally unique interface ID formed from an Ethernet MAC address, for example) you really don't need to worry about duplicate address assignment unless there is a systems administration problem on your home network. Based on this, however, I think I need to add back in the capability in our MN public API for the user to have control over setting the L bit, and then when I register a binding with the L bit set, I have the extra hassle of the BED hack when returning home. Of course, there is the other alternative that Pascal Thubert suggested, specifically doing DAD on the MN's home address to resolve the link-layer address of the HA defending the home address. That appears increasingly more attractive ;-) ---------------------- Vijay Devarapalli responds to Ed Remmell: > Of course, there is the other alternative that Pascal Thubert suggested, > specifically doing DAD on the MN's home address to resolve the link-layer > address of the HA defending the home address. That appears increasingly more > attractive ;-) I agree with the last part. this is what I has suggested to a bunch of folks off the list. > I had this long discussion with Nicolas Delest. I think we > like Pascal's suggestion of the MN doing DAD for its own > address. > > 1. MN realizes it is home (by receiving a router advert > with the home prefix) > 2. it sends a DAD probe with source set to unspecified > address and the target set to HoA. Note: this is the > natural behaviour. whenever the MN receives a router > advertisement advertising a new prefix, it configures > an address and does DAD for that address. > 3. the HA responds with a neighbor advertisement. > 4. the MN gets hold of HA's MAC address > 5. the MN sends a deregistration BU. > > ofcourse there is one small hack in the above. the MN > instead of considering the neighbor advertisement from > the HA as a DAD failure, it considers it a DAD success > and proceeds to send a deregistration BU. but IMO, this > is not a big deal. it is a DAD success because, the HA > was defending it so far and now the MN can take over. > (Nicolas convinced me on this). Note: steps 2, 3 and 4 are skipped if the router advertisement was sent by the HA which currently has binding cache entries for the MN. > if the HA were not defending MN's home address (because > the MN was shut off before coming home), then > > 1. MN realizes it is home > 2. MN looks at its binding update list and knows that > the binding at the HA has expired. > 3. does DAD for the home address. > 4. if DAD succeeds everything is fine. if it fails, > then someone on the home link has configured its > address. > > we concluded that there is no need for BED (and therefore > no need for a new ICMP code). I think the above is sufficient. This also solves the issue raised by Greg in another email with subject "MIPv6 v20 Question re returning home NA hack". ---------------------- Ed Remmell writes: Honestly, I think what has happened is that when S=0 was removed the L bit has become a bit of a relic. The original intent of the L bit seems to be (per an earlier email from Brian Haley): "... it's set to allow the HA to derive all your other addresses from your home address." This implies that it was mainly intended for use with S=0, which is now removed from the specification. I had an example to give of a MN setting a random interface ID (per RFC-3041) on an interface, in which case should the BU for a home address formed from that IID be sent with L=1 or L=0 since the home address shares the IID with the link-local scope address auto-configured on the interface, but I've since decided that this discussion is all a moot point because it really seems like there is no point to keep the L bit now that S=0 is gone. The only benefit I can see currently for setting L=1 is that it affords the MN greater protection/defense of its home address when interoperating with nodes attached to its home network that optimize DAD. Since nodes that use RFC-3041 will likely optimize DAD, and since they are picking purely random interface IDs that are more likely to conflict than globally unique IIDs, also since the privacy intent of RFC-3041 has the random interface ID (and the associated home addresses) frequently changing so that a user's Internet activity cannot be tracked, it seems almost useful to set L=1 when registering RFC-3041 generated home addresses to avoid DAD conflicts. almost... not quite. Hopefully the L bit will just go away ;-) I think my MN implementation will just pretend that it has (i.e. always set L=0 in the BU). ---------------------- Vijay Devarapalli responds to Ed Remmell: > I think my MN implementation will > just pretend that it has (i.e. always set L=0 in the BU). which is perfectly acceptable for your embedded systmes implementation. but we are not discussing a specification for embedded systems here. the specification is for most mobile nodes. removing the L bit does not help returning home. here is why... the proposal is > > 1. MN realizes it is home (by receiving a router advert > > with the home prefix) > > 2. it sends a DAD probe with source set to unspecified > > address and the target set to HoA. Note: this is the > > natural behaviour. whenever the MN receives a router > > advertisement advertising a new prefix, it configures > > an address and does DAD for that address. > > 3. the HA responds with a neighbor advertisement. > > 4. the MN gets hold of HA's MAC address > > 5. the MN sends a deregistration BU. steps 2, 3 and 4 are just few more lines of code, which are actually avoided if if the router advertisement (by which the MN figured out it is at home) was sent by the HA which currently has binding cache entries for the MN. If the HA were not defending the link local address the MN has to do the following. 1. MN realizes it is home (by receiving a router advert with the home prefix) 2. MN does DAD for link local address (it cant use the link local address till it does DAD, unless you can be sure that your link local is unique) 3. MN does neighbor discovery to figure out HA's MAC address. source address of NS is link local and target is HA's address. 4. The HA responds with a neighbor advertisement 5. the MN gets hold of HA's MAC address 6. the MN sends a deregistration BU. what did you gain in this? infact the deregistration BU has to wait till DAD for the link local completes. or were you planning to use the link local address without doing DAD for it? I am not sure you can do that, because the MN was off-link and nobody was defending the link local address. ---------------------- Greg O'Shea responds to Ed Remmell: > Hopefully the L bit will just go away ;-) I vote for that: if always L=0 and always L=1 are surfacing as alternative and reasonable behaviours for MN implementations then the feature starts to look extremely doubtful. Aside: another (hopefully moot) point is that my reading of the spec allows an HA to derive and test the LLA even when L=0 is received - it says HA should protect the HoA which doesn't prevent it from protecting the LLA as well. Not that one would, presumably, but one could, so setting L=0 might not get what you expect from the HA. ---------------------- Greg O'Shea responds to Ed Remmell: >> This also solves the >> issue raised by Greg in another email with subject >> "MIPv6 v20 Question re returning home NA hack". Yes, this looks much better than what is there now. >> > 2. MN looks at its binding update list and knows that >> > the binding at the HA has expired. Can it cope with MN rebooting on home net during lifetime of HA binding? ---------------------- Vijay Devarapalli responds to Greg O'Shea: > Can it cope with MN rebooting on home net during lifetime of HA binding? Yes, if the lifetimes are not too long. otherwise we need something new for this. the MN can use RFC 3041 generated home address. or we could have the following 1. MN reboots at home. does not remember if it had a binding at its HA. 2. when the MN receives an RA, it realizes it is at home 3. does DAD for the home address. DAD fails if HA is still defending the MN's address 4. MN cant differentiate between HA defending its address and some other node configuring its address 5. attempts a deregistration with its HA. 6. HA deletes the binding cache entry. if HA was not defending MN's address, it responds with status 133 (Not home agent for this mobile node) 7. if the MN receives a bind ack with status 133, it concludes somebody on the home link has configured its address. The probability of this happening is very remote especially with smaller binding lifetimes. I am not sure it is worth solving this by introducing new mechanisms. ---------------------- Ed Remmell responds to Greg O'Shea: > Aside: another (hopefully moot) point is that my reading of the spec > allows an HA to derive and test the LLA even when L=0 is received - it > says HA should protect the HoA which doesn't prevent it from protecting > the LLA as well. Not that one would, presumably, but one could, so > setting L=0 might not get what you expect from the HA. I expect that if I register with L=0, the HA will not be defending any link-local address associated with the HoA for that registration. If this is not the case, I'd like to know why. When the MN registers with L=0, it is telling the HA that it does *NOT* have configured a link-local scope home address which matches on the interface ID with the HoA that it is registering. The HA should only be testing and defending home addresses that belong to the MN. In this case, the MN has explicitly told the HA that this link-local scope home address is not one of its addresses, therefore the HA should not defend that address. If it does, I'd consider that a broken HA implementation. Granted, if there are other nodes on the home network that optimize DAD, not defending the link-local scope address formed from the same interface ID will be an incomplete defense of the HoA, but then DAD isn't perfect, the range of random interface IDs to use for RFC-3041 addresses is huge so you wouldn't expect conflicts on random interface IDs that frequently, the other style of interface ID is globally unique so you wouldn't expect any conflicts on it, etc. ---------------------- Greg O'Shea responds to Ed Remmell: >> Aside: another (hopefully moot) point is that my reading of the spec >> allows an HA to derive and test the LLA even when L=0 is received - it The spec just needs to be tightened to say what the HA must NOT do when L=0. Strictly speaking this cannot safely be inferred from what it MUST do when L=1. ---------------------- Ed Remmell responds to Vijay Devarapalli: > If the HA were not defending the link local address the MN has > to do the following. > > 1. MN realizes it is home (by receiving a router advert > with the home prefix) > 2. MN does DAD for link local address (it cant use the link > local address till it does DAD, unless you can be sure > that your link local is unique) > 3. MN does neighbor discovery to figure out HA's MAC address. > source address of NS is link local and target is HA's > address. > 4. The HA responds with a neighbor advertisement > 5. the MN gets hold of HA's MAC address > 6. the MN sends a deregistration BU. > > what did you gain in this? I would prefer to use regular Neighbor Discovery procedures whenever possible. In step #2 above, the MN is performing DAD, not Address Resolution. So, the NA response that the HA sends in step #4 is part of DAD processing - I'd prefer not to use it for Address Resolution, which is normally a separate procedure. I'd rather have a little extra latency in the "MN returning home" scenario than make MIPv6-specific changes to Neighbor Discovery. At this point, if the MN needs to deregister, it would be performing Address Resolution on the global scope address of the HA (since that is what it persists in NVRAM), not the link-local scope address of the HA - the Neighbor Advertisement that the HA sends in step #4 isn't even for an address that belongs to the HA (i.e. it isn't the address that the HA uses as a source address when it sends a Router Advertisement), it is for a MN home address that the HA is proxying for. So, using the NA that the HA sends in step #4 to resolve the address of the HA to be able to send a deregistration BU to the HA in step #6 is definitely non-standard w/ regards to Neighbor Discovery. Or, were you expecting that the MN would send the deregistration BU to its own link-local scope home address that it just got the DAD failure for? That is fairly confusing... Also, in a follow-up email you sent, the MN behavior for the case where the HA is still defending its link-local scope home address becomes trickier: > 1. MN reboots at home. does not remember if it had a binding > at its HA. > 2. when the MN receives an RA, it realizes it is at home > 3. does DAD for the home address. DAD fails if HA is still > defending the MN's address > 4. MN cant differentiate between HA defending its address > and some other node configuring its address > 5. attempts a deregistration with its HA. > 6. HA deletes the binding cache entry. if HA was not > defending MN's address, it responds with status 133 (Not > home agent for this mobile node) > 7. if the MN receives a bind ack with status 133, it > concludes somebody on the home link has configured its > address. As Greg O'Shea suggested, I'd like to see some explicit text in the MIPv6 specification that states that if the MN registers a binding with L=0, the HA MUST NOT defend the link-local scope address corresponding to the home address in the binding. I do not see much benefit (anymore - at least not since S=0 was removed) to having the HA defend the MN's link-local scope address, and I'd prefer for the MN to have control over whether or not this occurs (so that I can permanently disable it in our embedded systems MN implementation, and not have to worry about special recovery logic for the scenario of the HA defending the MN's link-local scope address causing MN DAD failure when returning home). ---------------------- Ed Remmell writes to Jari Arkko: Please consider adding the following to the specification: > As Greg O'Shea suggested, I'd like to see some explicit text in the MIPv6 > specification that states that if the MN registers a binding with L=0, the > HA MUST NOT defend the link-local scope address corresponding to the home > address in the binding. I'd like it to be possible to have a simple MIPv6 MN implementation which always registers with L=0 and which doesn't have the ND hacks to recover from the situation of returning home when the HA is still defending the MN's link-local scope home address (which it should not be doing when the MN registers with L=0). I'm planning on implementing it this way anyways, but the problem is that currently if the HA does conflict on the MN's link-local scope home address when the MN returns home, the user application will need to do the recovery by handling the DAD failure (we provide a callback notification) and changing temporarily the interface ID to a random interface ID that doesn't conflict to be able to do the NS/NA exchange on the HA's global address to be able to send the deregistration BU - that does make my example code ugly, to need to handle this special case. ---------------------- Jari Arkko writes: It seems that most people wanted to at least make sure that the semantics of L=0 are clear in that the home agent will not be able to defend the link-local version. If it did, a mobile node that used L=0 could still get a DAD failure when using its link-local address on the home link. I think we can make this clear by having the following item in 10.3.1 (home agent's procedures for processing binding updates): " o L=0: Defend only the given address. Do not derive a link-local address. " We also discussed whether keeping the L bit makes sense after the other modifications to the specification. I still think it makes sense, because of the possibility of nodes who optimize DAD by checking just the link-local address. The L bit allows us to avoid this case. As for the potential DAD misses with RFC 3041 -- I agree, that RFC also appears to optimize DAD by skipping some of the tests. But I fear there's little we can do about this in Mobile IPv6. Let's leave that for IPv6. ---------------------- Greg O'Shea responds to Jari Arkko: Ok with me. ---------------------- Ed Remmell responds to Jari Arkko: Yes, I'm in complete agreement with all of this, thank you for paying attention to my concerns w/ regards to the L bit. ---------------------- ---------------------- ---------------------- ---------------------- ---------------------- ----------------------