Samita Chakrabarti: 8. Can a HA be a CN to the same mobile node ? Problem scenario: 1. A node acts as both HA and CN 2. A MN sends RR messages and does BU with H=0 to this node. (pressumably it had been using a different HA) 3. The same MN sends BU H=1 to the same HA/CN node Should this HA/CN node accept or ignore the second BU ? Or Should this HA/CN delete the old BCE and create a new BCE and also starts acting as HA. Proposal : For simplicity, it's better for HA to ignore the second BU. [ Otherwise, the combination of HA/CN and order of H bit (0/1) in successive BUs make implementation unnecessary complex ] -------------- Jari Arkko responds to Samita Chakrabarti: I agree. Add text to 9.5.1 where we talk about the conditions for BUs that use RR as the authz mechanism: "If receiving node is also acting as a home agent, it does not have a home registration Binding Cache entry for the given home address." This will lead to silent discard. Hmm... but wait. This isn't quite sufficient. It wouldn't work in the order of your example above. Also, following your order, how does the receiver know in Step 2 that it will act as a home agent in Step 3? Perhaps it is pre-configured with the home addresses... but even so, what if there are multiple redundant home agents? If I register with one of the for H=1, does it imply that I can do RR with the others, in case they also host a web server or something? -------------- Ed Remmell: To avoid confusion, I'd require that a node acting as a home agent MUST NOT respond as a correspondent node on any address on which it is responding as a home agent. In this case, if the home agent receives a HOTI or COTI message on one of its home agent addresses requesting it to participate in the Return Routability procedure, it MUST silently discard the HOTI/COTI messages and not respond. Note that if it did respond by sending back a Binding Error status 2 "Unrecognized MH Type value", this could potentially confuse a MN implementation if the MN is refreshing its home registration binding at the same time, and cause the MN to mistakenly drop/deregister its BUL entry for its home registration. So, it is better for the home agent to just silently discard in this case. I guess the same confusion could occur in some MN implementations if the home agent were to reply with a ICMPv6 Parameter Problem error code 1 "Mobility Header protocol not supported" message. -------------- Brian Haley responds to Jari Arkko: I'll try and clarify. What does the receiver do if they have a binding, and get a BU to update that binding with a different value in the H-bit field than the current binding? The MN shouldn't have sent it since it should know from its binding list what "state" your binding has, but it did. -------------- Jari Arkko responds to Brian Haley: Ok. That sounds good. So we would add a rule that a BU should not change the H-bit value in a binding? And if you break the rule, its a silent discard? -------------- Charlie Perkins responds to Jari Arkko: It should not be a silent discard. There should be an error returned indicating the problem. -------------- Vijay Devarapalli responds to Charlie Perkins: it is a bug in the MN implementation if it didnt compare the flags in the current BU with the previous BU sent to the same CN/HA. do we need an error message? -------------- Charlie Perkins responds to Vijay Devarapalli: The alternative is that the benighted MN will just keep trying! -------------- Brian Haley responds to Jari Arkko: I would send an error in a BA. But we do not delete the current binding, just wait for the MN to respond accordingly since it just re-synchronized itself with us. -------------- Samita Chakrabarti responds to Jari Arkko: We have discussed the situations at the Connectathon and it could be quite complex with the order of H bits ( 0, 1 or 1, 0 ) and then whether its HA and CN at that point for the MN. Also you brought up interesting question about multiple HAs while one being HA for MN1, the other non-active HA is acting as CN for the same MN1. Would it make sense then to impose a rule like the following ? * If the node is acting as HA for a particular mobile node and it receives a BU with H=0 for the same mobile node, the second BU is silently discarded. This would imply that a node cannot act as both HA and CN for the same mobile node home-address. Also, I need to check if the draft has any wording about handling HOTI messages from the same home-address it's serving as HA. To me it does not make sense for HA to act as CN for the same MN. * Similarly, it is just simple to say that a node serving as CN for a MN (with route optimization and thus having a corresponding BCE with H flag =0) should ignore a subsequent BU with H flag=1. Thus if a MN decides to make the current serving CN as its HA, it must de-register first from the CN and start with a new HA registration. Generally CN/MN nodes or CN only node always rejects BU with H =1, so it's not an issue with them. Question remains should (do) we allow a node to configure to do HA and CN operations at the same time (even if we apply the first bullet rule above) ? I suppose the spec may not want to disallow this feature provided the first rule is applied. -------------- Samita Chakrabarti responds to Brian Haley: > I would send an error in a BA. But we do not delete the current > binding, just wait for the MN to respond accordingly since it just > re-synchronized itself with us. In order to make it simple, I'd vote for ignoring the BU in the second case(i.e, silent discard). The BCE remains unchanged until the MN sends a correct BU or it expires. The possibility of occurence of this kind of mistake by a MN seems to be very small. -------------- Jari Arkko responds to Samita Chakrabarti: I'm happy with this. -------------- Jari Arkko writes: Meeting results: Most people seem to agree that this is an issue. An error return is preferred. There's a question from Michael Thomas on whether the CN->HA transition might actually be legal. Official minutes from IETF-56: 273 - can a HA be CN at the same time? Suggestion: ignore a new BU with a different H value Hesham: This seems like a bug in the MN, maybe an error message should be sent CP: I would like to suggest the same. MT: Should CN->HA actually be illegal or is there a real situation where this could occur. JA: Could always delete the old entry before sending new binding. JA: It's clear that this is an error condition. -------------- Jari Arkko writes: Here's a proposal to close issue #273, what to do if CN becomes a HA or the other way around. In IETF-56, the consensus was that this is an issue, and that if the peer refuses to make the transition, it should send an error message. Mike Thomas asked whether it would make sense to allow CN->HA transitions. In principle yes, but I'd like to avoid that if at all possible, because it would create a special case in the text. The proposed text changes are: Add a new status code in Section 6.1.8 (BA): 139 Registration type change disallowed Add the following to Section 9.5.1 (BU processing): If a binding already exists for the given home address, and the its home registration flag has a different value than the Home Registration (H) bit in the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 139 (registration type change disallowed). Also change the paragraph about the silent discard as follows: For packets carrying Binding Updates that fail to satisfy all of these tests for any reason other than insufficiency of the Sequence Number, registration type change, or expired nonce index values MUST be silently discarded. My understanding is that we don't need to change the mobile node section due to this. Mobile nodes have BULs and should not change the type of registration just like that. -------------- Samita Chakrabarti responds to Jari Arkko: The change looks good to me for CN->HA for the already existing BCE. Should not we make similar restriction for HA->CN for the already existing BCE ? -------------- Jari Arkko responds to Samita Chakrabarti: Section 9.5.1 is referenced from the HA processing, so I think that the text I sent out applies also for HAs. -------------- Samita Chakrabarti responds to Jari Arkko: Ok. That clarifies. BTW, I was wondering if it makes sense to state in words that HA<->CN conversion for the existing Binding is not allowed ? In light of our current knowledge, the text is quite obvious, but I was thinking if it would be easier to specify that restriction in words for future clarity. -------------- Jari Arkko responds to Samita Chakrabarti: Ok, added. New text: "... The home registration flag stored in the Binding Cache entry MUST NOT be changed." -------------- Samita Chakrabarti responds to Jari Arkko: I like this better Thanks. -------------- -------------- -------------- --------------