Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

[Saleem Bhatti <[e-mail]>]

Tom;

> On 30 May 2018, at 20:23, Tom Herbert <[e-mail]> wrote:
> 
> On Wed, May 30, 2018 at 12:08 PM, Saleem Bhatti <[e-mail]> wrote:
>> 
>> 
>>> On 30 May 2018, at 20:01, Tom Herbert <[e-mail]> wrote:
>>> 
>>> On Wed, May 30, 2018 at 11:48 AM, Saleem Bhatti <[e-mail]> wrote:
>>>> Behcet;
>>>> 
>>>> On 30 May 2018, at 19:35, Behcet Sarikaya <[e-mail]> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, May 30, 2018 at 1:28 PM, David Allan I <[e-mail]>
>>>> wrote:
>>>>> 
>>>>> The only network upgrade for ILNP is DNS support for RFC 6742, which is
>>>>> believe is already deployed.
>>>>> 
>>>> 
>>>> I am not sure about deployed but maybe defined is better.
>>>> 
>>>> 
>>>> If you are running the most recent version of BIND, KnotDNS, or NSD, then
>>>> they support RFC6742 out-of-the-box, as far as I know.
>>>> 
>>> The more relevant question would be which host OSes support ILNP.
>> 
>> Currently, probably about the same number as the networks that support ILA ;-)
>> 
> Saleem,
> 
> I'm not sure how to interpret your response. ILA has been in upstream
> for a while and is begin deployed. I know that ILNP is not in Linux,
> but I don't know about other OSes.

Apologies - please excuse my flippant response. 

(I believe we may have had some version of this discussion before on the list.)

I have a Linux testbed at St Andrews, code written mainly by PhD students, Linux kernel version 3.9 - an old kernel, no longer supported. I have students working on porting the code to a newer kernel (version 4.x, hopefully 4.9 or 4.14).

The code is not yet in the upstream Linux repositories. As the ILNPv6 code makes changes to the main/core kernel code, it will take a while for this to make its way into the upstream code - it is harder to get changes in to the core kernel than to be added to the repo as a module.

I do not know of ILNP code existing in any other OSs.

Cheers,
--/Saleem


