RE: Network merge [Re: RFC6724-bis?]

[Vasilenko Eduard <[e-mail]>]

On the one side is something tangible and valuable right now
On the other side “to leave that possibility open” (for something that we could not predict yet)
It is what I call “evident choice”.

I do not have a clue why RFC 6724 has left ULA below IPv4.
As you see, not everybody is happy about it.
Do you believe that so a complex document such as SASA may not be improved in any way? Never?
Then 6man has concluded actually.
Ed/
From: ipv6 [mailto:[e-mail]] On Behalf Of David Farmer
Sent: Tuesday, September 27, 2022 9:58 PM
To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>
Cc: Michael Richardson <[e-mail]>; 6man WG <[e-mail]>
Subject: Re: Network merge [Re: RFC6724-bis?]



On Tue, Sep 27, 2022 at 1:41 PM Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
Does ULA in the global DNS make sense without ULA in the global routing table?
What is the use case?

OK. It is a ramification point.

I think you are missing my point; the question is, could there be any situation where ULA in the global DNS makes sense? If such a situation exists, then we shouldn't preclude the possibility. RFC 4193 seems to leave that possibility open.

One option is the prioritization of the whole fc/7 above GUA that:

1.       Does not need to change code in all OSes, just configuration gai.conf is enough.

2.       Automatically activate many ULA prefixes after companies merge.

3.       Prioritize ULA above GUA as many expect for internal communication.

4.       But the one who would leak ULA to the global DNS would be not reachable even if he properly resolve to the GUA too.

The second option is the prioritization of the whole fc/7 above IPv4 but below GUA that:

1.       Does not need to change code in all OSes, just configuration gai.conf is enough.

2.       Automatically activate many ULA prefixes after companies merge.

3.       But internally DNS should resolve only ULA because GUA would be preferred.
No problem if somebody would leak ULA to the global DNS.

The third option is the prioritization of the specific /48 that:

1.       Tolerant to ULA leakage to the global DNS (what is the value without ULA leakage to the global RIB?).

2.       Needs code change on all OSes.

3.       Needs manual insertion of other /48 after companies merge.

The choice looks evident.

If the choice is so evident, then you need to explain to me why did the authors of RFC 6724 choose as they did, and not what you think is so evident.

Thanks

Eduard
From: David Farmer [mailto:farmer<mailto:farmer>=[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, September 27, 2022 8:47 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: 6man WG <[e-mail]<mailto:[e-mail]>>; David Farmer <[e-mail]<mailto:[e-mail]>>; Mark Smith <[e-mail]<mailto:[e-mail]>>; Michael Richardson <[e-mail]<mailto:[e-mail]>>
Subject: Re: Network merge [Re: RFC6724-bis?]



On Tue, Sep 27, 2022 at 03:06 Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
I do not understand the concern about DNS leakage outside of the ULA domain.
For sure, it would happen again and again. People are making mistakes.
But why it is a problem?
Only resources of this domain may lose reachability from the outside.
The one who made a mistake would be contacted and fix it.
Ed/

First, not prioritizing remote ULAs is consistent with section 6, Destination Address Selection, Rule 1: Avoid unusable destinations.  Most ULAs will be unreachable and are therefore unusable, only the known local ULAs have any realistic chance of being reachable and therefore usable.

Further, while ULAs in the global DNS are not recommended, they are not prohibited either, and the “not recommended” in the controlling sentence of section 4.4 of RFC4193 is explicitly not normative. The only normative statement in that section is that reverse queries (PTR queries) MUST NOT be sent to DNS Servers for the global DNS because of the excessive load they can create. However, the AS112 project, as described in RFC 7534, now handles this issue, so even that normative statement is probably obsolete, or at least no longer absolutely necessary.

And even if it was normatively “NOT RECOMMENDED” to put ULAs in the global DNS, per RFC 2119, “there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful.”

Therefore, there probably exist situations where ULAs in the global DNS could be acceptable, and it is therefore probably a good idea to at least account for this possibility when considering the appropriate priority for ULAs, and the current version of RFC 6724 does just that,

Thanks.

From: David Farmer [mailto:farmer<mailto:farmer>=[e-mail]<mailto:[e-mail]>
Sent: Tuesday, September 27, 2022 3:15 AM
To: Mark Smith <[e-mail]<mailto:[e-mail]>>
Cc: 6man WG <[e-mail]<mailto:[e-mail]>>; Michael Richardson <[e-mail]<mailto:[e-mail]>>; Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Subject: Re: Network merge [Re: RFC6724-bis?]



On Mon, Sep 26, 2022 at 18:17 Mark Smith <[e-mail]<mailto:[e-mail]>> wrote:

Define another flag if this is going to be the solution to the fault of putting ULA AAAAs in global DNS.

(Can it be adapted to the fault of putting link-local addresses in DNS?)

ULAs in the global DNS, are only one of several faults that is being worked around with this admitted hack.  Another is the lose or even nonexistent boundary controls between the local and global domains in most networks, especially unmanaged networks, which can expose local information more widely than expected by most users. This is all further exasperated by the lack of any precise definition of what local means, and the very concept a globally scoped local address only adds to this confusion.

A sign that it's not solving the problem where it exists.

The problems exists in my places.



--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE<https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================