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

[David Farmer <[e-mail]>]

Nick,

I would have preferred an explicit mention of section 10.6 of RFC 6724, and
the need for the addition of the site-specific /48 ULA prefix to the policy
table, particularly the fact that without the optional automatic addition
of the site-specific /48 ULA prefix, implementations of RFC6724 will have
the issues discussed. Nevertheless, I think what you have is probably good
enough.

Thanks.

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

> 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/>
>>> >
>>>
>>> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================