Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

From: Fred Baker <[email-masked]>
Date: Tue, 4 Jan 2022 09:55:08 -0800

> On Dec 22, 2021, at 6:36 AM, [email-masked] wrote:
> 
> Ted,
> 
>> If you want your IPv6 transit network to work, do not number the interfaces of the routers with ULAs. As you say, lots of things will break if you violate this rule. 
> 
> This is how myths spread. Please stop.

A specific example would help. I would agree that blanket statements like this are generally not very helpful. What specifically breaks?

> Routers use the weak host model.
> Using link-locals only on an interface works just fine according to our RFCs.

But these are Unique Local Addresses, which is to say "global addresses". The only real issue I see is that they are generally advertised within a domain, and not beyond; it's not like routers handle them differently than any other GUA. Thus, the only explanations that I come up with for Ted's comment have to do with firewalls or routing; I seriously doubt that anyone else is filtering ULAs or otherwise cares about them specifically.

>> I don’t think we need to fix this—there isn’t a shortage of IPv6 addresses. The reason to use a ULA is when you need one or more prefixes but don’t have a way to get them from an internet connection. 

Or if your organization wants to limit service use by policy. An example from your company would be services that are only available to employees. IT has a policy of naming such services as "wwwin-whatever", and then presumably adding them to a filter, either in the firewall or in the host itself. Giving such hosts a ULA address and associating the address with the name in DNS would prevent outside hosts from accessing, or ddos'ing, the service.

> O.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jan 2022 13:03:47 -0500

My comment was specifically in response to the observation that we might
want to get e.g. ICMP Packet Too Big messages back, and if the ULA gets
dropped on the way back, or gets routed incorrectly because of the source
address selection issue I raised at the beginning of this long
conversation, then PMTU discovery would fail. I don't know that that's a
huge problem, but that's what I was responding to. Possibly my response
could have used a bit more context.

On Tue, Jan 4, 2022 at 12:55 PM Fred Baker <[email-masked]> wrote:

> >> If you want your IPv6 transit network to work, do not number the
> interfaces of the routers with ULAs. As you say, lots of things will break
> if you violate this rule.
> >
> A specific example would help. I would agree that blanket statements like
> this are generally not very helpful. What specifically breaks?
>
> But these are Unique Local Addresses, which is to say "global addresses".
> The only real issue I see is that they are generally advertised within a
> domain, and not beyond; it's not like routers handle them differently than
> any other GUA. Thus, the only explanations that I come up with for Ted's
> comment have to do with firewalls or routing; I seriously doubt that anyone
> else is filtering ULAs or otherwise cares about them specifically.
>
> >> I don’t think we need to fix this—there isn’t a shortage of IPv6
> addresses. The reason to use a ULA is when you need one or more prefixes
> but don’t have a way to get them from an internet connection.
>
> Or if your organization wants to limit service use by policy. An example
> from your company would be services that are only available to employees.
> IT has a policy of naming such services as "wwwin-whatever", and then
> presumably adding them to a filter, either in the firewall or in the host
> itself. Giving such hosts a ULA address and associating the address with
> the name in DNS would prevent outside hosts from accessing, or ddos'ing,
> the service.
>
> > O.
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jan 2022 08:46:06 +1300

On 05-Jan-22 07:03, Ted Lemon wrote:
> My comment was specifically in response to the observation that we might want to get e.g. ICMP Packet Too Big messages back, and if the ULA gets 
dropped on the way back, or gets routed incorrectly because of the source 
address selection issue I raised at the beginning of this long conversation, then PMTU discovery would fail. I don't know that that's a huge problem, but that's what I was responding to. Possibly my response could have used a bit more context.

Right. Effectively, ICMP offers a loophole in the rule that ULAs must be filtered at the appropriate domain boundary (and the rule that LLAs must never appear off-link). That doesn't mean: don't use ULAs (or LLAs). It means: don't use them in ICMPv6 packets with a non-local destination. You need a GUA for that.

    Brian

