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

[Nick Buraglio <[e-mail]>]

Circling back around to re-ignite some discussions about this draft. I am
planning to be at the next IETF, is there anything else folks would like
addressed in this current document? Other details to discuss?
https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula/

nb


ᐧ

On Tue, May 17, 2022 at 9:39 AM Nick Buraglio <[e-mail]> wrote:

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