> 
> Tom
> 
>> Cheers,
>> --/Saleem
>> 
>> 
>>> 
>>> Tom
>>> 
>>>> Cheers,
>>>> --/Saleem
>>>> 
>>>> 
>>>> However, DNS is not privacy enabled which is our main issue here.
>>>> 
>>>> 
>>>> Regards,
>>>> Behcet
>>>>> 
>>>>> Cheers
>>>>> Dave
>>>>> 
>>>>> -----Original Message-----
>>>>> From: 5gangip <[e-mail]> On Behalf Of Saleem Bhatti
>>>>> Sent: Wednesday, May 30, 2018 9:19 AM
>>>>> To: Tom Herbert <[e-mail]>
>>>>> Cc: Luigi Iannone <[e-mail]>; 5GANGIP <[e-mail]>; Behcet
>>>>> Sarikaya <[e-mail]>
>>>>> Subject: Re: [5gangip] New Version Notification for
>>>>> draft-xyzy-atick-gaps-00.txt
>>>>> 
>>>>> Tom;
>>>>> 
>>>>>> On 30 May 2018, at 16:44, Tom Herbert <[e-mail]> wrote:
>>>>>> 
>>>>>> Behcet,
>>>>>> 
>>>>>> The statement "For ILNP the basic deployment requires end-systems to
>>>>>> be updated." is unscoped. As written, this would imply that all hosts
>>>>>> on the Internet need to be updated to support ILNP. That is simply a
>>>>>> non-starter.
>>>>> 
>>>>> Good catch - thanks.
>>>>> 
>>>>>> If the idea is that ILNP can be deployed by networks then hosts within
>>>>>> that network can be updated.
>>>>> 
>>>>> Only those end-systems that need to use ILNP need to be updated. ILNP
>>>>> nodes can work in networks with non-ILNP nodes - see Section 10.4 of
>>>>> RFC6741.
>>>>> 
>>>>> 
>>>>>> But, then the question
>>>>>> becomes how ILNP hosts are going to be able to talk non ILNP hosts
>>>>>> (say servers on the Internet). For that the an ILNP gateway or proxy
>>>>>> also must be deployed in the network.
>>>>> 
>>>>> A gateway or proxy is not required.
>>>>> 
>>>>> ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when
>>>>> required - the process is described in Section 10.6 of RFC6741.
>>>>> 
>>>>> Cheers,
>>>>> --/Saleem
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>> On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya
>>>>>> <[e-mail]> wrote:
>>>>>>> Luigi, Saleem,
>>>>>>> 
>>>>>>> What is the agreement now as to the revision of the draft?
>>>>>>> 
>>>>>>> I had already added some text regarding UE being alone on the link,
>>>>>>> i.e.
>>>>>>> point-to-point link in wireless networks, that should make both sides
>>>>>>> happy?
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Behcet
>>>>>>> 
>>>>>>> On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi Saleem,
>>>>>>>> 
>>>>>>>> On 29 May 2018, at 12:03, Saleem Bhatti <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hello Luigi;
>>>>>>>> 
>>>>>>>> Thanks for your comments - my responses are inline, below.
>>>>>>>> 
>>>>>>>> On 29 May 2018, at 09:32, Luigi Iannone <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 28 May 2018, at 19:16, Saleem Bhatti <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> There is some text which is incorrect - on page 4:
>>>>>>>> 
>>>>>>>> ----
>>>>>>>> Furthermore, ILNP demands a change in the way local (e.g., within a
>>>>>>>> LAN) communication is carried out, needing all of the devices to
>>>>>>>> support ILNP.  This in turn may raise heavy deployability issues.
>>>>>>>> ----
>>>>>>>> 
>>>>>>>> This is not true - "all devices" do *not* need to be updated, but
>>>>>>>> only those end-systems that wish to use ILNPv6. Switches
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Switches clearly do not need to be changed since they are L2.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Agreed.
>>>>>>>> 
>>>>>>>> However, the text clearly says "all of the devices", which is
>>>>>>>> incorrect.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Agreed.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> and routers
>>>>>>>> 
>>>>>>>> 
>>>>>>>> You need to implement the ILCC in your first hop router.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> No, that is not required. I have a testbed at St Andrews and we run
>>>>>>>> Linux routers that are not modified, and are not ILNP-aware. For
>>>>>>>> example, please see the testbed experiment described in this paper:
>>>>>>>> 
>>>>>>>> IP without IP addresses
>>>>>>>> https://dl.acm.org/citation.cfm?doid=3012695.3012701
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks for the pointer. :-)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Then you need new ICMP messages, and few other tricks here and there
>>>>>>>> in existing stuff.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The new ICMP messages, e.g. Locator Updates for ILNPv6, RFC6743, are
>>>>>>>> end-to-end - only the end hosts needs to be updated to generate
>>>>>>>> these messages.
>>>>>>>> 
>>>>>>>> If any on-path routers wish to examine such messages, then yes, they
>>>>>>>> would need to be updated, but that is not required for ILNPv6 to work.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ack.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Other solutions are more clear because introduce new entities and
>>>>>>>> protocol, so either you have it or you don’t.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Yet, may be the last sentence can be soften deleting  “heavy”.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> All new solutions will incur some sort of deployment overhead, so I
>>>>>>>> am not sure why such a comment should apply specifically and only to
>>>>>>>> ILNP.
>>>>>>>> 
>>>>>>>> For ILNP the basic deployment requires end-systems to be updated.
>>>>>>>> Such updates would be deployed through over-the-air updates, as is
>>>>>>>> common today with many operating systems. DNS entries for ILNP nodes
>>>>>>>> would also be needed, and the new DNS RRs for ILNP (RFC6742) are
>>>>>>>> supported commercially (e.g. by BIND, NSD, and KnotDNS, and possibly
>>>>>>>> others)..
>>>>>>>> 
>>>>>>>> For other solutions, other deployment issues exist, e.g. for ILA and
>>>>>>>> LISP, new network entities/functions need to be deployed and managed
>>>>>>>> for routing, and so, I guess, the existing network will need to be
>>>>>>>> reconfigured to integrate the new functionality. I am guessing some
>>>>>>>> operators may find that a "heavy" deployment burden, but it is best
>>>>>>>> that those operators comment on whether or not they see that is a
>>>>>>>> problem, as I have no experience with running large networks.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Updating end-systems is IMHO a real nightmare. You have no control
>>>>>>>> on who will update and when. Network history is full of such examples.
>>>>>>>> Yes, ILA and LISP has to be deployed by operators, but they can have
>>>>>>>> full control of what will happen in their own network (which they
>>>>>>>> usually like).
>>>>>>>> YMMV.
>>>>>>>> 
>>>>>>>> In general, I may agree that deployment considerations for all of
>>>>>>>> the considered solutions can be improved and corrected.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>> L.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> --/Saleem
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ciao
>>>>>>>> 
>>>>>>>> L.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> do not need to be updated, as ILNPv6 is backwards compatible with
>>>>>>>> IPv6. It is possible to run an ILNPv6 node in a LAN which also has
>>>>>>>> non-ILNPv6 nodes.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> --/Saleem
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 25 May 2018, at 15:50, Behcet Sarikaya <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> We have submitted the gaps draft. Those who have contributed text
>>>>>>>> are listed as co-authors.
>>>>>>>> Please send your comments to the list.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Dirk& Behcet
>>>>>>>> 
>>>>>>>> A new version of I-D, draft-xyzy-atick-gaps-00.txt has been
>>>>>>>> successfully submitted by Behcet Sarikaya and posted to the IETF
>>>>>>>> repository.
>>>>>>>> 
>>>>>>>> Name:           draft-xyzy-atick-gaps
>>>>>>>> Revision:       00
>>>>>>>> Title:          Gap and Solution Space Analysis for End to End Privacy
>>>>>>>> Enabled Mapping System
>>>>>>>> Document date:  2018-05-25
>>>>>>>> Group:          Individual Submission
>>>>>>>> Pages:          10
>>>>>>>> URL:
>>>>>>>> https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt
>>>>>>>> Status:
>>>>>>>> https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/
>>>>>>>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00
>>>>>>>> Htmlized:
>>>>>>>> https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Abstract:
>>>>>>>> This document presents a gap and solution analysis for end-to-end
>>>>>>>> privacy enabled mapping systems.  Each of the identifier locator
>>>>>>>> separation system has its own approach to mapping identifiers to the
>>>>>>>> locators.  We analyse all these approaches and identify the gaps in
>>>>>>>> each of them and do a solution space analysis in an attempt to
>>>>>>>> identify a mapping system that can be end to end privacy enabled.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission until the htmlized version and diff are available at
>>>>>>>> tools.ietf.org.
>>>>>>>> 
>>>>>>>> The IETF Secretariat
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 5gangip mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 5gangip mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 5gangip mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 5gangip mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 5gangip mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>> 
>>>>> _______________________________________________
>>>>> 5gangip mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>> 
>>>> 
>>>> 
>>