> 
> On Tue, Jan 4, 2022 at 12:55 PM Fred Baker <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > On Dec 22, 2021, at 6:36 AM, [email-masked] <mailto:[email-masked]> wrote:
>      >
>      > Ted,
>      >
>      > [email-masked] <mailto:[email-masked]>
>      > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Jan 2022 17:00:02 -0500

I would like to hear an argument for why any organization would want to
number their routers with ULAs.  Or more specifically, why would one use a
ULA for the source address for ICMPv6s.

(I don't care what you use to manage your router: RFC8994 even says ULAs
would be great for ACP management)

It's not just that it might break a bunch of things, it's that there seems to
be no good reason to do.  It's IPv4 scarcity think.  Allocate a /64 and
number all your routers as /128 from within.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Jan 2022 10:18:34 +1100

> Right. Effectively, ICMP offers a loophole in the rule that ULAs must be filtered at the appropriate domain boundary (and the rule that LLAs must never appear off-link). That doesn't mean: don't us…

Yes.

More generally, the simple requirement to make sure ICMPv6 works is
that the SA and DAs of an ICMPv6 message must be reachable from each
other, because that then ensures there is no SA filtering or
reachability limits that will prevent the ICMPv6 message reaching its
destination.

So an LLA or ULA SA can't be used to send an ICMPv6 message to a GUA
DA on the Internet, because BCP38 will likely drop it, and there are
no routes back to the LLA or ULA SA on the Internet, so that scenario
fails the mutual reachability requirement.

An ICMPv6 LLA SA to any on-link LLA, ULA or GUA will work.

A ULA SA to a GUA DA inside the same network, assuming full
reachability between the ULA and GUA spaces inside the local network,
will work. A GUA SA to a ULA DA in the same network would also work in
that scenario.

People could create islands of ULA or GUA address spaces with no
mutual reachability between them within their own network that would
cause ICMPv6 to fail, however all bidirectional communication would
also fail too. They have bigger problems than ICMPv6 PMTUD not
working.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 5 Jan 2022 00:43:44 +0000

What about air-gapped networks? I'm considering doing just this. It avoids involving any other organization, in the assignment of IPv6 addresses, number of subnets, subnetting architecture, or any of that.

Use the ULA prefix rules, to keep the addresses unique in each platform, document this, and no one else needs to be involved.

Bert

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Jan 2022 10:46:39 -0500

Manfredi (US), Albert E <[email-masked]> wrote:
    > What about air-gapped networks? I'm considering doing just this. It
    > avoids involving any other organization, in the assignment of IPv6
    > addresses, number of subnets, subnetting architecture, or any of that.

It also leaves you with no whois or rDNS for when the airgap fails, your
packets get out, and someone ponders who to tell.
(I see this *REGULARLY*)

IPv6 is beyond plentiful.
If I can avoid using ULA, I would always do that.  No technical entity with
more than 1000 people should be without their own assignment in my opinion.

    > Use the ULA prefix rules, to keep the addresses unique in each
    > platform, document this, and no one else needs to be involved.

Exactly.  Nobody else is involved, so nobody can ever help you.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Jan 2022 08:51:41 +1300

> If I can avoid using ULA, I would always do that.

All the same, it seems that we really need a document that
characterises use cases for ULA usage and suggests guidelines.
We've tried and failed to do that it in the past, so the
issue keeps coming up.

Regards
    Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 10 Jan 2022 16:13:59 +0000

Hi all,
ULA is different from private IPv4 in the Telco environment
Because for any additional functionality in the data plane on the transit (like SRv6)
IPv6 needs to layer another IPv6 data plane: IPv6 should be encapsulated into IPv6 by RFC 2473.
This outer IPv6 data plane effectively shields the address type used inside the Telco environment.
If ICMP would happen then it would be destined to the source of the outer IPv6 data plane (Carrier PE), not to the source of the inner data plane (user host).
Hence, even for the case of IPv4 in the inner data plane, ICMP PTB would be properly processed on ingress IPv6 PE.

