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

[Ed Horley <[e-mail]>]

Thanks, Brian, anything specific Nick, myself, and others can do around
helping to document the problem space better? Maybe jump on a working
call/session to chat through it?

On Mon, May 16, 2022 at 10:47 PM Brian E Carpenter <
[e-mail]> wrote:

> Ed,
>
> This is a topic where the WG basically failed some years ago, by being
> unable to reach a consensus around
> draft-ietf-v6ops-ula-usage-recommendations. I still think that is
> unfortunate, but at least we need to agree on the problem space and what
> needs to be fixed. Whether Nick's draft needs to be either adopted or
> published as an RFC isn't clear yet, but I think it's very important to
> document the problem space first. So I'd say we should encourage the draft
> & its author for a little longer, before deciding
> about adoption.
>
> Regards
>     Brian
>
> On 17-May-22 07:01, Ed Horley wrote:
> > I was curious what the process is for moving this to v6ops WG draft? I
> know several folks have requested this, sorry for my ignorance on the
> matter. I feel it wouldn't it make sense to get that done given that Brian
> and others are working on issues for RFC 6724 and there seems to be more
> discussion around the ULA topic in general. Thoughts?
> > - Ed
> >
> > On Tue, May 10, 2022 at 9:01 AM Nick Buraglio <[e-mail] <mailto:
> [e-mail]>> wrote:
> >
> >     I added some additional verbiage based on your suggestions and
> addressed the NIT.
> >
> >     nb
> >
> >     On Sun, May 8, 2022 at 6:23 PM Brian E Carpenter <
> [e-mail] <mailto:[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 <
> 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 <
> https://streaklinks.com/BCrgR95yMi36cGo4vgrfW-nn/http%3A%2F%2F10.1.0.0%2F16>
> (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 <
> http://user.mynet.example.com>, a local server printer.mynet.example.com <
> http://printer.mynet.example.com>,
> >         and a remote server www.theirnet.example.com <
> http://www.theirnet.example.com>. Assume they have these various
> >         addresses:
> >
> >         user.mynet.example.com <http://user.mynet.example.com> has:
> >
> >         10.1.0.1
> >         fdee:face:fade::1
> >         2001:db8:fade::1
> >
> >         printer.mynet.example.com <http://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 <http://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] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >     ᐧ
> >     _______________________________________________
> >     v6ops mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
> >
> > --
> > Ed Horley
> > [e-mail] <mailto:[e-mail]>| [phone]
> > Advancing Cloud, IoT, and Security with IPv6
> > https://hexabuild.io <https://hexabuild.io/>
> > And check out the IPv6 Buzz Podcast at
> https://packetpushers.net/series/ipv6-buzz/ <
> https://packetpushers.net/series/ipv6-buzz/>
>
>

-- 
Ed Horley
[e-mail] | [phone]
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/