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

From: "Mudric, Dusan" <[email-masked]>
Date: Fri, 21 Aug 2020 17:23:48 +0000

> On 2020-08-20, 1:57 PM, "Vasilenko Eduard" 
> <[email-masked]> wrote:
> 
>> It is possible to look into "Prefix List" (RFC 4861 terminology), 
>> If particular PIO was with "L"="Local" bit set, Then it is possible
>> to use GUA as destination, but LLA as source. Should work.
> 
 [Dusan] rfc6724#section-5, SASA Rule 2

"   Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If 
   Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. 
   Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then 
   prefer SA and otherwise prefer SB."

 prefers the closest Scope(S) to the given destination Scope(D). If D
 is GUA, a source will selects its S-GUA, rather than S-LLA.

 Even if it might be possible to make S-LLA - to - D-GUA connection, 
 for security reasons it is preferred that both parties use LLAs for 
 ON-LINK communication.

But if I am a Cisco router computer software I
can not force a Juniper router computer software to do whatever.  If
Juniper computer contacts me by using a GUA all I can do is to reply to
it using my LLA.  I have no way to signal it to tell it 'please use an LLA
instead'. This draft is proposing  such a new way.

 So, this draft is saying "I have your GUA destination address
 but I would like to talk to you using our LLAs. If you agree to give me
 your LLA, we will talk using our LLAs".

>> It is radical departure from 6724: " to prefer destination/source 
>> address pairs for  which the two addresses are of equal scope or 
>> type ..."
> 
>> I am not sure that any other RFC would not block this approach. I 
>> do not see any blocking factor. Let's others speak.

Yes, I think it is time to see what others think.

>> PS: I do not believe that it is possible to map Destination GUA to
>>  Destination LLA.
> 
[Dusan] The proposed mechanism is to use address resolution for GUA,
to obtain Destination LLA, when it is found that a destination GUA is
on link. LLA is a Link Local Address, not 'link-layer address' MAC address.
Address resolution NA message can be extended to provide D-LLA. That 
is how a source will learn about destination LL address.

The existing address resolution mechanisms (NS/NA) would resolve
a link-layer address of a GUA that is used by the same interface on
which GUA is attached. The existing address resolution mechanism 
(NS/NA) does not offer means to obtain the link-local address of 
an interface of a GUA. This draft is proposing to change the current
mechanism to be able to negotiate LLAs.

Alex