Anyway, I vote against ULA for Telco infrastructure.
Because ULA would impose Carrier to have double IPv6 data plane (and only IPv6 for outer data plane) forever for all services
to shield ULA from the external audience.

The tunneling story is broken when the outer data plane is MPLS over v6. MPLS does not have its own ICMP staff to handle it properly.

Reminder, that the majority of IPv4 traffic is carried in GRT (Global Routing Table), not inside VPN.
Because many features are not developed for VPNs. And because of additional scalability requirements to routers in a VPN case.
It would be not good if RFC 2473 tunnels would become mandatory for plain IPv6 Internet traffic.

RFC 2473 tunnels for inter-domain services would request ULA routing between Carriers
That looks like a violation of ULA specification and a low-probable address collision.

Maybe a need to connect infrastructure from the Internet
That would be blocked with ULA numbering.

Hence, I see just a list of limitations. I do not understand the advantage.
The story of better security is not viable. If somebody would like such type of filtering on the perimeter then filter GUA block. It would be possible to reverse if one would change his mind or stumble upon some limitations.
ULA is a one-way ticket, not flexible. Some limitations are already evident.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, January 5, 2022 10:52 PM
To: Michael Richardson <[email-masked]>; Manfredi (US), Albert E <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

> If I can avoid using ULA, I would always do that.

All the same, it seems that we really need a document that characterises use cases for ULA usage and suggests guidelines.
We've tried and failed to do that it in the past, so the issue keeps coming up.

Regards
    Brian

On 06-Jan-22 04:46, Michael Richardson wrote:
>      > addresses, number of subnets, subnetting architecture, or any 
> of
that.
> 
> It also leaves you with no whois or rDNS for when the airgap fails, 
> your packets get out, and someone ponders who to tell.
> (I see this *REGULARLY*)
> 
> If I can avoid using ULA, I would always do that.  No technical entity 
> with more than 1000 people should be without their own assignment in my opinion.
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jan 2022 04:18:27 -0300

> The story of better security is not viable. If somebody would like such type of filtering on the perimeter then filter GUA block. It would be possible to reverse if one would change his mind or stu…

