Continuing from Ran's message "Re: [rrg] Proposal for recommendation
language - ILNP & IPv4".
Short version: Ran indicates that ILNP for IPv4 will use separate
headers to convey the Identifier and other items
such as a nonce. The IP header will contain 32
bit IP addresses which function as a Locator.
Details remain unclear - but are apparently
explained in a paper which is not freely available.
If this arrangement can be shown to work, then
my previous critique about each multihomed end-user
network which currently has N IP addresses for N
hosts requiring, in total, 3*N global unicast
addresses (N in ISP-A and N in ISP-B, plus N in
for its own IP addresses) does not apply.
This approach would be significantly different from
the IPv6 approach. So whatever claims are made
about ILNP in IPv6 don't necessarily hold for its
application to IPv4.
If you accept making packets longer with an extra
header, and accept the need to upgrade the stacks
of all hosts, then many things become possible.
However, if ILNP is to work with ordinary
applications, then it seems that it is stuck with
a 32 bit limitation on Identifier. (As best I can
guess how it might work.)
I suggest that if we are going to require stack
upgrades to all IPv4 hosts, then many other things
are open for consideration too. I recall that
HIPv4 involves stack and I think application
upgrades. How would ILNPv4 compare with HIPv4?
Ran, I understand you have read all the relevant
research literature, which includes Patrick
Frejborg's work on HIPv4. Can you give an account
of the commonalities and differences between ILNP
for IPv4 and HIPv4?
Hi Ran,
You wrote:
>> How would ILNP work with the 32 bits of IPv4 address split between
>> Locator and Identifier? As far as I know, this is not documented
>> anywhere.
>
> See draft-rja-ilnp-dns, which makes clear that the 32-bits
> is the Locator value (L32). As we've discussed on this
> list (both historically and recently) there are a variety
> of ways that one can engineer the transport of an Identifier
> (and a Nonce for that matter).
>
> A more detailed explanation of ILNPv4 is in the peer-reviewed
> paper published in Telcommunications Systems.
OK - this is:
http://www.springerlink.com/content/83546636m483u377/
Please email me a copy of the paper. I don't feel inclined to pay
$34 to read it.
I understand then that ILNPv4 involves attaching an extra header to
all packets at the sending host, and having this transported to the
destination host. The full 32 bits of the existing IP header is used
as a "Locator" - so a single router on a single IP address can
therefore handle packets for any Identifier - and for any number of
hosts with different identifiers.
I assume you would use more than 32 bits for Identifier. I will
assume 64 bits for this discussion.
This is completely different from the way Locator and Identifier are
placed in packets in ILNPv6. The description you have given here is,
AFAIK, the best description to date in the RRG list.
If you can do this, which depends on the nature of your new header,
then it should work fine. You are effectively creating a new address
space, new namespace or whatever you like to call it for host
Identifiers. Then the existing IPv4 address space is used by the
border routers of ISPs or other networks.
To use this, hosts need new stacks. Are you planning on this working
with existing applications?
This appears to be a significantly different arrangement to that of
ILNP for IPv6. So whatever claims are made for ILNP for IPv6 would
need to be carefully re-evaluated in terms of however it is to be
implemented for IPv4.
> This is an IRTF Research Group. Unlike the IETF, the IRTF
> expects that participants already know the RG topic very well,
> and that participants WILL take the time to read the relevant
> research literature.
This is an unsupported assertion. Where in the IRTF rules is this
stated?
You expect me to know how ILNP for IPv4 will work and you have
previously claimed that you have explained it to me before - but you
haven't. You can't expect me or anyone else to read all the papers
listed at your site:
http://ilnp.cs.st-andrews.ac.uk/
some of which go back to 2004, just to understand your proposal.
This is especially the case if the papers are not freely available.
It is reasonable to expect anyone interested in your proposal to read
the Internet Drafts, summaries etc. you post to the list. People
can't be expected to keep up with every update to these, but I did
read your I-Ds at the start of the year and made a concerted attempt
to understand your proposal then.
> ILNP is VERY well documented in the
> peer-reviewed research literature. Most of those papers
> are available online in PDF at well-known URLs.
Please make the above mentioned paper available on your site, or
email it to anyone on the list who wants to read it.
> When time permits, I intend another pass at updating the
> various draft-rja-ilnp-* I-Ds. (NB: Time I spend on this
> list is time not available to do such updates, and my paid
> job does not include any of this.)
OK - I know it is hard to keep up documenting things, since the
proposal does develop and it is a lot of work discussing things on
the list, developing ideas, writing them up in a consistent manner etc.
>> This is not a society, but if you want your ideas to be properly
>> understood and respected - and if you want to find out any
>> shortcomings they may have - then you will debate them patiently and
>> in detail with people who provide critiques.
>
> Wrong. This is NOT a debating society.
I wrote it is not a society. I asserted that in order to have your
ideas understood and respected you need to engage in patient and
detailed debate, including making information about your proposal
freely available. I stand by this assertion. You have an
understanding of how ILNP will work for IPv4 but it seems no-one else
does. If you explained it on the list, or in an I-D, we would all be
able to understand it without too much fuss.
> It certainly is
> NOT incumbent upon anyone to debate anything with anyone.
Sure - no-one is obligated to do so. Its just that if you want your
proposal to be widely understood and respected, as far as I know,
there is no alternative to patient and detailed discussion and debate.
> RGs are not setup as debating forums.
Yet they are forums in which debate frequently does occur. You seem
to be avoiding debate and discussion - instead expecting people to
already understand what is in your mind and which may be documented
in some paper linked to from your site.
> The way that one gets ideas properly reviewed, understood,
> and respected in the research world (and an IRTF RG by
> definition IS in the research world) is to publish papers
> in the peer-reviewed research literature. We've done that
> with ILNP, and we have been doing that with ILNP since LONG
> before this RG was re-focused onto this topic.
Sure - and some important aspects of your proposal are not understood
by many RRG participants despite us going to some trouble to do so.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
