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

[Saleem Bhatti <[e-mail]>]

Luigi;

On 08 Jun 2018, at 09:51, Luigi Iannone <[e-mail]<mailto:[e-mail]>> wrote:



On 7 Jun 2018, at 13:29, Saleem Bhatti <[e-mail]<mailto:[e-mail]>> wrote:



[snip]

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.

There is a difference between “supporting” vs “deployment”, the first does not necessarily imply the second.

The RFC6742 DNS RRs for ILNP are supported/deployed in the same sense as IPv6 AAAA RRs are supported and deployed - they are implemented but you only configure them for use when you need them.


You are right, I was unclear. Let me rephrase it. How many people use ILNP out there? How many L64 RR are actually configured in DNS?

None outside the St Andrews testbed, as far as I know.


How does it work when you have a WiFi where you do not have any clue which device is connected? How do you understand that that particular device that just connect supports ILNPv6?

If by "connected" and "connect" you mean a layer 2 association with a WiFi basestation, then you cannot tell if it supports ILNPv6 just from the layer 2 association, just like you cannot tell if the device supports IPv6 (or even if it supports IPv4).

I was talking about L3. I connect to an open WiFi, How do they know I support ILNP?

At layer 3, to spot a node that runs ILNPv6, a device would need to see packets from the ILNPv6 node that contain the Nonce Header (e.g. a TCP SYN for a connection set-up), or a DNS update for L64, or a Locator Update message.



If you can, do you need to create a dynamic DNS entry with the ILNP record? How can I tell other that they need to check that particular dynamic entry to contact me?

An ILNPv6 mobile node that uses DNS will have a L64 RR. When the mobile node moves, it learns its new Locator value (which is the IPv6 routing prefix learned from an IPv6 Router Advertisement), then it updates its Locator value held in the L64 record. The "other" correspondent node would use DNS as normal, and see that new Locator value in the L64 record when it looks up the FQDN for the mobile node to initiate a new communication connection or session.

My point was more about general management. In my work place they need to know whether my devices are ILNPv6 or not because I need to mangle with the DNS, right?

Only if they expect the ILNP nodes to have incoming connections requiring DNS lookups would you need a DNS entry for the node, e.g. if the ILNP node was running a web server. If the ILNP node is a client system only, or it is using an application with its own presence/rendezvous mechanism, then it would not need a DNS entry.

Both the Nonce Header (RFC6744) and the Locator Update messages (RFC6743) have IANA-assigned codepoints, so firewall policies can be set-up as required. Other than that, the ILNPv6 packets look like IPv6 packets, on the wire.

Cheers,
--/Saleem



Thanks

Luigi



However, if the mobile node and correspondent node already have a communication session in progress, e.g. a TCP connection, or UDP session, then the mobile node signals the correspondent node with the new Locator value using a Locator Update message (RFC6743).

Cheers,
--/Saleem



Thanks

Ciao

L.




Cheers,
--/Saleem


However, DNS is not privacy enabled which is our main issue here.

Regards,
Behcet
Cheers
Dave

-----Original Message-----
From: 5gangip <[e-mail]<mailto:[e-mail]>> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <[e-mail]<mailto:[e-mail]>>
Cc: Luigi Iannone <[e-mail]<mailto:[e-mail]>>; 5GANGIP <[e-mail]<mailto:[e-mail]>>; Behcet Sarikaya <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
>>>
>>> Hi Saleem,
>>>
>>> On 29 May 2018, at 12:03, Saleem Bhatti <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 28 May 2018, at 19:16, Saleem Bhatti <[e-mail]<mailto:[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]<mailto:[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<http://tools.ietf.org/>.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/5gangip