ULAs (as well as IPv4's private address space) can be useful as another
layer of isolation. If, for some reason, filters fail, a fair number of
your opponents will be unable to reach your (otherwise-exposed) services.

I've done both (ULA+GUAs, with some services only on ULAs, plus filters)
and just (just GUAs with appropriate filters).

AFAICT, ULAs have never been deprecated. As such, it's kind of
interesting that we have a feature without guidelines on how to make use
of it...

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 18 Jan 2022 11:24:04 +0000

I did not say about depreciation. For sure not.
ULA is good when a small company does not want to deal with RIR (it is not about big carriers).
ULA+NPT is the only currently working mechanism for small businesses to get redundancy from 2 PA Carriers.
The context was about big Carrier infrastructure, not Enterprise, not Home network.

Fernando,
Could you elaborate a bit more why in an attempt to emulate closed domain
It is better to filter ULA than GUA on the perimeter
(For a big Carrier)

Because in reality, it is the only positive claim of ULA for Carrier infrastructure.

Eduard
-----Original Message-----
From: Fernando Gont [mailto:fernando.gont=[email-masked]] 
Sent: Tuesday, January 18, 2022 10:18 AM
To: Vasilenko Eduard <[email-masked]>; 6man WG <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

> The story of better security is not viable. If somebody would like such type of filtering on the perimeter then filter GUA block. It would be possible to reverse if one would change his mind or stu…

ULAs (as well as IPv4's private address space) can be useful as another layer of isolation. If, for some reason, filters fail, a fair number of your opponents will be unable to reach your (otherwise-exposed) services.

I've done both (ULA+GUAs, with some services only on ULAs, plus filters) and just (just GUAs with appropriate filters).

AFAICT, ULAs have never been deprecated. As such, it's kind of interesting that we have a feature without guidelines on how to make use of it...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jan 2022 08:37:33 -0300

Hi, Eduard,

> I did not say about depreciation. For sure not.

What I mean is that there seems to be a group of people being very vocal
about how bad ULAs are (which is probably the reason why we never got
guidance on ULAs). But my take is that if they are so bad, they should
be deprecated. But if they are not, guidance should be provided.

> ULA is good when a small company does not want to deal with RIR (it is not about big carriers).

And probably also good if you need/want stable addressing within your
home network.

> The context was about big Carrier infrastructure, not Enterprise, not Home network.

Sorry, I missed the context.  That said, as noted, it may be of use in
cloud infrastructure.

> Could you elaborate a bit more why in an attempt to emulate closed domain

That's exactly the point: when you use ULAs for certain services (say,
some admin interfaces), you somewhat declare the part of a closed
domain. And that's another layer of protection -- e.g., you're filters
failed for some reason, but since you;re using GUAs, you are not fully
exposed to the 'net.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 18 Jan 2022 13:10:46 +0000

Hi Fernando,
Sorry, I do not understand why the filtering of 2 IPv6 prefixes has any difference.
Mask would be probably different for GUA (that Carrier devoted for infrastructure) and ULA (always /48),
but mask looks like not a problem.
The number of filters is the same (by the number of ports).
Why ULA segregation is better for Carrier? The Special GUA prefix looks the same effective.

IMHO:
- the carrier has no problem reserving a special GUA prefix for infrastructure
- no difference for carrier what prefix to filter on the perimeter (if it is needed in principle).

Hence, I am questioning the only claimed advantage of ULA for Carrier's infrastructure.
For disadvantages, I have presented the list before.

ULA has an advantage for small entities that do not want to deal with RIR. These are not Carrier!
Eduard
-----Original Message-----
From: Fernando Gont [mailto:fernando.gont=[email-masked]] 
Sent: Tuesday, January 18, 2022 2:38 PM
To: Vasilenko Eduard <[email-masked]>; 6man WG <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

Hi, Eduard,

> I did not say about depreciation. For sure not.

What I mean is that there seems to be a group of people being very vocal about how bad ULAs are (which is probably the reason why we never got guidance on ULAs). But my take is that if they are so bad, they should be deprecated. But if they are not, guidance should be provided.

> ULA is good when a small company does not want to deal with RIR (it is not about big carriers).

And probably also good if you need/want stable addressing within your home network.

> The context was about big Carrier infrastructure, not Enterprise, not Home network.

Sorry, I missed the context.  That said, as noted, it may be of use in cloud infrastructure.

> Could you elaborate a bit more why in an attempt to emulate closed 

That's exactly the point: when you use ULAs for certain services (say, some admin interfaces), you somewhat declare the part of a closed domain. And that's another layer of protection -- e.g., you're filters failed for some reason, but since you;re using GUAs, you are not fully exposed to the 'net.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jan 2022 15:16:43 +1100

> Why ULA segregation is better for Carrier? The Special GUA prefix looks

It isn't.

ULAs aren't reachable from the Internet, that's they're default nature. Use
ULAs for internal only infrastructure services, then they're Internet DDoS
proof by default.

As RFC5505 says, "what can be configured can be misconfigured".

Filtering GUAs is trying to take away default Internet reachability, and
there is room for misconfiguration.

With ULA addressing there is no default Internet reachability in the first
place, and no configuration required to take away something that never
existed.

We're about to use ULA addressing been our BNGs and DHCPv6 servers for the
DHCPv6 traffic so the DHCPv6 service can't be DDoS'd from the Internet.
We're also going to put in 2000::/3 only DA filters on customers so they
can't DDoS them either (less of a risk because of the customers' vested
interest in the service being available, however simple to do, so may as
well.)

