Hi Ran, sorry for the confuse, I was referring to my proposal http://tools.ietf.org/html/draft-frejborg-hipv4-06
I have proposed a 4 x 4 bytes addressing scheme to get more space. I took the freedom and added your 32 identifiers to the second frame in the document, see attachment - we can call this ILNPv4, hIPv4 is anyway a cumbersome acronym... So with the hIPv4 header you have more IPv4 address space and the identifier functionality that exists in ILNP can be used, e.g locator translation (rewrite) can be applied without that the transport checksum changes. And this is can be made compatible with CES solutions, if the CES people will implement this functionality in their nodes. I have also a use case where I need a Public Locator Referral, instead I could use ILNPv4 locators to get the rewriting/translation done at a middlebox. May I carry out investigation around the 32-bit identifier and try to add ILNP functionality to the hIPv4 framework (the name should be changed anyway) to see where it goes? About the current deployed stack - you are right, there is a lot of shipped IPv6 stacks but best current practise is to turn that of because otherwise there is security risk that you get hacked on a public network by leaving the IPv6 door open since most likely your personal firewall will offer no protection. -- patte On Fri, Apr 23, 2010 at 9:09 PM, Ran Atkinson <[email protected]> wrote: > > Earlier, Patrick Frejborg wrote: >> Ah, then ILNPv4 and hIPv4 are not that far from each other... > > Correct, and that is not a coincidence. Both HIP and ILNP > have their roots in the IRTF NSRG. There are limited ways > to use off-the-shelf mechanisms to carry identifiers in IPv4. > The ILNP designers have gone to some lengths to document > that HIP-like mechanisms could fit inside the architecture > (NB: This required no protocol changes in ILNP, just clarity > of documentation.) > > Multiple ILNP papers have made it clear that one can also > use a cryptographically-generated ID with ILNP. That might > be a CGA-like thing. It also could be a HIT-like thing. > > (As a user, I do NOT want to use cryptography on all or > even most of my packets, so I find that HIP's focus on > cryptography isn't well aligned with my personal operational > requirements. Other folks mileage may vary. Similarly, > I find the CGA arguments non-persuasive and would not want > to use a CGA for my own packets. ILNP leaves the ID > generation flexible, so users can make choices sensible > for local environments.) > > Later, he wrote: >> ...give them options go either to IPv6 (ILNP) or >> to something that is backwards compatible with >> the current deployed stack. > > ILNP already *IS* backwards-compatible with the current > deployed stack. So the quoted phrase, especially the word "or", > is very confusing. > > RFC-1687 says many things (e.g. convergence with ISO CLNP > would be nice). It wasn't obvious which part of that RFC > Patrick was referring to. > > Yours, > > Ran > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg >
The header of a hIPv4 packet 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 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|P|S|VLB|L| R | Protocol | LH Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Locator Referral | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Removing Private Locator Referral and adding ILNPv4 32 bit identifiers 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 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|P|S|VLB|L| R | Protocol | LH Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
