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

[Nick Buraglio <[e-mail]>]

Updates made to https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula/

Comments hereby solicited.

ᐧ

On Wed, Jun 22, 2022 at 10:43 AM Nick Buraglio <[e-mail]> wrote:

> Been traveling and missed this. I'll get this addressed prior to IETF 114,
> is there anything else necessary to get on the agenda? I will need to get
> travel sorted ASAP.
>
> nb
>
>
>
> ᐧ
>
> On Sat, Jun 4, 2022 at 3:58 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> Nick,
>>
>> I think you should point out that RFC6724 also purports to define the
>> solution in section 10.6, and that this actually works, except that the
>> mechanism is o/s dependent and is not, as far as I know, supported by an
>> RA-based signal from the router, a DHCPv6 option, or a NETCONF mechanism.
>> The
>> only mechanisms available appear to be local config on the host [1].
>>
>> If a host was required to configure a policy entry as per section 10.6
>> whenever a new ULA prefix was announced by an RA, I think we would get the
>> required behaviour. (There could be a config option to disable that,
>> although it's hard to imagine it ever being the wrong thing to do.)
>>
>> The only alternative to that seems to be a wrapper for getaddrinfo() like
>> I prototyped [2].
>>
>> Regards
>>     Brian
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/v6ops/3MVHjxnvbNd5tOqyzIOzTrBKzVk/
>> [2]
>> https://mailarchive.ietf.org/arch/msg/v6ops/W1-I0RDb3F2F5B8CEx_bpYsXdRk/
>>
>> On 03-Jun-22 08:38, Nick Buraglio wrote:
>> > 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/ <
>> https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula/>
>> >
>> > nb
>> >
>> >
>> > ᐧ
>> >
>> > On Tue, May 17, 2022 at 9:39 AM Nick Buraglio <[e-mail] <mailto:
>> [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] <mailto:
>> [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] <mailto:[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]> <mailto:[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]> <mailto:
>> [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> <
>> 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 <http://10.1.0.0/16> <
>> https://streaklinks.com/BCrgR95yMi36cGo4vgrfW-nn/http%3A%2F%2F10.1.0.0%2F16
>> <
>> 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> <http://user.mynet.example.com <
>> http://user.mynet.example.com>>, a local server printer.mynet.example.com
>> <http://printer.mynet.example.com> <http://printer.mynet.example.com <
>> http://printer.mynet.example.com>>,
>> >              >         and a remote server www.theirnet.example.com <
>> http://www.theirnet.example.com> <http://www.theirnet.example.com <
>> http://www.theirnet.example.com>>. Assume they have these various
>> >              >         addresses:
>> >              >
>> >              > user.mynet.example.com <http://user.mynet.example.com> <
>> http://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> <http://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> <http://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]> <mailto:
>> [e-mail] <mailto:[e-mail]>>
>> >              > https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops> <
>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops>>
>> >              >
>> >              >     ᐧ
>> >              >     _______________________________________________
>> >              >     v6ops mailing list
>> >              > [e-mail] <mailto:[e-mail]> <mailto:
>> [e-mail] <mailto:[e-mail]>>
>> >              > https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops> <
>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops>>
>> >              >
>> >              >
>> >              >
>> >              > --
>> >              > Ed Horley
>> >              > [e-mail] <mailto:[e-mail]> <mailto:
>> [e-mail] <mailto:[e-mail]>>| [phone]
>> >              > Advancing Cloud, IoT, and Security with IPv6
>> >              > https://hexabuild.io <https://hexabuild.io> <
>> 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/> <
>> https://packetpushers.net/series/ipv6-buzz/ <
>> https://packetpushers.net/series/ipv6-buzz/>>
>> >
>> >
>> >
>> >         --
>> >         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/>
>> >
>>
>>