Everything doesn't have to be on the Internet just because you have enough
address space to easily do so.

Regards,
Mark.

> To: Vasilenko Eduard <[email-masked]>; 6man WG <[email-masked]
> >
> guidance on ULAs). But my take is that if they are so bad, they should be
> deprecated. But if they are not, guidance should be provided.
>
>
> some admin interfaces), you somewhat declare the part of a closed domain.
> And that's another layer of protection -- e.g., you're filters failed for
> some reason, but since you;re using GUAs, you are not fully exposed to the
> 'net.
>
> Thanks,
> --
> Fernando Gont
> “This communication is the property of EdgeUno or one of its group
> companies and/or affiliates. This electronic message contains information
> which may be privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and if you are not
> the intended recipient be aware that any non-explicitly authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited, and will be considered a criminal offense. Please notify
> [email-masked] about the unintended receipt of this electronic message
> and delete it.”

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 19 Jan 2022 05:00:36 +0000

From: ipv6 <[email-masked]> On Behalf Of Mark Smith

> ULAs aren't reachable from the Internet, that's they're default nature. Use ULAs for internal only infrastructure services, then they're Internet DDoS proof by default.

Or at least, it is much easier to filter out any rogue ULAs arriving from the Internet, than it is to filter out a specific set, perhaps a huge set, of GUA prefixes. Same the other way around, to prevent your ULAs from exiting.

Yet, if you want DNS services, your internal DNS can be configured to use ULAs.

> Everything doesn't have to be on the Internet just because you have enough address space to easily do so.

Agreed. IPv6, just like IPv4, is a convenient, existing protocol, well thought out, well debugged, very flexible, lots of gear supports it, but it does not have to become associated with "the Internet" at all. Sometimes, by design, such networks, or parts of networks, must stay isolated. In these cases, ULAs seem way easier to use safely. And never mind the administrative advantage.

Bert

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 19 Jan 2022 09:35:39 +0000

Hi Mark,
This is a good argument that ULA filtering is already activated by default on all interfaces. Hence, ULA is more secure for the closed domain.
Indeed, a Firewall is more secure because everything is “deny” by default. It is considered a big part of Firewall security.
The discussion about DDoS or other security problems (for example, all other types of attacks) could be much longer in this case - your list is not full.

But is it really the case?

Is this a mistake that people are trying to add “ULA deny” to the list of Martian’s deny?
https://6session.wordpress.com/2009/04/08/ipv6-martian-and-bogon-filters/
Why they are doing it for routers? You said that it is already there.

I have found a few references of different vendors that “ULAs are treated as regular global addresses. The router configuration filters ULA prefixes to prevent them from appearing in the public domain”.

I have found a discussion that ULA is good because one does not need to change the manual filter compared to the case of dynamic PA GUA
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula-usage-recommendations

Good comment about ULA not traversing many internet hops: (yet again, assuming someone in the path cares at least a bit about security)
https://blog.ipspace.net/2013/11/dont-use-ula-addresses-in-service.html

The administrator will configure the router ACLs to restrict IP addresses that contain any Unique Local Unicast addresses
https://www.stigviewer.com/stig/perimeter_router_juniper/2018-11-28/finding/V-14703

It is evident, that everybody assumes that ULA filtering is manual. It is difficult to search for a black cat in the black room.
Hence, could you reference the particular router that has “deny ULA” on some or all interfaces by default? (probably FC::)
Because in this case vendor should have a reminder not to forget to add a separate permit for the situation when ULA is needed (with probably a longer mask).
You may know the router that has put ULA in default deny. But it is very expensive for other people to find it.
I strongly suspect that the majority of routers have a default “permit” for ULA.

