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

[Brian E Carpenter <[e-mail]>]

Thanks Nick.

I think you now have the problem well described. Whether we want to propose any IETF action maybe deserves discussion.

Regards
    Brian Carpenter

On 23-Jun-22 04:09, Nick Buraglio wrote:
> Updates made to https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula/ <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] <mailto:[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] <mailto:[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/ <https://mailarchive.ietf.org/arch/msg/v6ops/3MVHjxnvbNd5tOqyzIOzTrBKzVk/>
>         [2] https://mailarchive.ietf.org/arch/msg/v6ops/W1-I0RDb3F2F5B8CEx_bpYsXdRk/ <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/> <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]> <mailto:[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]> <mailto:[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]> <mailto:[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]>> <mailto:[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]>> <mailto:[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>> <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> <http://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> <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>> <http://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>> <http://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>> <http://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>> <http://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>> <http://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>> <http://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]>> <mailto:[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>> <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]>> <mailto:[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>> <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]>> <mailto:[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>> <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/>> <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]> <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/>>
>          >
>