Built-in Roaming is limited due to a design fault adding STUN and TURN support would be good and make wire-guard connections more durable.

Peter Dolding oiaohm at gmail.com
Wed Jan 18 12:21:16 CET 2017


On Wed, Jan 18, 2017 at 4:11 PM, Dan Lüdtke <mail at danrl.com> wrote:
> Two things I have not seen so far:
> - government regulations that enforce NAT
> - ISPs (let alone carriers) "upgrading" their networks to ipv6 nat (i myself have run both, isp + carrier networks, and i call BS on your future outlook regarding nat ipv6)
> - code from you in this thread
>
https://en.wikipedia.org/wiki/Internet_censorship
When you start looking into countries that are red in the "World map
showing the status of YouTube blocking"  you will find some of those
its mandatory to have a NAT between ISP and open internet even for
IPv6.  Yes the area of infect users is currently small.  But when you
look a countries implementing more regulations we cannot be sure how
small this will remain.

I would say your outlook is wishful thinking that is willing to ignore
about 10 percent of the users on the internet who don't have well
behaved Carriers or Governments.

So Dan you are doing a works for me arguement what is the most invalid
arguement to-do in many cases.   Its lets sweep a bug under a carpet
and not consider it.

The problem is the type of NAT used.
https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT

Symmetric NAT  this nicely randomises what address users behind it are
coming from.    Usage of Symmetric NAT does not have to have anything
to-do with reducing the number of IP addresses in usage.   Symmetric
NAT can have equal number of users to internet address.

Symmetric NAT is the brick wall from hell to hole punching.    The
main objective of a Symmetric NAT is that something in the internet
that has not had a packet from something behind the Symmetric NAT
blocked by default.   Add in symmetric NAT randomising IP to IP
mapping.     So after IPv4 disappears what Symmetric NAT still has a
usage in IPv6.

Teredo that is IPv6 over IPv4 fails if both ends are behind Symmetric
NAT.    Normal STUN for NAT punching falls over if both ends are
behind Symmetric NAT this does not matter if it IPv4 or iPv6.
Symmetric NAT randomising ip to ip mapping bring hell.   So you opened
up a connection after so much time the Symmetric NAT forgets and you
attempt to send another packet to a end and it picks out a new IP
address at random to use.

The three types cone style NAT will stay in usage by client routers by
different Carriers even after IPv6 is dominate everywhere as it make
sense at that point so being able to punch though those at times will
still be required.

So the 4 types of common NAT are not going anywhere were they were
used for common sense reasons.   The Carrier NAT attempting to push
massive numbers of users though limited addresses will hopefully
disappear due to IPv6.

 Basically Dan is about time you step back look at NAT how it used and
where is used and why.    The change to IPv6 is only really getting
rid of one form of NAT  being the carrier nat that were non Symmetric
NAT based on Symmetric NAT ideas that at times had massive problems
like completely running out of ports due to not enough address because
attempting to push too many clients out too few of addresses.

 If somewhere has a pure Symmetric NAT where the number of external
address match the number of internal address for IPv4 for security
reasons doing the same thing on IPv6 has the same logical reasons.
So logically sane placed Symmetric NAT will remain and when you have
to get though them the same problems will remain.

The reality is the 4 common types of NAT can be deployed sanely
without massive over-stacking.   Under IPv6 the worse we should see is
hopefully only 2 NAT deep.     Possible 3 mode cone NAT in router and
Carrier with a Symmetric NAT between you and the internet. as long as
what ever is design can get though this worse case all cases will be
covered.   .  Why hopefully only 2 nat deep It is possible to have
like ADSL router NAT + a WIFI router doing NAT and Carrier doing
Symmetric NAT but the wifi NAT level is kinda self inflicted by user
on self not forced on user by carrier this is an improvement over the
3 to 4 deep in nat by carrier in some places..

Dan attempting to code when the required interfaces to make it work
don't exist and have not been debated does not make much sense.   Also
attempting to tell boss time this will need roughly to give something
functional also not be guessed when you are in the location that there
is a framework problem.

IPv6 is improving something things.   But IPv6 is not a magic bullet
to cure all the issues of having at times to get through NAT.

Basically it is BS the that existence of NAT can be ignored because
IPv6 fixes everything.   IPv6 pure once fully deployed by all carriers
should reduce the number of NAT you have to cross on the internet.
The big elephant in the room is that IPv6 is only going to reduce the
number of NAT in the internet not remove them all.

So working out how to handle the case that end user has found
themselves on the wrong side of deployed NATs applies to IPv4 and IPv6
with IPv6 hopefully being less glitch due to lower numbers of NAT in
the mix.

 Think if a company can use an accounts that is behind a Symmetric NAT
without having to pay extra or do extra government regulation  for a
static public internet IP address might reduce their costs of doing
business.    Also consider the ones most commonly going to be stuck
behind Symmetric NAT are also the places that will have massive
amounts of government regulation that can forbid having private keys
on overseas servers and and using overseas vpn servers.   Using a
Relay/TURN server is hair splitting as it not a overseas VPN server
its only an overseas relay at worst.

Reality Dan look out side your small conner of the earth.   New
standards does not change how messed up world internet regulations by
different governments are or different carriers stunts to make more
money.

.
Peter Dolding


More information about the WireGuard mailing list