Hence, again: if one needs to filter infrastructure prefix manually then no advantage for ULA against GUA.
The same human mistake is the same probable.
ULA is good only because one does not need to go to RIR. It is not applicable for Carriers.

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Wednesday, January 19, 2022 7:17 AM
To: Vasilenko Eduard <vasilenko.eduard=[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>; Fernando Gont <fernando.gont=[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

On Wed, 19 Jan 2022, 00:11 Vasilenko Eduard, <vasilenko.eduard=[email-masked]<mailto:[email-masked]>> wrote:
Hi Fernando,

It isn't.

Filtering GUAs is trying to take away default Internet reachability, and there is room for misconfiguration.

With ULA addressing there is no default Internet reachability in the first place, and no configuration required to take away something that never existed.

We're about to use ULA addressing been our BNGs and DHCPv6 servers for the DHCPv6 traffic so the DHCPv6 service can't be DDoS'd from the Internet. We're also going to put in 2000::/3 only DA filters on customers so they can't DDoS them either (less of a risk because of the customers' vested interest in the service being available, however simple to do, so may as well.)

Regards,
Mark.

IMHO:

-----Original Message-----
From: Fernando Gont [mailto:fernando.gont<mailto:fernando.gont>=[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 18, 2022 2:38 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

Hi, Eduard,

Thanks,

“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked]<mailto:[email-masked]> about the unintended receipt of this electronic message and delete it.”
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Jan 2022 12:11:56 -0300

On 19/1/22 01:16, Mark Smith wrote:
>
>
> On Wed, 19 Jan 2022, 00:11 Vasilenko Eduard,
> <vasilenko.eduard=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Fernando,
> ULAs aren't reachable from the Internet, that's they're default nature.
> Use ULAs for internal only infrastructure services, then they're
> Internet DDoS proof by default.
>
> With ULA addressing there is no default Internet reachability in the
> first place, and no configuration required to take away something that
> never existed.
>
> We're about to use ULA addressing been our BNGs and DHCPv6 servers for
> the DHCPv6 traffic so the DHCPv6 service can't be DDoS'd from the
> Internet. We're also going to put in 2000::/3 only DA filters on
> customers so they can't DDoS them either (less of a risk because of the
> customers' vested interest in the service being available, however
> simple to do, so may as well.)
>

FWIW, Mark explained the point I tried to make perfectly well. ;-)

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Jan 2022 07:58:29 +1100

Hi Eduard,

> The discussion about DDoS or other security problems (for example, all other types of attacks) could be much longer in this case - your list is not full.

All I have to do to disprove your argument that ULAs aren't useful for
carriers is provide a use case where they are. I have done that.

Which is the better operational situation, providing highest service
robustness and reliability:

- receive DDoS traffic from the Internet to a GUA address on an
infrastructure service, and then have to configure filters to drop it

- not receive DDoS traffic from the Internet to a ULA address on an
infrastructure service in the first place, because the Internet by its
nature doesn't route the ULA address space.

Erasmus answered this question 500 years ago - prevention is better than cure.

Yes.

> Why they are doing it for routers? You said that it is already there.

I did not say it was already there, although RFC4193 actually requires
it, see 4.1.

I said that ULAs aren't intended to be routed over the Internet. The
default nature of the Internet (as in the default nature of the
majority of ASes that make up the Internet) is not to route ULAs,
either the prefixes or packets with them as SAs and DAs. This is
because many network operators filter routes and also filter packets.
They're not trying to actively make ULAs work over the Internet,
unlike the GUA space.

Most network operators know that vendors don't always implement what
they should, so we put in place things like martin and bogon filters
against route announcements. That's far easier to do with IPv6 -
permit  route announcements in 2000::/3, drop everything else.

> ULA is good only because one does not need to go to RIR. It is not applicable for Carriers.

You forgot, "in my opinion".

I work for a carrier (and have worked for a number of them), ULAs are
useful to us for the reasons explained. (Many carriers have used
RFC1918s for internal only services, so this is far from a new idea).

