Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Dan Lüdtke" <mail@danrl.com>
To: Peter Dolding <oiaohm@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: 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.
Date: Wed, 18 Jan 2017 13:07:56 +0100	[thread overview]
Message-ID: <9157BE7F-FAC4-4826-8493-E29F1C3D75AB@danrl.com> (raw)
In-Reply-To: <CANA3KFWy1k7L=-FFegh0_3ujw5fx6JSDS15LTbvaKg=a4_gpqQ@mail.gmail.com>

I don't see a bug here. And no patches. And still no code. Only plenty of tl=
;dr. I think the only thing we can do is to agree to disagree.

> On 18 Jan 2017, at 12:21, Peter Dolding <oiaohm@gmail.com> wrote:
>=20
>> On Wed, Jan 18, 2017 at 4:11 PM, Dan L=C3=BCdtke <mail@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 mys=
elf have run both, isp + carrier networks, and i call BS on your future outl=
ook regarding nat ipv6)
>> - code from you in this thread
>>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> The problem is the type of NAT used.
> https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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..
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> .
> Peter Dolding

  reply	other threads:[~2017-01-18 11:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-02  6:10 Peter Dolding
2017-01-02 14:18 ` Jason A. Donenfeld
2017-01-05 11:08   ` Peter Dolding
2017-01-05 20:33     ` Jason A. Donenfeld
2017-01-09 13:43       ` Peter Dolding
2017-01-15  8:39         ` Dan Lüdtke
2017-01-15 10:55           ` Jason A. Donenfeld
2017-01-18  5:55           ` Peter Dolding
2017-01-18  6:11             ` Dan Lüdtke
2017-01-18 11:21               ` Peter Dolding
2017-01-18 12:07                 ` Dan Lüdtke [this message]
2017-01-21 21:51                   ` Peter Dolding
2017-01-22 23:29                     ` Jason A. Donenfeld
2017-01-15 10:40         ` Jason A. Donenfeld
2017-01-18  7:38           ` Peter Dolding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9157BE7F-FAC4-4826-8493-E29F1C3D75AB@danrl.com \
    --to=mail@danrl.com \
    --cc=oiaohm@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).