coupergateway / couper

Couper is a lightweight API gateway designed to support developers in building and operating API-driven Web projects
https://couper.io
MIT License
85 stars 15 forks source link

remove ipv6 restrictions #683

Closed malud closed 9 months ago

malud commented 1 year ago

Go is able to handle this but we have restricted the bind and (backend) connect options to ipv4 for simplicity. I guess we could just allow this format and create an option to disable the ipv6 bindings and connections.

Update: So the discussion below leads to the following config proposal:

This applies to the server {} block(s) bindings:

# environment: COUPER_BIND_ADDRESS="0.0.0.0,10.1.0.22"
# cli: -bind-address=0.0.0.0,10.1.0.22
settings {
  # default: * means both types, all interfaces
  # :: just v6
  # 0.0.0.0 just v4
  # 10.1.0.22 a very specific one, who knows...
  bind_address = ["*", "::", "0.0.0.0", "10.1.0.22"]
}

for the outgoing backend connection configuration:


# per backend block
backend {
  ivp6 = true
}

# for all backends
settings {
  #environment: COUPER_BACKEND_IPV6=true
  #cli: -backend-ipv6
  backend_ipv6 = true
}

The all backends option will override the specific ones. 
filex commented 1 year ago

Yes, we should remove that. When using Couper during development on a local machine (in my case MacOS), localhost is often preferably resolved to its IPv6 IP. That leads to surprising "connection refused" errors when using e.g. http://localhost:8080 instead of http://127.0.0.1:8080. This happens for example if an SPA server like webpack or vite proxy an API path to Couper. It would be good to be able to use localhost for that config.

filex commented 1 year ago

Which kind of configuration would we provide?

this depends on how likely it is that IPv6 causes problems.

malud commented 1 year ago

For the server {} part I would say let's add a more generic setting:

settings {
  # default: * means both types, all interfaces
  # :: just v6
  # 0.0.0.0 just v4
  # 10.1.0.22 a very specific one, who knows...
  bind_address = ["*", "::", "0.0.0.0", "10.1.0.22"]
}

and for the backend part I would use a per backend configuration:

backend {
  # so it would not break(?) existing setups
  # also a rare case while living in the pod world, use-case: wan origins
  use_ipv6 = true
}
filex commented 1 year ago

How could I add multiple bind IPs on the CLI?

$ couper run --bind ::,0.0.0.0
$ couper run --bind :: --bind 0.0.0
malud commented 1 year ago

I would suggest comma separated since it aligns best with the environment equivalent.

filex commented 1 year ago

So backend.use_ipv6 would default to false?

malud commented 1 year ago

So backend.use_ipv6 would default to false?

yes.

filex commented 1 year ago

would it be useful to have a global use_ipv6 switch, too? to make all backends use ipv6 without cluttering the whole config. That setting could also affect IP binding implicitly.

malud commented 1 year ago

would it be useful to have a global use_ipv6 switch, too? to make all backends use ipv6 without cluttering the whole config. That setting could also affect IP binding implicitly.

I would go with a global backend switch which does not affect the bind options.

filex commented 1 year ago

How would we call that switch? --backend-ipv6 and COUPER_BACKEND_IPV6=true. I think it is good to have the „backend“ prefix in the switch. But „use“ seems too verbose here. Should we use backend.ipv6 = true in the config, too?

malud commented 1 year ago

sounds good. I will update the description.

malud commented 1 year ago

Update done. So we do not want to enable -backend-ipv6 for all backend and disable this for a single one?

backend {
  ipv6 = false
}

Technically we could check for the existing attribute (syntax or bool ptr).

alex-schneider commented 1 year ago

The outgoing backend connection uses/supports already both IPv4 and IPv6.

We need not the backend_ipv6 = true in the settings and in the backend block...

filex commented 1 year ago

The outgoing backend connection uses/supports already both IPv4 and IPv6.

Ah, really? So if that is not a change, then I would agree that we don't need to make it configureable now.


Von: Alex Schneider @.***> Gesendet: Donnerstag, 6. April 2023 11:11 An: avenga/couper Cc: Felix Hassert; Comment Betreff: Re: [avenga/couper] remove ipv6 restrictions (Issue #683)

The outgoing backend connection uses/supports already both IPv4 and IPv6.

We need not the backend_ipv6 = true in the settings and in the backend block...

— Reply to this email directly, view it on GitHubhttps://github.com/avenga/couper/issues/683#issuecomment-1498738197, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAD3OQX2LVRSFN6LRZUGKFTW72CD3ANCNFSM6AAAAAAUME2T4Y. You are receiving this because you commented.Message ID: @.***>

rcanavan commented 1 year ago

Does it use https://en.wikipedia.org/wiki/Happy_Eyeballs for outgoing connections?

filex commented 1 year ago

We use the resolver/dialer from the standard Go lib. AFAIK, it does a dial race for ipv4/6.


Von: rcanavan @.***> Gesendet: Donnerstag, 6. April 2023 12:51 An: avenga/couper Cc: Felix Hassert; Comment Betreff: Re: [avenga/couper] remove ipv6 restrictions (Issue #683)

Does it use https://en.wikipedia.org/wiki/Happy_Eyeballs for outgoing connections?

— Reply to this email directly, view it on GitHubhttps://github.com/avenga/couper/issues/683#issuecomment-1498872519, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAD3OQXUSI2WQPFV5PT4GBLW72NZPANCNFSM6AAAAAAUME2T4Y. You are receiving this because you commented.Message ID: @.***>