Regards,
Mark.

> On Wed, 19 Jan 2022, 00:11 Vasilenko Eduard, <vasilenko.eduard=[email-masked]> wrote:
>
> Hi Fernando,

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 20 Jan 2022 08:54:25 +0000

Hi Mark,
Hence, you are talking that all other carriers would cooperate more on filtering, if filtering would be against ULA.
The Carriers themselves could NOT get more from ULA than GUA - any prefix is equal for the Carrier.
Others would help to get more treating ULA prefix especially.

Is it the case?

1.
Is it a good protection practice to be dependent on others in security?
What if they would make a mistake? Or would be hacked.

2.
Carriers filter on ingress, not on egress. They are protecting themselves, not others.
Hence, their subscriber base may not be filtered to try holes in the neighboring ASes.
This special (Martians) ULA filtering on the direct neighbors just does not help. Because activated not in the direction that neighboring telco is interested. 
The community of all neighbors could be rather big: the big country for example.
Hence, it is the additional protection for the small percentage of traffic that does not deserve direct peering.
Of course, the absence of a route to the prefix would help here as the second level of protection, but it would work independently from ULA or GUA.

3.
If the Carrier would not announce infrastructure GUA prefix then traffic to it would be dropped by all other Carriers in the world.
Internet is the default-free zone.

Hence, I still do not see a value from ULA for security. I agree to RFC 4193:
"Local IPv6 addresses do not provide any inherent security to the
   nodes that use them.  They may be used with filters at site
   boundaries to keep Local IPv6 traffic inside of the site, but this is
   no more or less secure than filtering any other type of global IPv6
   unicast addresses."

I see ULA value for:
- stability in the home environment that depends on PA
- avoidance of RIR in enterprise and home environment
But nothing from ULA for telco environment.

PS: Everything that we are talking about here is our opinions anyway.
Except for some people with hats that could do more.
Eduard
-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Wednesday, January 19, 2022 11:58 PM
To: Vasilenko Eduard <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

Hi Eduard,

> The discussion about DDoS or other security problems (for example, all other types of attacks) could be much longer in this case - your list is not full.

All I have to do to disprove your argument that ULAs aren't useful for carriers is provide a use case where they are. I have done that.

Which is the better operational situation, providing highest service robustness and reliability:

- receive DDoS traffic from the Internet to a GUA address on an infrastructure service, and then have to configure filters to drop it

- not receive DDoS traffic from the Internet to a ULA address on an infrastructure service in the first place, because the Internet by its nature doesn't route the ULA address space.

Yes.

> Why they are doing it for routers? You said that it is already there.

I did not say it was already there, although RFC4193 actually requires it, see 4.1.

I said that ULAs aren't intended to be routed over the Internet. The default nature of the Internet (as in the default nature of the majority of ASes that make up the Internet) is not to route ULAs, either the prefixes or packets with them as SAs and DAs. This is because many network operators filter routes and also filter packets.
They're not trying to actively make ULAs work over the Internet, unlike the GUA space.

Most network operators know that vendors don't always implement what they should, so we put in place things like martin and bogon filters against route announcements. That's far easier to do with IPv6 - permit  route announcements in 2000::/3, drop everything else.

> I have found a discussion that ULA is good because one does not need 
> to change the manual filter compared to the case of dynamic PA GUA
>
> Good comment about ULA not traversing many internet hops: (yet again, 
> assuming someone in the path cares at least a bit about security)
>
> The administrator will configure the router ACLs to restrict IP 
> addresses that contain any Unique Local Unicast addresses
>
> Hence, could you reference the particular router that has “deny ULA” 
> on some or all interfaces by default? (probably FC::)
>

I work for a carrier (and have worked for a number of them), ULAs are useful to us for the reasons explained. (Many carriers have used RFC1918s for internal only services, so this is far from a new idea).

Regards,
Mark.

