Mobile IPv6 identifies each node by its unchanging global home address, regardless of its current point of attachment to the Internet
While a mobile node is away from home it sends information about its current location (I.e. primary care-of address) to a home agent on its home link
The home agent intercepts packets addressed to the mobile node’s home address and tunnels them to the mobile node’s current location (I.e. primary care-of address)
Mobile IPv6 Triangular Routing IPv6 Network HA Visited Network Home Agent The mobile node’s home address is associated with the home agent Mobile Node With a care-of address Correspondent Node That is communicating with the mobile node Home Network
Mobile IPv6 Route Optimization IPv6 Network HA Visited Network Home Agent The mobile node’s home address is associated with the home agent Correspondent Node That is communicating with the mobile node Mobile Node With a care-of address Home Network
16 events, 9 states to manage CN registration (BUL entry)
Some of the state machine design was in an earlier MIPv6 draft, but removed in draft 18. This state machine can be found in open source implementations of MIPv6 (such as KAME). However, it combines MN home registration (with HA) and CN registration (for route optimization) in the same state machine.
We have two separate state machines for mobility bindings:
One for managing home registration
The other for managing CN registration (BUL entry)
Result: an easier to understand and more robust implementation
Don’t use separate state machine to manage Return Routability
Instead this is part of our CN registration (BUL entry) state machine
Special state ‘disabled’, we transition a CN registration (BUL entry) to when we determine a specific CN does not support route optimization. To avoid DoS attacks, once we’ve successfully registered binding with specific CN, we can never enter ‘disabled’ state, so the transition to ‘disabled’ can only occur on initial registration.
When a mobile node comes back on-link it notifies TCP of L2 handover. TCP then performs the recovery:
TCP was sending data, and was trying to retransmit: if TCP had gone into retransmission timeout during off-link condition, then upon coming back on-link TCP immediately retransmits one segment of unacknowledged data. This enables TCP to not be penalized (as much) by exponential backoff on retransmissions. Note, when TCP (re)transmits packets while MN is off-link, these packets are not queued but instead are discarded – this avoids MN queuing up duplicates of retransmitted packets to send once it is back on-link.
TCP receiver (peer TCP was sending data): the peer might have tried to send data while we were off-link, and we did not receive that data. So, TCP upon coming back on-link sends 3 duplicate ACKs to activate remote Fast Retransmit algorithm.
Elmic Features and Benefits Optimized for even small industrial control devices not needing any RTOS Runs with (or) without RTOS Code has small footprint, low latency, efficient memory usage Written specifically for embedded systems High performance True Zero-copy Assures a quality stack product Extensive internal and external testing of the stack Stack performs well on any chip or reference design Platform and RTOS Independent Robust full-featured implementation 100% RFC Compliance Benefits Features