Subject: Re: [rrg] HIP & ILNP

From: Ran Atkinson <[email-masked]>
Date: Fri, 23 Apr 2010 14:09:19 -0400

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

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 23 Apr 2010 23:23:38 +0300

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-masked]> wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>