> Cc: IPv6 Ops WG <[email-masked]>; Fernando Gont 
> <fernando.gont=[email-masked]>; 6man WG <[email-masked]>
> Mask would be probably different for GUA (that Carrier devoted for 
> infrastructure) and ULA (always /48), but mask looks like not a problem.
> customers so they can't DDoS them either (less of a risk because of 
> the customers' vested interest in the service being available, however 
> From: Fernando Gont 
> [mailto:fernando.gont=[email-masked]]

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Jan 2022 14:38:24 -0800

> On Jan 18, 2022, at 5:10 AM, Vasilenko Eduard <vasilenko.eduard=[email-masked]> wrote:

I would agree that guidance would be valuable. 

That said, to my small mind, the guidance is pretty straightforward: a ULA is only intended two be usable within a domain or to other domains that one has direct links to and supporting agreements with. In general, a BGP session should neither advertise nor accept advertisement of such a prefix apart from specific configuration resulting from such an agreement.

Rumination: A ULA is not a GUA. A person who assumes it is and configures a ULA when s/he should have had a GUA deserves the experience of figuring that fact out.

Rumination: A ULA could be used for a business-to-business relationship such as to a provider of a contracted service as described in https://datatracker.ietf.org/doc/html/draft-baker-v6ops-b2b-private-routing. 

I got all of that from reading RFC 4193.

What would you want to say that isn't intuitively obvious from that specification? Better, what guidance would you want to give that derives from operational experience?

BTW, when I read "ULA is bad" emails, what comes through is that the writer assumes that anything with an address is globally reachable or should be, and objects that a ULA is not globally reachable, "so service is denied to someone and they will be frustrated". I wonder whether the writer assumes that a ULA will be used in a manner similar to an RFC 1918 address behind a NAPT, and is motivated by "NAT is bad" considerations (RFC 2993). My sense is that if the entity assigning the address has the intention of denying service to the great unwashed, that will not be surprising. My next thought is that a system that has a ULA and a GUA should only use the ULA when communicating with a peer that also has a ULA in the same prefix - and I'm not sure that I know of an OS that understands that aspect of RFC 6724.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 24 Jan 2022 13:04:35 +0100

Dear Mark,

> nature doesn't route the ULA address space.

What exactly do you mean with "infrastructure service"?

Cheers, Jan Žorž
-- 
Anything that can be configured can be misconfigured. [RFC5505]

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Jan 2022 23:37:29 +1100

> What exactly do you mean with "infrastructure service"?

DHCPv6, RADIUS, syslog, OSS, NMS, orchestration services etc.

Internal infrastructure services that underpin the customer services that
ISPs provide, that have no need to be reachable from the Internet.

Regards,
Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jan 2022 09:05:19 +1300

Fred,
On 22-Jan-22 11:38, Fred Baker wrote:
> What would you want to say that isn't intuitively obvious from that specification?

I suspect that our problem comes from people *not* reading RFC 4193
carefully, because I agree that it is perfectly clear. There's
also confusion from the ambiguous use of "global" that mixes up the
mathematical notion of global scope with the practical notion of
globally reachable.

> Better, what guidance would you want to give that derives from operational experience?
> 

As far as I know, if the application chooses to use a ULA as a
destination address, IP stacks will choose a ULA as the source
address; and similarly for GUAs. That's the effect of Rule 8
(Use longest matching prefix) in RFC6724 Section 5 (Source Address
Selection).

We could discuss whether the destination address selection
algorithm in RFC6724, supposedly used by getaddrinfo() to sort
destination addresses, needs tweaking to ensure that ULAs
beat GUAs if there is a longest-match tie. (That would need
a new rule between rules 9 and 10 in Section 6.) But it's
easy enough for an app to apply that rule if it wants,
after calling getaddrinfo().

(So, this thread is mistitled - it's *destination* address
selection where there might be an issue.)

    Brian