Re: [v6ops] I-D Action: draft-buraglio-v6ops-ula-01.txt

[Nick Buraglio <[e-mail]>]

I will work through these suggestions.

nb


ᐧ

On Sun, May 8, 2022 at 6:23 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi,
>
> Thanks for this draft. I have a few comments (and a tiny nit at the end).
>
> >  The core issue is the stated interpretation from gai.conf that has the
> following default:
> >
> > #scopev4  <mask> <value>
> > #    Add another rule to the RFC 6724 scope table for IPv4 addresses.
>
> I'm not sure why this matters. RFC6724 is quite correct to indicate that
> most IPv4 unicast addresses formally have global scope, but auto-config
> and loopback addresses have link-local scope. IPv6 is pretty much the
> same, and in particular ULAs have *global scope* even though they are
> not globally reachable. RFC1918 addresses are identical to ULAs in
> that respect.
>
> Citing RFC4291 and https://www.rfc-editor.org/rfc/rfc8190.html#section-2.1
> would clarify the difference between global scope (architectural) and
> globally reachable (practical). What we care about here is whether an
> address is globally reachable ("no" for both RFC1918 and ULA, although
> they are both architecturally global). Unfortunately this distinction is
> lacking in the description of gai.conf and, I suspect, in the code of
> Linux getaddrinfo().
>
> What I think is lacking in the draft is an explanation of how
> getaddrinfo() works and why it matters. Here's a walkthrough that
> I hope will help clarify what I mean:
>
> Consider an end-user network with the following properties:
>
> It is dual stacked.
> It uses 10.1.0.0/16 (NATted to the Internet).
> It uses (or wants to use)  fdee:face:fade::/48 for internal IPv6.
> It uses 2001:db8:fade::/48 for external IPv6
>
> We'll neglect for now whether it has a subnet structure. It shouldn't
> matter.
>
> Consider a host user.mynet.example.com, a local server
> printer.mynet.example.com,
> and a remote server www.theirnet.example.com. Assume they have these
> various
> addresses:
>
> user.mynet.example.com has:
>
> 10.1.0.1
> fdee:face:fade::1
> 2001:db8:fade::1
>
> printer.mynet.example.com has:
>
> 10.1.0.10  (A record in local DNS)
> fdee:face:fade::a  (AAAA record in local DNS)
>
> www.theirnet.example.com has:
>
> 192.0.2.15  (A record in global DNS)
> 2001:db8:cafe::f  (AAAA record in global DNS)
>
> What do we *want* to happen?
>
> If user opens a connection to printer, we want it to choose
> SA = fdee:face:fade::1
> DA = fdee:face:fade::a
>
> If user opens a connection to www, we want it to choose
> SA = 2001:db8:fade::1
> DA = 2001:db8:cafe::f
>
> Now, if user does a DNS lookup, via getaddrinfo(), the results
> will look like this (in the Python universe):
>
> For printer:
>
> (<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))
> (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fdee:face:fade::a', 0, 0, 0))
>
> For www:
>
> (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('2001:db8:cafe::f', 0, 0, 0))
> (<AddressFamily.AF_INET: 2>, 0, 0, '', ('192.0.2.15', 0))
>
> At this point, consider what RFC6724 says:
>
>     As a consequence, we intend that implementations of APIs such as
>     getaddrinfo() will use the destination address selection algorithm
>     specified here to sort the list of IPv6 and IPv4 addresses that they
>     return.  Separately, the IPv6 network layer will use the source
>     address selection algorithm when an application or upper layer has
>     not specified a source address.
>
> Thus, to get the desired behaviour, what matters is destination
> address selection: if we select DA = fdee:face:fade::a, then the
> ULA source address will follow.
>
> Of course this is a small matter of programming, and most programmers
> just pick the first address. That's why we need the Section 10.6
> mechanism of RFC6724, to insert an appropriate precedence like
>
>     fdee:face:fade::/48 45 14
>
> which will prioritize local use of ULAs but will change nothing
> for off-site access.
>
> At that point in my thinking, I started coding the program that
> I posted yesterday.
>
> Nit:
>
> s/gai.cnf/gai.conf/
>
> Regards
>     Brian
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>