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

[Nick Buraglio <[e-mail]>]

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