Will the data transfer with the destination on the same LAN network be routed through the internet when the...
I'm planning to set up a Nextcloud locally. I will be using my own domain with a DNS record to connect to my WAN IP and port forward the needed ports to the local machine running Nextcloud.
Now of course on the client devices I'm going to set up Nextcloud using the domain.
So I'm wondering:
Will the data transfer be routed through the internet, despite me being connected to the host LAN or not?
How far will this affect the transfer speed? (I'm on a 35 Mbit/s down - 7 Mbit/s up VDSL connection)
Maybe this also depends on the ISP / router that will be used?
thanks!
routing nat speed
|
show 1 more comment
I'm planning to set up a Nextcloud locally. I will be using my own domain with a DNS record to connect to my WAN IP and port forward the needed ports to the local machine running Nextcloud.
Now of course on the client devices I'm going to set up Nextcloud using the domain.
So I'm wondering:
Will the data transfer be routed through the internet, despite me being connected to the host LAN or not?
How far will this affect the transfer speed? (I'm on a 35 Mbit/s down - 7 Mbit/s up VDSL connection)
Maybe this also depends on the ISP / router that will be used?
thanks!
routing nat speed
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
1
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20
|
show 1 more comment
I'm planning to set up a Nextcloud locally. I will be using my own domain with a DNS record to connect to my WAN IP and port forward the needed ports to the local machine running Nextcloud.
Now of course on the client devices I'm going to set up Nextcloud using the domain.
So I'm wondering:
Will the data transfer be routed through the internet, despite me being connected to the host LAN or not?
How far will this affect the transfer speed? (I'm on a 35 Mbit/s down - 7 Mbit/s up VDSL connection)
Maybe this also depends on the ISP / router that will be used?
thanks!
routing nat speed
I'm planning to set up a Nextcloud locally. I will be using my own domain with a DNS record to connect to my WAN IP and port forward the needed ports to the local machine running Nextcloud.
Now of course on the client devices I'm going to set up Nextcloud using the domain.
So I'm wondering:
Will the data transfer be routed through the internet, despite me being connected to the host LAN or not?
How far will this affect the transfer speed? (I'm on a 35 Mbit/s down - 7 Mbit/s up VDSL connection)
Maybe this also depends on the ISP / router that will be used?
thanks!
routing nat speed
routing nat speed
edited Dec 15 '18 at 16:40
jonathanjo
11.4k1934
11.4k1934
asked Dec 14 '18 at 17:33
UmizoomiUmizoomi
232
232
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
1
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20
|
show 1 more comment
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
1
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
1
1
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20
|
show 1 more comment
1 Answer
1
active
oldest
votes
I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "496"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f55476%2fwill-the-data-transfer-with-the-destination-on-the-same-lan-network-be-routed-th%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
add a comment |
I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
add a comment |
I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.
I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.
edited Dec 14 '18 at 19:43
answered Dec 14 '18 at 17:47
jonathanjojonathanjo
11.4k1934
11.4k1934
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
add a comment |
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
Hairpinning requires the router to do dual NAT. While it won't consume your Internet bandwidth, it does make your router do a lot of extra work and requires all the packets to travel over the connection between your router and your LAN twice. You can easily max out your router's ability to route and this can cause your Internet connection to work more slowly because the router's overloaded.
– David Schwartz
Dec 14 '18 at 22:01
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f55476%2fwill-the-data-transfer-with-the-destination-on-the-same-lan-network-be-routed-th%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You are talking about hairpin routing, which is pretty inefficient. It would be better to have a separate DNS entry on your own network that points to the local address, then the traffic will never hit the router, but be delivered directly from host-to-host.
– Ron Maupin♦
Dec 14 '18 at 17:36
It mainly depends on whether you are using NAT. You'll get the best performance if you avoid NAT. If the ISP cannot give you enough IPv4 addresses to avoid the need for NAT you should ask them for IPv6 instead. I also suggest you take a look on my answer to a related question on Super User.
– kasperd
Dec 14 '18 at 19:27
@kasperd The original question speaks of WAN IP address and port forwarding, so definitely is NAT. Of course, "use public addresses" is actually a good answer to the problem.
– jonathanjo
Dec 14 '18 at 19:41
@jonathanjo You are right, it is actually clear from the question that NAT is involved. That just means the rest of my comment remains relevant. I still recommend avoiding NAT in this case which might require the use of IPv6. A solution without NAT will give better performance than even the best optimized hairpin NAT setup can achieve.
– kasperd
Dec 14 '18 at 20:30
1
@kasperd ... as I said, using public addresses is an excellent way of addressing this issue, and certainly hairpin is generally considered undesirable. Opinions do vary widely on IPv6 though.
– jonathanjo
Dec 14 '18 at 21:20