Re: [**EXTERNAL**] RE: New Version Notification for draft-mudric-6man-lcs-01.txt

["Mudric, Dusan" <[e-mail]>]

Hi Eduard,

An application can choose to use LL for on-link communication. That request can be passed via a socket API to ND.
ND would set NS 'L' bit to indicate the LL address resolution is required and use of LL for the on-link communication,
if a destination host returns it.

The process starts with an application requesting a socket to send to GUA destination. 
First step is a destination address selection and the sequence goes to the LL address resolution, step 4:

1st: Host should choose destination address, if multiple GUA and ULA are provided
2nd: Host should choose source address, for the selected destination address
3rd: Host should choose next hop, and outgoing interface, based on the source address prefix
4th: If a destination is on-link, the host may want to resolve destination GUA into destination LL

Step 4 is further broken down into:
4.1st: Sender creates a neighbor cache entry for GUA.
4.2nd: Sender sends NS, with L bit set, to GUA.
4.3rd: Sender receives NA with link-layer and LL addresses
4.4th: Sender updates GUA cache entry with the link-layer address
4.5th: Sender creates a neighbor cache entry for destination LL address and sets
           the destination link-layer address of the destination host
4.6th: Sender closes the socket listening on GUA and opens a socket listening on LL
4.7th: Sender transmits a packet to link-layer address of the destination host,
           using destination host LL address as IPv6 packet destination address
4.8th: Application sending to GUA should obtain the SASA address (which is now LL
          address) for the further negotiations (e.g. SIP needs to negotiate media addresses). 
          This also implies an application should be given an option to request
          LL vs. GUA communication, when opening a socket to GUA destination. Socket
          API should have this option and use it to initiate LL address resolution.


Good point about the server side. There might be a mix of clients on the local link, some that want to use LL and some that don't.
For that reason server APPs would need to listen on both GUA and LL, using APP port numbers. That can be achieved by opening
a listening socket on ANY address. It is very unlikely that the server will talk only to clients on the local link. In case it does 
happen, the server applications can listen on {LL, port}.

If a server is listening on GUA only for a particular application, and this algorithm is supported, a client might request LL 
conversation. However, the server application would be unreachable. What can be a solution for this? May be if a socket
API does not request LL connection, server ND should not return LL address (step 4.3).

Thanks,
Dusan.

>On 2020-10-22, 3:02 PM, "Vasilenko Eduard" <[e-mail]> wrote:
>
>Hi Dusan,
>It does not work the way you numbering events.
>It could not start from NCE population, because ND needs traffic to become interested in new NCE.
>
>Does your points 4-7 mean that on-link communication would be prohibited on GUA in principle,
>Because all GUA requests would be automatically translated to LLA?
>If not, how ND should know what should be translated into LLA and what should not?
>
>Does it mean that traffic would be black-holed if server would not attach application to LLA?
>How client would understand that server is listening on LLA for particular application?
>
>Eduard