> 
>> Eduard
> -----Original Message----- From: Mudric, Dusan 
> [mailto:[email-masked]] Sent: 20 августа 2020 г. 16:08 To: 
> Alexandre Petrescu <[email-masked]>; Vasilenko Eduard 
> <[email-masked]>; [email-masked] Cc: Dusan Mudric 
> <[email-masked]> Subject: Re: [**EXTERNAL**] New Version 
> Notification for draft-mudric-6man-lcs-00.txt
> 
> 
> On 2020-08-18, 4:04 PM, "Vasilenko Eduard" 
> <[email-masked]> wrote:
>> 
>> Hi Dusan, Hi Alexandere,
> 
> [Alex] Thank you for the reply.  We carefully consider the comments.
> 
> We identified a corner case of communicating on the same link.  In 
> this corner case the RFC6724 recommendation creates a security 
> problem.
> 
> Rather, we recommend to use the least possible scope that is 
> 'common', i.e. it allows to reach the other.  In other words, use a 
> LL src even if the dst is a GUA (GUA on the same link).
> 
> (maybe the 'least common scope' is not the best.  Because by RFC
> 4291 "Addr Archi" the LL and GUA are not the same common scope, even
>  though one might imagine that link scope is included in a 'global' 
> scope, and thus the least common scope between LL and GUA is the LL 
> scope; it is a notion borrowed from set theory, an intersection; 
> another difficulty with 'least common scope' is that Global in GUA is
> not a 'scope' but a characteristic of the uniqueness; and 'Global 
> Unicast' is an address 'type', not a scope.  To make things worse, 
> 'types' of addresses  could be more than just LL ang GUA; other 
> equally legitimate address types are 'unicast', 'multicast' and 
> 'anycast', and also 'Unspecified', 'Loopback', 'Multicast'; and there
> are sub-types too.  So, maybe a more precise recommendation would be
> to 'use an address type whose scope is the least possible to reach a
> given destination', or 'least possibly scoped address type', instead
> of 'least common scope'.)
> 
>> RFC 6724 does have big attention to choose addresses with smallest 
>> scope - section 3.1.
> 
> [Alex] That section 3.1 is about mapping multicast scopes to unicast 
> scope, in order to give reason to comparing the scopes of unicast. 
> However, a 1-to-1 mapping between these two scopes is hardly 
> understandable.  In particular, there still exists a site-local
> scope for multicast but no longer for unicast.   And, there exist a
> unicast ULA global scope that is not reachable (it's global in that
> it is uniquely global, not because it is globally reachable -
> 'reachable' a word not in dictionary anyways :-).   So it's hard to
> see its multicast counterpart: either it's globally reachable or it's
>  site-local (cant be both).
> 
> (In a multicast context it's not possible to use a multicast address
>  in the source of the packets; so in a multicast context one couldn't
>  talk about same-scope recommendations.  Moreover, there should not
> be blockage to sending packets of ll scope to global mc scope.  _If_
> we had a src multicast possibility then yes, there could have been a
>  good recommendation of same-scope src-to-dst multicast-to-multicast
>  packets. But we are not concerned with that here.)
> 
> Because of the impossibility of the mapping that I mention above, 
> it's impossible to come up with rules of same scope use in unicast 
> context. And thus the effort of mapping seems without success.
> 
>> Then scope is at the second priority for section 5 "Source Address 
>> Selection".
> 
> [Alex] Rule 2 might not lead to what we want.  The execution of that 
> rule using input parameters SA==GUA, SB==LL and D==GUA leads to 
> select SA (a GUA) as src; we dont want GUA in src when the 
> destination is GUA on the same link.
> 
> [Dusan] It is rather DASA rule 8: Rule 8: Prefer smaller scope. If 
> Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) > 
> Scope(DB), then prefer DB.
> 
> I think the order of address selection should be: - DASA Rule 8 to 
> select LL destination address, preferring the smaller scope, and - 
> SASA Rule 6 will select SA-LL source address that has the same label
>  as destination DA-LL address
> 
> Section 10.2 example: "   Candidate Source Addresses: 2001:db8:1::2 
> or fe80::2 Destination Address List: 2001:db8:1::1 or fe80::1 Result:
> fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) (prefer
> smaller scope)"
> 
> This means a host needs to autodiscover a destination LL address, 
> before applying DASA Rule 8. The details of this mechanism will be 
> provided.
> 
>> I have not understood what else you need? IMHO: it is better to 
>> clearly state what particular sentences in RFC 6724 you would like 
>> to change or amend.
> [Dusan] For ON-LINK D-GUA, SASA cannot be done until On-Link check 
> and LL address resolution are completed. A socket API in  RFC5014 
> would get a destination GUA or ULA, and: - Need to do ON-LINK 
> determination, and - Obtain LL address for ON-LINK destinations (LL 
> address resolution). Otherwise: - Rule 8 can be updated to check if a
> destination (with its DA-GUA and DB-ULA addresses) is ON-LINK, and 
> obtain and use LL address for  ON-LINK destinations.
> 
> The second approach makes SASA dependent on asynchronous 
> communication with the ON-LINK destination and is not a preferred 
> choice. If the first approach is used, there is no need to update RFC
> 6724.
> 
>> I suspect that finally you would come to the problem how to find 
>> LLA for particular GUA?
> 
> [Alex] Yes, probably that problem.  As a solution, it is not 
> impossible to find the LLA of a particular interface that is is 
> present as a field in an entry in a routing table whose first field 
> covers the GUA ('covers' - as identified by a longest-prefix match 
> algorithm).
> 
>> even for the case when proper GUA prefix is announced from local 
>> router with "L" bit set. Because GUA and LLA could have different 
>> interface ID.
> 
> [Alex] Yes, could.
> 
>> GUA has been fetched from an Active Directory or DNS.
> 
> [Dusan] Or assigned by DHCPv6 (e.g. a destination host server 
> address)
> 
>> Where to find LLA for the same host?!? Is every host should 
>> register all their addresses on default router? to find 
>> correspondence.
> 
> [Dusan] No.
> 
>> What is the protocol to fetch this correspondence?
> 
> [Dusan] Host already have defined on-link determination, RFC 4861.
> If DA_GUA prefix: " - is covered by one of the link's prefixes (e.g.,
> as indicated by the on-link flag in the Prefix Information option)"
> "A node considers an address to be on-link".
> 
> The same RFC4861 defines "     Address resolution: How nodes 
> determine the link-layer address of an on-link destination (e.g., a 
> neighbor) given only the destination's IP address."
> 
> If the DA is ON-LINK, a host can resolve DA not only into the 
> link-layer address, but, with extensions, into DA_LL address.
> 
>> Nope. It would not fly... Not on this planet.
>> 
>> Correspondence between GUA and ULA is potentially possible to keep 
>> in Active Directory. It looks like operational recommendation to 
>> corporate IT: use ULA and populate it into DNS and Active
>> Directory with higher priority (if you need GUA at all for internal
>>  resources); use ULA and GUA for ordinary hosts. > I do not see why
>>  you need to change RFC 6724 for this - host should automatically 
>> choose ULA in this scenario. The fact that ULA is more secure is 
>> not a big secret. > Eduard
> 
> 
>> -----Original Message----- From: ipv6 
>> [mailto:[email-masked]] On Behalf Of
> Mudric, Dusan
>> Sent: 18 августа 2020 г. 16:56 To: [email-masked] Cc: 
>> [email-masked] Subject: FW: [**EXTERNAL**] New 
>> Version Notification for
> draft-mudric-6man-lcs-00.txt
>> 
>> Hi,
>> 
>> Please provide comments.
>> 
>> Thanks a lot, Dusan.
>> 
>> On 2020-08-18, 9:31 AM, "[email-masked]"
> <[email-masked]> wrote:
>> 
>> 
>> A new version of I-D, draft-mudric-6man-lcs-00.txt has been 
>> successfully submitted by Dusan Mudric and
> posted to the
>> IETF repository.
>> 
>> Name:		draft-mudric-6man-lcs Revision:	00 Title:		Least-Common 
>> Scope Communications Document date:	2020-08-18 Group:		Individual 
>> Submission Pages:		5 URL:
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-mudric-6man-lcs-00.txt__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuv1SQv-G$
>
>
>
> 
Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mudric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuq3WYxzi$
>
>
>
> 
Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuvX3ounT$
>
>
>
> 
Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuqfeyVD5$
>
>
>
> 
> 
>> 
>> Abstract: This draft formulates a security problem statement.
> The problem
>> arises when a Host uses its Global Unicast Address
> (GUA) to
>> communicate with another Host situated on the same link.
>> 
>> To address this problem, we suggest to select and use
> addresses of a
>> least scope that are common.
>> 
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
>> --------------------------------------------------------------------
>
>>
>>
>> 
> IETF IPv6 working group mailing list
>> [email-masked] Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdYKG$
>
>
>
>  
> --------------------------------------------------------------------
>> 
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 08:55:28 +0000

