Repository navigation
mipv6: intercept packets for an absent mobile node on its home link #1268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
ecfcc47
64e8dcc
3484020
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -725,6 +725,11 @@ void Mipv6::processBUMessage(Packet *inPacket, const Ptr<const BindingUpdate>& b | |
| // of course this is also true for CNs | ||
| destroyTunnelFromTrigger(HoA); | ||
|
|
||
| // ...which on the home link means giving the home address back to the | ||
| // mobile node, that being where it has just returned to | ||
| if (rt6->isHomeAgent()) | ||
| stopInterceptingForHomeAddress(HoA); | ||
|
|
||
| // A correspondent node inserts the Type 2 Routing Header for this home | ||
| // address based on its route-optimization state (see datagramLocalOutHook), | ||
| // not on the binding cache, so that state must be dropped here too -- otherwise | ||
|
|
@@ -884,6 +889,13 @@ void Mipv6::processBUMessage(Packet *inPacket, const Ptr<const BindingUpdate>& b | |
| destroyTunnelForEntryAndTrigger(HA, HoA); | ||
|
|
||
| createTunnel(NORMAL, HA, CoA, HoA); | ||
|
|
||
| // The tunnel only carries what already reached this home agent. Traffic | ||
| // from a host on the home link is resolved by Neighbour Discovery there | ||
| // and never routed, so intercepting it takes a second step -- and only | ||
| // for a home registration, which is what the standard keys the check on. | ||
| if (homeRegistration) | ||
| startInterceptingForHomeAddress(HoA, existingBinding); | ||
| } | ||
| else { | ||
| // we first destroy the already existing RH2 path if | ||
|
|
@@ -2803,6 +2815,40 @@ void Mipv6::handleBULExpiry(cMessage *msg) | |
| } | ||
| } | ||
|
|
||
| void Mipv6::startInterceptingForHomeAddress(const Ipv6Address& HoA, bool existingBinding) | ||
| { | ||
| /*10.4.1 | ||
| While a node is serving as a home agent for some mobile node, the home agent | ||
| uses IPv6 Neighbor Discovery [18] to intercept unicast packets on the home link | ||
| addressed to the mobile node. In order to intercept packets in this way, the | ||
| home agent MUST act as a proxy for this mobile node and reply to any received | ||
| Neighbor Solicitations for it.*/ | ||
| NetworkInterface *homeLink = rt6->findOnLinkInterface(HoA); | ||
|
|
||
| if (homeLink == nullptr) { | ||
| // Every home agent advertises the home prefix, so this means the home address | ||
| // does not belong to a prefix this node serves. | ||
| EV_WARN << "Home address " << HoA << " is on-link on no interface; not intercepting for it\n"; | ||
| return; | ||
| } | ||
|
|
||
| ipv6nd->addProxyAddress(homeLink, HoA); | ||
|
|
||
| /*10.4.1 | ||
| [...] subsequently it MUST multicast onto the home link a Neighbor Advertisement | ||
| message [18] on behalf of the mobile node.*/ | ||
| // Only for a binding that did not exist before. A binding that is merely being | ||
| // refreshed, or moved to a new care-of address, changes nothing on the home link: | ||
| // its neighbours already resolve the home address to this home agent. | ||
| if (!existingBinding) | ||
| ipv6nd->sendUnsolicitedNa(homeLink, HoA); | ||
|
Comment on lines
+2843
to
+2844
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🔴 Home-link takeover advertisement skipped after registration change When a home registration replaces a non-home binding, Learn moreA home agent accepts a Binding Update without the Home Registration flag and stores it through addOrUpdateBC. Example: A home-link host caches mobile node M's MAC. The home agent first receives a non-home binding for M's address, then M registers that address as its home address while away. The proxy answers new solicitations, but the host continues sending to M's old MAC. Recommended fix: Capture the previous entry's Was this helpful? React with 👍 or 👎 to provide feedback.
Comment on lines
+2843
to
+2844
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🟡 Takeover advertisement precedes home-address verification For a new binding, Learn moreA new home binding takes the Example: A second node still owns the requested home address on the home link. The home agent announces its own MAC for that address immediately, and a neighbor replaces its existing MAC mapping before the delayed acknowledgement. Recommended fix: Defer starting proxy service and sending the takeover advertisement until the new binding's home-link duplicate check has completed successfully. Keep the acceptance and failure paths consistent so a failed check does not leave a proxy or tunnel behind. Was this helpful? React with 👍 or 👎 to provide feedback. |
||
| } | ||
|
|
||
| void Mipv6::stopInterceptingForHomeAddress(const Ipv6Address& HoA) | ||
| { | ||
| ipv6nd->removeProxyAddress(HoA); | ||
| } | ||
|
|
||
| void Mipv6::createBCEntryExpiryTimer(const Ipv6Address& HoA, NetworkInterface *ie, simtime_t scheduledTime) | ||
| { | ||
| cMessage *bcExpiryMsg = new cMessage("BCEntryExpiry", MK_BC_EXPIRY); | ||
|
|
@@ -2844,6 +2890,10 @@ void Mipv6::handleBCExpiry(cMessage *msg) | |
| destroyTunnelFromTrigger(bcExpIfEntry->HoA); | ||
| removeRouteOptimizationForTrigger(bcExpIfEntry->HoA); | ||
|
|
||
| // an expired binding is no longer a reason to answer for the home address | ||
| if (rt6->isHomeAgent()) | ||
| stopInterceptingForHomeAddress(bcExpIfEntry->HoA); | ||
|
|
||
| // and remove entry from list | ||
| cancelTimerIfEntry(bcExpIfEntry->dest, bcExpIfEntry->ifEntry->getInterfaceId(), KEY_BC_EXP); | ||
| // deletion of the message already takes place in the cancelTimerIfEntry(.., KEY_BC_EXP); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 Old home link keeps proxying moved address
When a home prefix moves between interfaces,
startInterceptingForHomeAddressadds the new proxy without withdrawing the old one. The home agent keeps answering solicitations on the former home link, where its tunnel still intercepts traffic.Learn more
Proxy registrations are keyed by interface and address in proxyAddresses. findOnLinkInterface can select a different interface after advertised prefixes are changed. A refreshed Binding Update calls
addProxyAddressfor the new interface, but the previous registration and multicast membership remain; the home agent answers Neighbor Solicitations on both links.Example: The home agent initially advertises M's home prefix on eth1 and later moves it to eth2. A subsequent Binding Update adds proxying on eth2 while eth1 still answers solicitations for M's address.
Recommended fix: Before changing the home-link proxy, withdraw the previous interface's proxy registration for that address, or make the proxy update operation atomically move the registration to the selected interface. Retain the no-extra-advertisement behavior only when the existing proxy is already on the selected interface.
Was this helpful? React with 👍 or 👎 to provide feedback.