Ran, I think some of the confusion surrounding the details of ILNP are the result of my presentation of your slides in Dublin. Specifically, although I might not have said that ILNP *mandates* that applications adopt a new API, I'm pretty sure I suggested that it was a very good idea (and although I don't believe that apps *have to* use the new API, to realize the benefits of ILNP, at a minimum I think the current socket API implementation needs to change).
Another point I made, in response to a question as to how two nodes simultaneously moving could maintain communication, is that the DNS can be thought of as a mobility rendevous service. So in this instance, feel free to blame the messenger! More comments below. On Sat, 2008-10-04 at 14:56 -0400, RJ Atkinson wrote: [snip] > % I recall a lot of discussion about the problem of ensuring 64 bit > % identifiers are unique in the world. Your proposal (page 4) does > % not ensure an identifier is unique, except in the scope of a 64 bit > % identifier. > > [draft-rja-ilnp-intro-01, pages 4 and 5] > > I have consistently said for ~15 years now that identifiers > are not required to be globally unique, but that instead the > functional requirement is to have "probably unique" IDs. > > HIP is taking roughly the same position. HIP identifiers can > collide (e.g. due to a hash collision). As with ILNP IDs, > such a collision is unlikely. > > If one wants a globally-unique ID, this is straight forward to > obtain from any system with an IEEE Ethernet or Firewire > interface. In this case the scope bit of the EUI-64 is set to > "global". [draft-rja-ilnp-intro-01, pages 4 and 5] > > If one wants anonymous IDs, with the increased probability of > collision manual selection implies, that can be done by setting > the scope bit to "local" and generating 62 bits in whichever way > one chooses. aka RFC 3041. > Similarly, one can have an ID that is derived from the hash of a > public-key, as HIP does, by setting the scope bit of the EUI-64 > to "local". Again, since there are 2 reserved bits in an EUI-64, > one has 62 user-selected or hash-output bits left. > > (In fact, I think ILNP can be engineered to provide all of the > capabilities of HIP as a deployment option. Both HIP and ILNP > were born in the IRTF Namespace RG. Both were significantly > influenced by the earlier GSE work by O'Dell. So the > similarities between ILNP and HIP are not at all surprising. > There are also some obvious design differences. :-) As we have discussed, I don't think the major concern is the probability of accidental identifier collision, but instead the possibility of identifier spoofing as a means to launch DoS attacks. In ILNP identifiers are much easier to spoof than addresses in IPv4 or IPv6. With that said, there is more than one way to protect against this, some of which might affect the protocol specification, and some of which are purely implementation tricks. [snip] > % I think this means that you can't support multihoming or > % whatever benefits for communications with non-upgraded hosts. > > (I am unable to really understand/parse/lex the quoted sentence > above. Terribly sorry.) > > Communications with existing nodes works the same as it does > today. Communications with existing nodes is no worse than at > present, which is the functional requirement here. Well, to be fair, communication between an ILNP node and a non-ILNP node, where the ILNP node has PA locators, wouldn't work as well as communication between two nodes each with PI addresses. The aspect that I especially appreciate about ILNP, however, is that, like TCP SACK, or ECN, or SHIM6, or HIP, it is relatively cheap to deploy locally, and benefits accrue to any two communicating hosts which both support it, without requiring changes in the core infrastructure, and without degrading communications with non-ILNP nodes. This was not true of GSE. Regards, // Steve -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