Hi Dusan,
[Dusan] The proposed mechanism is to use address resolution for GUA, to obtain Destination LLA, when it is found that a destination GUA is on link.
It is exactly the problem: you have not proposed any details how to do it.

Another problem for adoption could be on use case:
- if it is corporate environment, then Server is probably on a separate segment from client, and both are protected by FW on the perimeter
- if it is home environment, then resource location is manual - LLA could be chosen without any protocol extensions.
Do you have any evidences that the problem is really applicable to real life?

PS: Vendor names are typically better to use "Vendor1" and "Vendor2", real vendors could have an objections that they are not capable to do something.

Ed/
-----Original Message-----
From: Mudric, Dusan [mailto:[email-masked]] 
Sent: 21 августа 2020 г. 20:24
To: Alexandre Petrescu <[email-masked]>; Vasilenko Eduard <[email-masked]>; [email-masked]
Cc: Dusan Mudric <[email-masked]>
Subject: Re: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt

>> It is possible to look into "Prefix List" (RFC 4861 terminology), If 
>> particular PIO was with "L"="Local" bit set, Then it is possible to 
>> use GUA as destination, but LLA as source. Should work.
> 

"   Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If 
   Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. 
   Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then Hi 
   prefer SA and otherwise prefer SB."

 prefers the closest Scope(S) to the given destination Scope(D). If D  is GUA, a source will selects its S-GUA, rather than S-LLA.

 Even if it might be possible to make S-LLA - to - D-GUA connection,  for security reasons it is preferred that both parties use LLAs for  ON-LINK communication.

