Hi Ran, A lurker kindly sent me a copy of the paper I think you were referring to:
> A more detailed explanation of ILNPv4 is in the peer-reviewed > paper published in Telcommunications Systems. http://www.springerlink.com/content/83546636m483u377/ R. Atkinson, S. Bhatti, S. Hailes, ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming, Telecommunication Systems, vol. 42, no. 3-4 pp273-291. [Springer] Dec 2009. ISSN 1018-4864 print / 1572-9451 online. It is over 13,000 words, which is fine by me - this is a complex field. Just don't give me a hard time in the future for writing in detail about Ivip or anything else. I haven't read this yet, but below my signature is the section which appears to be relevant to ILNP for IPv4. - Robin 5.2 Retro-fitting IPv4: ILNPv4 ------------------------------ ILNP could also be implemented as a set of modifications for IPv4, giving ILNPv4. Here, the IPv4 addresses would become the Locators and separate Identifiers would be carried in a new IP option. As with the previously described IPv6-centric approach, all of the transport-layer state would be bound to the Identifiers and a new session mapping table would be added to the IP layer in host implementations. Similarly, one could optionally carry a nonce in an IPv4 option to provide light-weight protection against off-path attacks. Mobility and multi-homing would work as described previously and would bring the same benefits. This would provide many of the same architectural benefits as the IPv6- oriented approach in ILNPv6. A possible realisation of a ILNPv4 header is shown in Fig. 6. If the IPv4 address field in the IPv4 header were reused for ILNPv4, the current IPv4 address prefix would be used as the Locator, and the host part of the IPv4 address would be ignored. Again, this would mean that there is virtually no impact on routing ILNPv4 packets through an existing IPv4 core. For ILNPv4, ARP would need to be modified to use the combination of the ILNPv4 Locator and the Identifier. So, the edge router at the final hop, as well as dual-stack IPv4/ILNPv4 hosts in the subnetwork, would need to know when to send a normal IPv4 ARP and when to send a modified ILNPv4 ARP. If the full 32-bits of the IPv4 address were used for ILNPv4 Locator values, then the lifetime of the IPv4 address space potentially could be prolonged. Of course, there is the possibility of confusion here, with ambiguities between a 32-bit value being a ILNPv4 locator or a normal IPv4 address for a node interface. Practical considerations (e.g. limited IPv4 option space, routers that forward IPv4 packets with options via the slowpath) reduce the value proposition of ILNPv4, compared with ILNPv6. However, we feel that a proof of concept implementation of ILNPv4 should be possible with approximately the same effort as ILNPv6. Fig. 6 ILNPv4 packet header with optional Nonce 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|IHL=12 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OT=ILNPv4_ID | OL=5 | Padding=0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lower 32 bits of nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL: Internet Header Length OT: Option Type OL: Option Length _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
