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

[Nick Buraglio <[e-mail]>]

I am definitely available to help this along. I incorporated the last
suggested changes a week or so ago.
nb



ᐧ

On Tue, May 17, 2022 at 9:36 AM Ed Horley <[e-mail]> wrote:

> 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/
>