But if I am a Cisco router computer software I can not force a Juniper router computer software to do whatever.  If Juniper computer contacts me by using a GUA all I can do is to reply to it using my LLA.  I have no way to signal it to tell it 'please use an LLA instead'. This draft is proposing  such a new way.

 So, this draft is saying "I have your GUA destination address  but I would like to talk to you using our LLAs. If you agree to give me  your LLA, we will talk using our LLAs".

>> address pairs for  which the two addresses are of equal scope or type 
>> ..."
> 
>> I am not sure that any other RFC would not block this approach. I do 
>> not see any blocking factor. Let's others speak.

>> PS: I do not believe that it is possible to map Destination GUA to  
[Dusan] The proposed mechanism is to use address resolution for GUA, to obtain Destination LLA, when it is found that a destination GUA is on link. LLA is a Link Local Address, not 'link-layer address' MAC address.
Address resolution NA message can be extended to provide D-LLA. That is how a source will learn about destination LL address.

The existing address resolution mechanisms (NS/NA) would resolve a link-layer address of a GUA that is used by the same interface on which GUA is attached. The existing address resolution mechanism
(NS/NA) does not offer means to obtain the link-local address of an interface of a GUA. This draft is proposing to change the current mechanism to be able to negotiate LLAs.

Alex

> Rather, we recommend to use the least possible scope that is 'common', 
> i.e. it allows to reach the other.  In other words, use a LL src even 
> if the dst is a GUA (GUA on the same link).
> 
> unicast ULA global scope that is not reachable (it's global in that it 
> is uniquely global, not because it is globally reachable -
> talk about same-scope recommendations.  Moreover, there should not be 
> blockage to sending packets of ll scope to global mc scope.  _If_ we 
> had a src multicast possibility then yes, there could have been a  
> Because of the impossibility of the mapping that I mention above, it's 
> impossible to come up with rules of same scope use in unicast context. 
> And thus the effort of mapping seems without success.
> 
> rule using input parameters SA==GUA, SB==LL and D==GUA leads to select 
> SA (a GUA) as src; we dont want GUA in src when the destination is GUA 
> on the same link.
> 
>> clearly state what particular sentences in RFC 6724 you would like to 
>> change or amend.
> [Dusan] For ON-LINK D-GUA, SASA cannot be done until On-Link check and 
> LL address resolution are completed. A socket API in  RFC5014 would 
> get a destination GUA or ULA, and: - Need to do ON-LINK determination, 
> and - Obtain LL address for ON-LINK destinations (LL address 
> resolution). Otherwise: - Rule 8 can be updated to check if a 
> The second approach makes SASA dependent on asynchronous communication 
> with the ON-LINK destination and is not a preferred choice. If the 
> first approach is used, there is no need to update RFC 6724.
> 
>> I suspect that finally you would come to the problem how to find LLA 
>> for particular GUA?
> 
>> Where to find LLA for the same host?!? Is every host should register 
>> all their addresses on default router? to find correspondence.
> 
> [Dusan] No.
> 
>> Correspondence between GUA and ULA is potentially possible to keep in 
>> Active Directory. It looks like operational recommendation to 
>> corporate IT: use ULA and populate it into DNS and Active Directory 
>> with higher priority (if you need GUA at all for internal  
>> choose ULA in this scenario. The fact that ULA is more secure is not 
>> a big secret. > Eduard
> 
> 
>> -----Original Message----- From: ipv6 [mailto:[email-masked]] 
>> On Behalf Of
> Mudric, Dusan
>> [email-masked] Subject: FW: [**EXTERNAL**] New Version 
>> Notification for
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft
> -mudric-6man-lcs-00.txt__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0
> MxmIe6D_mOhy38kXzuv1SQv-G$
>
>
>
> 
Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mud
> ric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mO
> hy38kXzuq3WYxzi$
>
>
>
> 
Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6
> man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy3
> 8kXzuvX3ounT$
>
>
>
> 
Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> t-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6
> D_mOhy38kXzuqfeyVD5$
>
>
>
> 
> 
>> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!OSsGDw!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdY
> KG$
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Aug 2020 18:09:19 +0200

Hi, Eduard,

>  to obtain Destination LLA, when it is found that a destination GUA 
> is on link. It is exactly the problem: you have not proposed any 
> details how to do it.
> 
> - if it is corporate environment, then Server is probably on a 
> separate segment from client, and both are protected by FW on the 
> perimeter

True, especially if Server might be a DHCPv6 server for multiple subnets.

In the design space, we might not want a central Server to perform that
resolution GUA-LLA for all Hosts in a domain.  We might want that
resolution to be targetting the Host that owns the addresses, a little
bit like NS/NA does.

However, we might want to consider the next-hop router instead of Server.

> - if it is home environment, then resource location is manual - LLA 
> could be chosen without any protocol extensions.

True, in some small home environments tables of mappings LLA-GUA could
be maintained manually, and protocol extensions might not be necessary.

> Do you have any evidences that the problem is really applicable to 

We will provide some more details soon.

> PS: Vendor names are typically better to use "Vendor1" and
> "Vendor2", real vendors could have an objections that they are not
> capable to do something.

YEs yes, true enough.   Anonymizing names helps avoid pointing the finger.

Alex, and Dusan

> 
> Ed/ -----Original Message----- From: Mudric, Dusan 
> [mailto:[email-masked]] Sent: 21 августа 2020 г. 20:24 To: 
>>> It is possible to look into "Prefix List" (RFC 4861
>>> terminology), If particular PIO was with "L"="Local" bit set,
>>> Then it is possible to use GUA as destination, but LLA as source.
>>> Should work.
>> 
> But if I am a Cisco router computer software I can not force a 
> Juniper router computer software to do whatever.  If Juniper
> computer contacts me by using a GUA all I can do is to reply to it
> using my LLA.  I have no way to signal it to tell it 'please use an
> LLA instead'. This draft is proposing  such a new way.
> 
> So, this draft is saying "I have your GUA destination address  but I 
> would like to talk to you using our LLAs. If you agree to give me 
>>> I am not sure that any other RFC would not block this approach.
>>> I do not see any blocking factor. Let's others speak.
> 
>>> PS: I do not believe that it is possible to map Destination GUA 
>>> to Destination LLA.
>> 
> on link. LLA is a Link Local Address, not 'link-layer address' MAC 
> address. Address resolution NA message can be extended to provide 
> D-LLA. That is how a source will learn about destination LL address.
> 
> The existing address resolution mechanisms (NS/NA) would resolve a 
> link-layer address of a GUA that is used by the same interface on 
> (NS/NA) does not offer means to obtain the link-local address of an 
> interface of a GUA. This draft is proposing to change the current 
>> 'common', i.e. it allows to reach the other.  In other words, use
>> a LL src even if the dst is a GUA (GUA on the same link).
>> 
>> 4291 "Addr Archi" the LL and GUA are not the same common scope, 
>> even though one might imagine that link scope is included in a 
>> 'global' scope, and thus the least common scope between LL and GUA 
>> is the LL scope; it is a notion borrowed from set theory, an 
>> intersection; another difficulty with 'least common scope' is that 
>> Global in GUA is not a 'scope' but a characteristic of the 
>> uniqueness; and 'Global Unicast' is an address 'type', not a
>> scope. To make things worse, 'types' of addresses  could be more
>> than just LL ang GUA; other equally legitimate address types are
>> 'unicast', 'multicast' and 'anycast', and also 'Unspecified',
>> 'Loopback', 'Multicast'; and there are sub-types too.  So, maybe a
>> more precise recommendation would be to 'use an address type whose
>> scope is the least possible to reach a given destination', or
>> 'least possibly scoped address type', instead of 'least common
>> scope'.)
>> 
>>> RFC 6724 does have big attention to choose addresses with 
>>> smallest scope - section 3.1.
>> 
>> [Alex] That section 3.1 is about mapping multicast scopes to 
>> unicast scope, in order to give reason to comparing the scopes of 
>> unicast. However, a 1-to-1 mapping between these two scopes is 
>> hardly understandable.  In particular, there still exists a 
>> site-local scope for multicast but no longer for unicast.   And, 
>> there exist a unicast ULA global scope that is not reachable (it's 
>> global in that it is uniquely global, not because it is globally 
>> reachable - 'reachable' a word not in dictionary anyways :-).   So 
>> it's hard to see its multicast counterpart: either it's globally 
>> reachable or it's site-local (cant be both).
>> 
>> (In a multicast context it's not possible to use a multicast 
>> address in the source of the packets; so in a multicast context
>> one couldn't talk about same-scope recommendations.  Moreover,
>> there should not be blockage to sending packets of ll scope to
>> global mc scope.  _If_ we had a src multicast possibility then yes,
>> there could have been a good recommendation of same-scope
>> src-to-dst multicast-to-multicast packets. But we are not concerned
>> with that here.)
>> 
>>> Then scope is at the second priority for section 5 "Source 
>>> Address Selection".
>> 
>> [Alex] Rule 2 might not lead to what we want.  The execution of 
>> that rule using input parameters SA==GUA, SB==LL and D==GUA leads 
>> to select SA (a GUA) as src; we dont want GUA in src when the 
>>  SASA Rule 6 will select SA-LL source address that has the same 
>> label as destination DA-LL address
>> 
>> or fe80::2 Destination Address List: 2001:db8:1::1 or fe80::1
>> Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 
>> 2001:db8:1::2) (prefer smaller scope)"
>> 
>>> clearly state what particular sentences in RFC 6724 you would 
>>> like to change or amend.
>> determination, and - Obtain LL address for ON-LINK destinations
>> (LL address resolution). Otherwise: - Rule 8 can be updated to
>> check if a destination (with its DA-GUA and DB-ULA addresses) is
>> ON-LINK, and obtain and use LL address for  ON-LINK destinations.
>> 
>> choice. If the first approach is used, there is no need to update 
>> RFC 6724.
>> 
>>>  router with "L" bit set. Because GUA and LLA could have
>>> different interface ID.
>> 
>> [Alex] Yes, could.
>> 
>>  If DA_GUA prefix: " - is covered by one of the link's prefixes 
>> (e.g., as indicated by the on-link flag in the Prefix Information 
>> option)" "A node considers an address to be on-link".
>> 
>>> Correspondence between GUA and ULA is potentially possible to 
>>> keep in Active Directory. It looks like operational 
>>> recommendation to corporate IT: use ULA and populate it into DNS 
>>> and Active Directory with higher priority (if you need GUA at all
>>> for internal resources); use ULA and GUA for ordinary hosts.
>>>> I do not see why you need to change RFC 6724 for this - host
>>> should automatically choose ULA in this scenario. The fact that 
>>> ULA is more secure is not a big secret. > Eduard
>> 
>>