Vraag Hoe slecht is de uitputting van het IPv4-adres eigenlijk?


Al jaren schrijft de pers over het probleem dat er momenteel maar heel weinig IPv4-adressen beschikbaar zijn. Maar aan de andere kant, gebruik ik een serverhostingbedrijf dat graag openbare IPv4-adressen voor een kleine hoeveelheid geld verspreidt. En mijn privé-internetverbinding wordt geleverd met een openbaar IPv4-adres.

Hoe is dat mogelijk? Is het probleem zo slecht als de pers wil dat we geloven?


161
2018-01-28 14:01


oorsprong


Sommige bedrijven hebben nog steeds veel IPv4-adressen bij de hand. Anderen hebben heel weinig. Ik moet heel goed nadenken over het gebruik van een IPv4-adres; als resultaat heb ik nogal wat machines met alleen IPv6. - Michael Hampton♦
Het geeft je ook een beetje perspectief op de hoeveelheid pijn. ISP's zijn bereid anderen te laten voorkomen dat ze IPv6 moeten gebruiken. - immibis
Ik zou het niet noemen slecht, maar het is zeker een pijn. Dat gezegd hebbende, de meeste verbruikers het kan waarschijnlijk niet schelen dat ze achter een nat zijn, aangenomen dat Facebook en WhatsApp werken. - Journeyman Geek
@JourneymanGeek Nou, gemiddelde consumenten geven niet echt om iets dat ze niet begrijpen. Er zijn bijvoorbeeld ideeën voor gedistribueerde sociale media (omdat dat het erg moeilijk maakt om te censureren), maar niemand geeft nog om zulke dingen tot na ze zijn van de grond gekomen, wat ze niet kunnen vanwege NAT. Ik denk dat NAT een van de redenen is waarom we met een gecentraliseerd web zijn beland, omdat het in principe onmogelijk is om je eigen website te hosten zonder iemand te betalen. - immibis
Zoals @Azendale al aangaf, is de hosting van gameservers een grote. Waarom kan ik niet gewoon minecraft_server.exe uitvoeren en mijn vrienden mijn adres geven? Vanwege NAT. "Consumenten" willen zeker soms gameservers uitvoeren. - immibis


antwoorden:


Het is heel slecht. Hier is een lijst met voorbeelden van wat ik uit de eerste hand heb opgedaan met ISP's van consumenten om het tekort aan IPv4-adressen te bestrijden:

  • Herhaaldelijk heen en weer schuifelen rond IPv4-blokken tussen steden waardoor korte onderbrekingen en resets voor verbindingen voor klanten worden veroorzaakt.
  • Verkorting DHCP leasetijden van dagen tot minuten.
  • Sta gebruikers toe te kiezen als ze willen netwerk adres vertaling (NAT) op de Customer Premise Equipment (CPE) of niet, zet het dan met terugwerkende kracht toch voor iedereen aan.
  • NAT inschakelen voor CPE voor klanten die al gebruik hebben gemaakt van de mogelijkheid om zich af te melden voor NAT.
  • Het verminderen van de dop op het aantal gelijktijdig actieve MAC-adressen (media access control) opgelegd door CPE.
  • Het inzetten carrier-grade NAT (CGN) voor klanten die een echt IP-adres hadden toen ze zich aanmeldden voor de service.

Dit alles vermindert de kwaliteit van het product dat de ISP aan hun klanten verkoopt. De enige verstandige verklaring waarom ze dit zouden doen voor hun klanten is een tekort aan IPv4-adressen.

Het tekort aan IPv4-adressen heeft geleid tot fragmentatie van de adresruimte met meerdere tekortkomingen:

Zonder NAT kunnen we vandaag de weg niet vinden met de 3700 miljoen routeerbare IPv4-adressen. Maar NAT is een brosse oplossing die u een minder betrouwbare connectiviteit en problemen geeft die moeilijk te debuggen zijn. Hoe meer lagen NAT, hoe erger het zal zijn. Twee decennia van hard werken hebben ervoor gezorgd dat een enkele laag NAT voornamelijk werkt, maar we zijn al zover dat een enkele NAT-laag voldoende was om het tekort aan IPv4-adressen te omzeilen.


174
2018-01-28 14:31



Een ding om toe te voegen is dat NAT ook leidt tot kwaadwillende gebruikers die normale gebruikers treffen en maakt IP in het algemeen onbetrouwbaar als een mechanisme voor gebruikersdifferentiatie. Bijvoorbeeld Wikipedia blokkeert bijna elke Qatari-gebruiker vanwege het vandalisme van een of enkele gebruikers. - IllusiveBrian
@IllusiveBrian maakt een geldig punt. Ik heb een ad-targeting-software geërfd die IP-adressen als primaire ID gebruikte. Dit is tegenwoordig niet voldoende en moest uitgebreid worden aangepast om het betrouwbaar te houden. India en Griekenland lijken twee van de zwaarst getroffen landen te zijn. Ik zie een advertentie 100 keer per dag uit dezelfde IPv4 worden geraakt, maar elke treffer kan een andere gebruiker zijn, bepaald door andere volgmethoden - Darren H
@DmitriySintsov niet meer dan een eenvoudige, stateful firewall. Als een edge-apparaat NAT kan doen, kan het stateful firewallen. - mfinni
@DarrenH "ad-targeting software die IP-adressen gebruikte als een primaire identifier ... en uitgebreid moest worden aangepast om het betrouwbaar te houden." Nou, die reden alleen is genoeg om NAT te behouden. - Andy
@DarrenH Het is gewoon een opmerking over het niet leuk vinden van advertentiesoftware, welke toon je ook voelt, is in je hoofd. - Andy


Voordat we geen IPv4-adressen meer hadden, gebruikten we (op grote schaal) NAT niet. Elke computer met internetverbinding zou een eigen uniek adres hebben. Toen NAT voor het eerst werd geïntroduceerd, was het om de klanten van ISP één echt adres per apparaat te geven dat de klant gebruikte / bezat om 1 klant 1 echt adres te geven. Dat loste het probleem een ​​tijdje (jaren) op terwijl we moesten overschakelen naar IPv6. In plaats van over te schakelen naar IPv6, wachtte (meestal) iedereen op iedereen om over te schakelen en dus (meestal) heeft niemand IPv6 uitgerold. Nu pakken we hetzelfde probleem opnieuw aan, maar deze keer wordt een tweede laag NAT (CGN) ingezet, zodat ISP's 1 echt adres kunnen delen met meerdere klanten.

IP-adresuitputting is geen groot probleem als NAT niet verschrikkelijk is, ook niet als de eindgebruiker er geen controle over heeft (Carrier Grade NAT of CGN).

Maar ik zou zeggen dat NAT verschrikkelijk is, vooral in het geval dat de eindgebruiker er geen controle over heeft. En (als een persoon wiens taak netwerkengineering / administratie is, maar een graad in software-engineering heeft), zou ik willen beweren dat netwerkbeheerders door het gebruik van NAT in plaats van IPv6 het gewicht hebben verhoogd van het oplossen van de uitputting van het adres uit hun veld en naar eindgebruikers. en applicatieontwikkelaars.

Dus (naar mijn mening), waarom is NAT een verschrikkelijk, slecht ding dat vermeden moet worden?

Laten we kijken of ik het recht kan doen door uit te leggen wat het breekt (en welke problemen het veroorzaakt dat we er zo aan gewend zijn geraakt dat we ons niet eens realiseren dat het beter zou kunnen zijn):

  • Netwerklaag onafhankelijkheid
  • Peer-to-peer verbindingen
  • Consistente naamgeving en locatie van bronnen
  • Optimale routering van verkeer, hosts die hun echte adres kennen
  • De bron van kwaadaardig verkeer volgen
  • Netwerkprotocollen die gegevens en besturing scheiden in afzonderlijke verbindingen

Laten we kijken of ik al deze items kan uitleggen.

Netwerklaag onafhankelijkheid

ISP's worden verondersteld alleen laag 3-pakketten te passeren en niet te schelen wat zich in de lagen daarboven bevindt. Of je nu TCP, UDP, of iets beters / exotischers doorgeeft (SCTP misschien? Of zelfs een ander protocol dat beter is dan TCP / UDP, maar onduidelijk is vanwege een gebrek aan NAT-ondersteuning), je ISP mag niet zorg; het zou allemaal moeten lijken op gegevens voor hen.

Maar dat is het niet - niet wanneer ze de "tweede golf" van NAT, "Carrier Grade" NAT, implementeren. Vervolgens moeten ze noodzakelijkerwijs de laag 4-protocollen die u wilt gebruiken, bekijken en ondersteunen. Op dit moment betekent dit praktisch dat je alleen TCP en UDP kunt gebruiken. Andere protocollen zouden ofwel gewoon worden geblokkeerd / verwijderd (overgrote meerderheid van de gevallen in mijn ervaring) of gewoon doorgestuurd worden naar de laatste host "binnen" de NAT die dat protocol gebruikte (ik heb 1 implementatie gezien die dit doet). Zelfs doorsturen naar de laatste host die dat protocol gebruikte, is geen echte oplossing - zodra twee hosts het gebruiken, breekt het.

Ik kan me voorstellen dat er een aantal vervangende protocollen voor TCP en UDP zijn die momenteel niet getest en ongebruikt zijn vanwege dit probleem. Begrijp me niet verkeerd, TCP & UDP waren indrukwekkend goed ontworpen en het is verbazingwekkend hoe ze beide hebben kunnen opschalen naar de manier waarop we vandaag het internet gebruiken. Maar wie weet wat we gemist hebben? Ik heb gelezen over SCTP en het klinkt goed, maar heb het nooit gebruikt omdat het onpraktisch was vanwege NAT.

Peer-to-peer-verbindingen

Dit is een grote. Eigenlijk de grootste naar mijn mening. Als u twee eindgebruikers hebt, beide achter hun eigen NAT, ongeacht welke verbinding eerst wordt geprobeerd, laat de NAT van de andere gebruiker zijn pakket vallen en is de verbinding niet gelukt.

Dit is van invloed op games, spraak- / videochat (zoals Skype), hosting van uw eigen servers, enz.

Er zijn oplossingen. Het probleem is dat deze tijdelijke oplossingen kosten van ontwikkelaarstijd, eindgebruikerstijd en ongemak kosten of kosten van de servicefrastructuur kosten. En ze zijn niet waterdicht en breken soms. (Zie opmerkingen van andere gebruikers over de uitval van Skype.)

Een workaround is port forwarding, waarbij u het NAT-apparaat programmeert om een ​​specifieke inkomende poort door te sturen naar een specifieke computer achter het NAT-apparaat. Er zijn hele websites gewijd aan hoe dit te doen voor alle verschillende NAT-apparaten die er zijn. Zien https://portforward.com/. Dit kost doorgaans de tijd en frustratie van eindgebruikers.

Een andere oplossing is om ondersteuning toe te voegen voor zaken als perforeren naar toepassingen en onderhouden van serverinfrastructuur die niet achter een NAT staat om twee NATed-clients te introduceren. Dit kost gewoonlijk ontwikkelingstijd en stelt ontwikkelaars in staat om de serverinfrastructuur mogelijk te onderhouden waar dit voorheen niet nodig was.

(Weet je nog wat ik zei over het gebruik van NAT in plaats van IPv6, waardoor het gewicht van het probleem verschoof van netwerkbeheerders naar eindgebruikers en applicatieontwikkelaars?)

Consistente naamgeving / locatie van netwerkbronnen

Omdat aan de binnenkant van een NAT en vervolgens aan de buitenkant een andere adresruimte wordt gebruikt, heeft elke service die wordt aangeboden door een apparaat in een NAT, meerdere adressen om deze te bereiken, en de juiste die moet worden gebruikt, is afhankelijk van waar de client toegang tot heeft vanaf . (Dit is nog steeds een probleem, zelfs nadat u port forwarding hebt gekregen.)

Als u een webserver in een NAT hebt, bijvoorbeeld op poort 192.168.0.23 poort 80, en uw NAT-apparaat (router / gateway) heeft een extern adres van 35.72.216.228 en u poortdoorschakeling instelt voor TCP-poort 80, nu uw webserver is toegankelijk via poort 192 808.80.2 poort 80 OF 35.72.216.228. Welke u moet gebruiken, hangt af van of u zich binnen of buiten de NAT bevindt. Als u zich buiten de NAT bevindt en het adres 192.168.0.23 gebruikt, komt u niet waar u verwacht. Als u zich binnen de NAT bevindt, en u gebruikt het externe adres 35.72.216.228, u macht krijg waar je wilt, als uw NAT-implementatie een geavanceerde is die haarspeld ondersteunt, maar dan zal de webserver die aan uw verzoek voldoet, zien dat het verzoek afkomstig is van uw NAT-apparaat. Dit betekent dat al het verkeer door het NAT-apparaat moet gaan, zelfs als er een korter pad in het netwerk achter de NAT is, en dit betekent dat logbestanden op de webserver veel minder nuttig worden omdat ze allemaal het NAT-apparaat als de bron van de verbinding. Als uw NAT-implementatie haarspeld niet ondersteunt, zult u niet komen waar u verwachtte te gaan.

En dit probleem wordt erger zodra u DNS gebruikt. Plotseling, als je wilt dat alles naar behoren werkt voor iets dat gehost wordt achter NAT, wil je verschillende antwoorden geven op het adres van de dienst gehost in een NAT, op basis van wie het vraagt ​​(AKA split horizon DNS, IIRC). Bah.

En dat alles gaat ervan uit dat iemand kennis heeft van port forwarding en hairpin NAT en split horizon DNS. Hoe zit het met eindgebruikers? Hoe groot is de kans dat dit allemaal goed werkt wanneer ze een consumentenrouter en een aantal IP-beveiligingscamera's kopen en willen dat deze "gewoon werken"?

En dat brengt mij ertoe om:

Optimale routering van verkeer, hosts die hun echte adres kennen

Zoals we hebben gezien, vloeit het NAT-verkeer niet altijd door het optimale pad, zelfs niet met geavanceerde haarspeldbochten. Dat is zelfs het geval wanneer een deskundige beheerder een server opzet en haarspeld NAT heeft. (Toegegeven, gesplitste horizon-DNS kan leiden tot optimale routering van intern verkeer in handen van een netwerkbeheerder.)

Wat gebeurt er wanneer een applicatieontwikkelaar een programma zoals Dropbox maakt en het distribueert naar eindgebruikers die niet gespecialiseerd zijn in het configureren van netwerkapparatuur? Wat gebeurt er in het bijzonder wanneer ik een bestand van 4 GB in mijn gedeelde bestand plaats en vervolgens probeer toegang te krijgen tot de volgende computer? Kan het direct worden overgedragen tussen de machines of moet ik wachten tot het naar een cloudserver wordt geüpload via een trage WAN-verbinding en vervolgens een tweede keer wachten totdat het via dezelfde langzame WAN-verbinding wordt gedownload?

Voor een naïeve implementatie zou het worden geüpload en vervolgens worden gedownload, met behulp van de Dropbox-serverinfrastructuur die niet achter een NAT staat als bemiddelaar. Maar als de twee machines zich alleen maar konden realiseren dat ze zich op hetzelfde netwerk bevonden, dan konden ze het bestand gewoon veel sneller rechtstreeks overbrengen. Dus voor onze eerste minder naïef implementatietip, kunnen we het besturingssysteem vragen welke IP (v4) -adressen de machine heeft, en dat dan controleren tegen andere machines die zijn geregistreerd op hetzelfde Dropbox-account. Als het in hetzelfde bereik ligt als wij, hoeft u alleen maar het bestand direct over te zetten. Dat zou in veel gevallen kunnen werken. Maar zelfs dan is er een probleem: NAT werkt alleen omdat we adressen kunnen hergebruiken. Dus wat als het 192.168.0.23-adres en het 192.168.0.42-adres dat op hetzelfde Dropbox-account is geregistreerd zich daadwerkelijk op verschillende netwerken bevinden (zoals uw thuisnetwerk en uw werknetwerk)? Nu moet je terugvallen op het gebruik van de Dropbox-serverinfrastructuur om te bemiddelen. (Uiteindelijk probeerde Dropbox het probleem op te lossen door elke Dropbox-client uit te zenden op het lokale netwerk in de hoop andere clients te vinden. Maar die uitzendingen kruisen geen routers die je achter de NAT hebt, wat betekent dat het geen volledige oplossing is , vooral in het geval van CGN.)

Statische IP's

Bovendien, aangezien het eerste tekort (en de golf van NAT) plaatsvond toen veel consumentenverbindingen niet altijd verbindingen hadden (zoals inbelverbindingen), konden ISP's hun adressen beter gebruiken door alleen openbare / externe IP-adressen toe te wijzen wanneer u daadwerkelijk verbonden was. Dat betekende dat wanneer je verbonden was, je hebt welk adres dan ook beschikbaar was, in plaats van altijd hetzelfde adres te krijgen. Dat maakt het veel moeilijker om je eigen server te gebruiken en het maakt het ontwikkelen van peer-to-peer-applicaties moeilijker omdat ze moeten omgaan met peers die rondlopen in plaats van vaste adressen te hebben.

Obfuscatie van de bron van kwaadaardig verkeer

Omdat NAT uitgaande verbindingen opnieuw schrijft alsof ze afkomstig zijn van het NAT-apparaat zelf, wordt al het gedrag, goed of slecht, in één extern IP-adres gerold. Ik heb geen NAT-apparaat gezien dat standaard elke uitgaande verbinding registreert. Dit betekent dat de bron van kwaadwillig verkeer in het verleden standaard alleen kan worden getraceerd naar het NAT-apparaat dat het heeft doorlopen. Hoewel de meer enterprise- of carrierklasse-apparatuur kan worden geconfigureerd om elke uitgaande verbinding te registreren, heb ik nog geen consumentenrouters gezien die dit doen. Ik denk zeker dat het interessant zal zijn om te zien of (en voor hoe lang) ISP's een logboek bijhouden van alle TCP- en UDP-verbindingen die via CGN's worden gemaakt terwijl ze deze uitrollen. Dergelijke gegevens zouden nodig zijn om misbruikklachten en DMCA-klachten te behandelen.

Sommige mensen denken dat NAT de veiligheid verhoogt. Als dat zo is, gebeurt dit door vergetelheid. De standaarddaling van inkomend verkeer die NAT verplicht stelt, is hetzelfde als een stateful firewall hebben. Ik ben van mening dat elke hardware die geschikt is voor het volgen van verbindingen die nodig is voor NAT, in staat moet zijn om een ​​stateful firewall te draaien, dus NAT verdient daar eigenlijk geen punten.

Protocollen die een tweede verbinding gebruiken

Protocollen zoals FTP en SIP (VoIP) hebben de neiging om afzonderlijke verbindingen te gebruiken voor controle en feitelijke gegevensinhoud. Elk protocol dat dit doet, moet helper-software hebben die een ALG (Application Layer Gateway) wordt genoemd op elk NAT-apparaat dat het doorgeeft, of het probleem omzeilen met een soort mediator of perforeren. In mijn ervaring zijn ALG's zelden of nooit bijgewerkt en zijn ze de oorzaak geweest van ten minste een paar problemen die ik heb behandeld met betrekking tot SIP. Elke keer als ik iemand hoor melden dat VoIP niet voor hen werkte omdat audio maar op één manier werkte, vermoed ik meteen dat ergens een NAT-gateway UDP-pakketten laat vallen die niet kunnen achterhalen wat te doen.

Samenvattend, NAT heeft de neiging om te breken:

  • alternatieve protocollen voor TCP of UDP
  • peer-to-peer-systemen
  • toegang krijgen tot iets dat gehost wordt achter de NAT
  • dingen zoals SIP en FTP. ALG's om dit te omzeilen veroorzaken nog steeds willekeurige en rare problemen vandaag, vooral met SIP.

In de kern is de gelaagde benadering die de netwerkstack neemt relatief eenvoudig en elegant. Probeer het uit te leggen aan iemand die net is begonnen met netwerken en ze gaan onvermijdelijk ervan uit dat hun thuisnetwerk waarschijnlijk een goed, eenvoudig netwerk is om te proberen te begrijpen. Ik heb dit in een paar gevallen gezien als een paar interessante (te ingewikkelde) ideeën over hoe routering werkt vanwege verwarring tussen externe en interne adressen.

Ik vermoed dat VoIP zonder alomtegenwoordigheid alomtegenwoordig en geïntegreerd zou zijn met het PSTN, en dat bellen vanaf een mobiele telefoon of computer gratis zou zijn (behalve het internet waarvoor je al hebt betaald). Immers, waarom zou ik betalen voor de telefoon wanneer u en ik een 64K VoIP-stream kunnen openen en het werkt net zo goed als het PSTN? Het lijkt vandaag, het nummer 1 probleem met het inzetten van VoIP gaat via NAT-apparaten.

Ik vermoed dat we ons meestal niet realiseren hoeveel simpeler veel dingen zouden kunnen zijn als we de end-to-end connectiviteit hadden die NAT brak. Mensen e-mailen nog steeds (of Dropbox) zelf bestanden omdat als het kernprobleem van het hebben van een bemiddelaar voor wanneer twee clients zich achter NAT bevinden.


129
2018-01-29 06:18



@supercat IPv6-adressen zijn wereldwijd uniek, maar niet plat (ter ondersteuning van routering, die hiërarchisch moet zijn). Het lijkt mij dat als we willen dat twee internet-verbonden hosts theoretisch kunnen communiceren, globaal unieke adressen in een of andere vorm nodig zijn. - Jakob
@supercat Het is helaas een hardnekkige mythe dat IPv6 nog steeds niet genoeg ruimte heeft voor iedereen. Je zou een / 48 kunnen geven aan iedereen op aarde en nog steeds enorme hoeveelheden ruimte over hebben. Om de momenteel toegewezen uit te putten 2000::/3 je zou die oefening meer dan 4.000 keer moeten herhalen! of geef iedereen een / 34. Maar a / 48 is goed genoeg voor vrijwel iedereen, en degenen die meer nodig hebben, kunnen het gemakkelijk krijgen. Zelfs als dat niet genoeg was, is er nog steeds 4000::/3, 6000::/3, etc., beschikbaar. We hebben veel kamer; het is tijd om het te gebruiken. Zie ook RFC 6177. - Michael Hampton♦
@immibis U lijkt iets gemist te hebben. Organisaties zijn niet beperkt tot het krijgen van ofwel een / 48 of een / 32. Ze kunnen vrijwel elk maatblok krijgen. Het kan een / 44 of een / 40 of / 39 of / 47 of zoiets zijn. Je zou ook RFC 6177 moeten lezen. - Michael Hampton♦
Helaas zijn veel mensen begonnen NAT te gebruiken als een waardeloze vorm van beveiliging en veel apparaten zoals chromecasts en IoT-apparaten gaan ervan uit dat elk apparaat dat verbinding kan maken een vertrouwd apparaat is, zodat elke consumentenrouter die ik heb gezien de inkomende verbindingen met ipv6-apparaten zal laten vallen zo goed en sommige die ik heb gezien hebben geen manier om dit uit te schakelen, alleen de reguliere port forwarding. - Qwertie
... Ok ik haat NAT nu; hoe schakel ik over naar IPv6? - Adam Barnes


Een groot symptoom van IPv4-uitputting dat ik in andere antwoorden niet heb genoemd, is dat sommige mobiele serviceproviders begon met het gebruik van IPv6 - slechts enkele jaren geleden. Er is een kans dat u IPv6 al jaren gebruikt en het zelfs niet wist. Mobiele providers zijn nieuwer voor het internetgame en hebben niet noodzakelijkerwijs enorme bestaande IPv4-toewijzingen om uit te putten. Ze vereisen ook meer adressen dan kabel / DSL / glasvezel, omdat uw telefoon geen openbaar IP-adres kan delen met andere leden van uw huishouden.

Mijn gok is dat IaaS en PaaS-aanbieders de volgende zullen zijn, vanwege hun groei die niet is gekoppeld aan fysieke adressen van klanten. Het zou me niet verbazen als IaaS-aanbieders die alleen IPv6 aanbieden binnenkort korting krijgen.


20
2018-01-29 16:58



Ik heb al een paar kleine providers gezien die IPv6-only VM's aanbieden en een premie in rekening brengen voor IPv4. - Michael Hampton♦


De grote RIR's hadden een tijdje geleden onvoldoende ruimte voor normale toewijzingen. Voor de meeste providers zijn de enige bronnen van IPv4-adressen dus hun eigen voorraden en de markten.

Er zijn scenario's waarbij het de voorkeur verdient om een ​​speciale openbare IPv4 IP te hebben, maar het is niet absoluut noodzakelijk. Er zijn ook een heleboel openbare IPv4-adressen die zijn toegewezen maar momenteel niet in gebruik zijn op het openbare internet (ze kunnen in gebruik zijn op privé-netwerken of ze kunnen helemaal niet worden gebruikt). Ten slotte zijn er oudere netwerken met adressen die veel losser worden toegewezen dan nodig is.

De drie grootste RIR's staan ​​nu toe dat adressen zowel tussen hun leden als aan elkaars leden worden verkocht. We hebben dus een markt tussen organisaties die ofwel adressen hebben die ze niet gebruiken of die adressen hebben die kunnen worden vrijgemaakt voor een vergoeding aan de ene kant en organisaties die echt meer IP-adressen nodig hebben aan de andere.

Wat moeilijk te voorspellen is, is hoeveel aanbod en vraag er op elk prijsniveau zal zijn en dus wat de marktprijs in de toekomst zal doen. Tot nu toe lijkt de prijs per IP verrassend laag te zijn gebleven.


14
2018-01-28 19:30



AfriNIC heeft minder dan a / 8 aan adressen die nog beschikbaar zijn, en ik heb veel voorbeelden gezien van organisaties buiten Afrika die deze pakken. - Michael Hampton♦


Idealiter zou elke host op het internet in staat moeten zijn om een ​​IP-adres voor de gehele wereld te verkrijgen, maar IPv4-adresuitputting is echt, eigenlijk ARIN heeft al een tekort aan adres in zijn gratis zwembad.

De reden waarom iedereen nog steeds prima toegang heeft tot internetdiensten, is dankzij Network Address Translation (NAT) -technieken waarmee meerdere hosts openbare IP-adressen kunnen delen. Dit gaat echter niet zonder problemen.


7
2018-01-28 14:32



Ik wil niet weten hoeveel manuren, bronnen en miljoenen er zijn verspild tussen Napster, Gnutella, Gossip, Kazaa, BitTorrent, Kademlia, FastTrack, eDonkey, Freenet, Grokster, Skype, Threema, Spotify enzovoort , het ontwikkelen van NAT-piercing-technieken. - Jörg W Mittag
@ JörgWMittag Om nog maar te zwijgen over hoe spectaculair het in december 2010 voor Skype is mislukt. - kasperd
En het feit dat je in de eerste plaats NAT-piercing-technieken moet gebruiken. Als machine X en machine Y beide op gewone verbindingen staan, kunnen ze niet met elkaar praten zonder een bemiddelaar. Vervelend voor dingen zoals bestandssynchronisatietaken. - Loren Pechtel
@kasperd Zou u dit kunnen uitwerken "niet gelukt voor Skype in december 2010"? Ik zou dat kunnen vinden een groot aantal supernodes mislukte in een keer, om een ​​niet nader genoemde reden. En niet om te zien hoe dat relevant is voor IPv4-adresuitputting. - ivan_pozdeev
@ivan_pozdeev Supernodes is een oplossing voor problemen veroorzaakt door NAT. NAT zelf is een oplossing voor het tekort aan IPv4-adressen. Dus de noodzaak voor Skype om in de eerste plaats supernodes te gebruiken, werd volledig veroorzaakt door een tekort aan IPv4-adressen. Was het internet in een redelijker tempo opgewaardeerd naar IPv6, dan zou Skype geen superknooppunten nodig hebben en zou die uitval niet zijn gebeurd. - kasperd


ISP's worden gebruikt om blokken van 256 IP-adressen aan bedrijven te geven. Nu zijn ISP's gierig en geven ze u (een bedrijf) als 5. Op de dag (2003) had elke pc en elk aangesloten apparaat in uw huis een eigen internet-IP-adres. Nu heeft de kabel / DSN / Fios-router één IP-adres en geeft hij 10.0.0.x ip-adressen uit aan alle pc's in uw huis. Samenvatting: ISP's gebruikte om IP-adressen te verspillen en nu verspillen ze ze niet meer.


5
2018-01-29 23:38



"Vroeger (2003) had elke pc en elk aangesloten apparaat in huis een eigen internet-IP-adres."Alleen als je hebt betaald voor de 2e, 3e, 4e, etc. - RonJohn
RonJohn heeft gelijk. Ik was een van de early adopters van breedband toen kabel-internet in 1997 naar mijn gebied kwam. Ik heb er $ 50 per maand voor betaald, en ik weet duidelijk dat ze een tweede IP-adres hebben aangeboden voor een extra $ 20 per maand. Hoewel ik er een wilde, was ik niet bereid om ervoor te betalen. Het volgende jaar werd mijn probleem opgelost toen ik NAT-apparaten ontdekte. Ze hadden niet veel functies (zoals port-forwarding voor inkomende verbindingen) maar degene die ik kreeg loste mijn onmiddellijke behoefte op. - Charles Burge
@CharlesBurge Ik herinner me dat ook. En we zien dat sommige providers hetzelfde proberen te doen met IPv6 nu ook. - Kevin Keane
@CharlesBurge: dit was afhankelijk van uw internetprovider. Ik had rond dezelfde tijd een vriend op kabel in Phoenix, AZ, en hij kreeg een volledig gerouteerd subnet, een / 29 blok, met 8 adressen, 5 bruikbaar. We hebben er een Linux-server op uitgevoerd met een poort (per ongeluk van onze kant), en het kabelnetwerk heeft er zelfs volledige BGP-routeringsinformatie mee gedeeld. Dat en mensen die hun Windows-pc's en -printers met volledig open aandelen op het netwerk plaatsten, maakten het leven interessant. - Zan Lynx
Oh ja, ik herinner me de zichtbaarheid van het netwerk. Alle anderen in mijn lus waren zichtbaar in 'Netwerkomgeving' en ik kon bladeren door alle shares die ze hadden. - Charles Burge


U hebt al veel uitstekende antwoorden, maar ik zou iets willen toevoegen dat nog niet is genoemd.

Ja, IPv4-adresuitputting is slecht, afhankelijk van hoe je het meet. Sommige bedrijven hebben nog steeds een groot aantal IPv4-adressen, maar we beginnen work-arounds te zien zoals carrier-grade NAT.

Maar veel van de antwoorden kloppen niet wanneer ze in IPv6 afwijken.

Hier is een lijst met technologieën die kunnen helpen omgaan met het IPv4-adrestekort. Elk heeft zijn eigen voordelen en nadelen.

  • IPv6

    • Voordeel: gestandaardiseerd en beschikbaar in de meeste besturingssystemen.
    • Nadeel: ondanks frequente verklaringen van het tegendeel, ernstige beveiligingsproblemen. Al in 2005, US CERT gewaarschuwd voor beveiligingsproblemen veroorzaakt door de algemene aanpak van IPv6. IPv6 kan goed beveiligd zijn, maar gezien de staat van de consument routers, kan het niet gebeuren.
    • Nadeel: migreren kost tijd, geld en expertise.
    • Nadeel: veel apparaten van consumentenklasse hebben ernstige gebreken. Een aantal D-Link routers ondersteunt bijvoorbeeld IPv6 door eenvoudig door te sturen allemaal verkeer zonder firewalling aan te bieden.

Een andere overweging: zelfs als IPv6 vandaag volledig zou worden betrapt, zou het nog steeds 20 jaar duren voordat IPv4 wordt afgebouwd vanwege legacy-apparatuur die mensen voor een zeer lange tijd zullen gebruiken (ik zie nog steeds Windows 2003-servers en Windows XP-werkstations) af en toe! Om nog maar te zwijgen van alle printers en camera's en IoT-gadgets die IPv6 niet ondersteunen).

  • CGNat:
    • Voordeel: werkt zonder wijzigingen op locatie van de klant.
    • Nadeel: ondersteunt alleen uitgaande verbindingen.
    • Nadeel: ondersteunt mogelijk niet een paar protocollen.

Uiteindelijk zal CGNat niet genoeg zijn. Misschien zal IPv6 aanslaan, maar het is ook heel goed mogelijk dat we uiteindelijk NAT van het betreffende land zullen zien, of iets in die richting.

Momenteel moet ik als consultant vaak aan mijn klanten wijzen dat ze worden blootgesteld op IPv6 (vaak dankzij Teredo). De volgende vraag zal altijd zijn: "hoeveel kost het om dat op te lossen?" en vervolgens: "Hoeveel kost het om het te blokkeren? Wat verliezen we als we het uitzetten?" Raad eens wat de beslissing elke keer zal zijn.

Kort gezegd: om uw vraag te beantwoorden, ja, IPv4-uitputting is echt. En we zullen heel wat mechanismen zien om ermee om te gaan. IPv6 kan wel of niet de vergelijking worden.

Voor de duidelijkheid: ik zeg niet dat ik net zoals deze situatie. Ik zou graag willen dat IPv6 slaagt (en ik zou graag een aantal verbeteringen zien in IPv6). Ik kijk gewoon naar de situatie zoals die nu op de grond is.


5
2018-02-01 01:54



CGN werkt, net als NAT, alleen met TCP, UDP en ICMP en niet met andere transportprotocollen. Het breekt ook veel applicatielaagprotocollen. NAT is een lelijke oplossing om IPv4 uit te breiden, en het heeft het nut ervan echt overleefd. - Ron Maupin
@supercat, IP-pakketten hebben geen DNS-namen. Dat zou een ander protocol zijn. Alleen TCP-, UDP- en ICMP-transportprotocollen werken met NAPT, andere niet. Veel applicaties en application-layer protocollen werken niet met NAPT, en ze vereisen lelijke hacks bovenop de lelijke NAPT-hack. Het uitgangspunt van IP is dat elk eindapparaat een uniek adres heeft en daarom zijn veel protocollen ontworpen. IPv6 lost dat probleem op, evenals enkele tekortkomingen van IPv4. - Ron Maupin
@supercat, als het echt zo simpel is, zou er geen reden zijn geweest voor de enorme hoeveelheid geïnstalleerde IPX-netwerken om naar IPv4 te converteren. Je zou hetzelfde type ding kunnen doen tussen IPX en IPv4, en het werd een tijdje gedaan, maar het is slechts een kleinigheid. - Ron Maupin
@supercat - dus om een ​​dergelijk netwerk te ondersteunen, moeten we bestaande standaarden opgeven en alle bestaande toepassingen die rechtstreeks verbinding maken met adressen herschrijven? Dat klinkt niet als een goede benadering voor mij. - Jules
@KevinKeane Het verbaast me niet dat een oude consumentenrouter uit 2010 IPv6-problemen heeft. Een zoekopdracht van 30 seconden op Google-zoekresultaten geeft aan dat ze jaren geleden dit probleem hebben opgelost. - Michael Hampton♦


NAT is wat er gebeurde toen IPv6 een idee was, nog voordat het realiteit was, en IP-adrestoewijzing een echt probleem aan het worden was (herinnert iedereen zich dat ze Class C's in feite aan het uitdelen waren?) En had de echte wereld in de tussentijd een oplossing nodig .

NAT is niet voldoende voor IoT. Als IoT gaat gebeuren, gebeurt dit met IPv6. De aard van IoT is meer in overeenstemming met hoe de dialup-wereld werkte, behalve dat er meerdere ordes van grootte meer apparaten op hetzelfde moment verbonden zullen zijn.


-1
2018-01-30 08:21



Uit een snelle zoekactie lijkt NAT oorspronkelijk te zijn gedefinieerd door RFC 1631 in mei 1994. IPv6 is gedefinieerd in RFC 1883, gepubliceerd in december 1995 als een voorgestelde norm (wat vrij ver langs het standaardspoor ligt). Ik weet niet waar je de grens trekt tussen 'een idee' en 'de realiteit', maar meestal werken IPv6-code bestond vrijwel zeker in testbanken lang voordat RFC 1883 werd gepubliceerd. Vergelijk dit eens met de RFC 1918, die in februari 1996 werd gepubliceerd, een paar maanden na de initiële IPv6 RFC. - α CVn
Normen zijn nutteloos zonder implementatie en een implementatie waar consumenten of bedrijven voor willen betalen. Testbedden en proof-of-concept tellen niet mee in de markt. Mijn punt over NAT is dat werkende implementaties de markt bereikten (en daardoor meer grip kregen) omdat de bestaande hardware (en er was toen al een) allemaal IPv4 sprak. Het was dus meer een kwestie van "probleem opgelost, nu werken aan urgentere problemen". - Xavier
@Xavier: 64K is een bovenlimiet die een NAT-apparaat niet eens kan bereiken. Ten eerste zijn alle lage poorten onder 1024 beperkt. En de meeste NAT beperkt zich tot een hoog poortbereik van ongeveer 20.000 poorten. En natuurlijk is er de geheugenkwestie: zelfs vandaag hebben we routers omgevallen en opnieuw ingesteld omdat iemand probeerde tegelijkertijd 10.000 TCP-verbindingen te openen. Kijk naar jou, Google Home. - Zan Lynx
@KevinKeane - omdat een deel van de trekking met IOT in staat is om extern verbinding te maken met uw apparaten. Momenteel is het configureren van NAT lastig wat fabrikanten van apparaten consumenten niet willen aandoen, maar dit doen we vaak via externe "hook-up" -services van apparaatfabrikanten. maar dit is niet duurzaam op lange termijn. Het enige wat nodig is, is dat een high-profile fabrikant failliet gaat en plotseling zal iedereen op zijn hoede zijn om erop te vertrouwen dat hun apparaten blijven werken. De enige manier waarop dit op lange termijn zal blijven werken, is als de meeste mensen IPv6 hebben. - Jules
@supercat - misschien, maar tot nu toe lijkt dit nog minder waarschijnlijk te zijn dan universele beschikbaarheid van IPv6 ... - Jules


Het hele IPv4-adres probleem is nogal ingewikkeld. Misschien vindt u bepaalde artikel-rapportage is het uitgeput, nog een andere praten over een groot aantal overschot (nooit gebruikt) adressen worden verkocht van de ene partij naar de andere. De vraag is waarom zijn deze niet beschikbaar voor degenen (opkomende regio's en plattelandsgebieden van ontwikkelde landen) er niet bij?

Hieronder is het resultaat van een onderzoek waar we per ongeluk naar toe zijn gegaan. Het gebruikt niets meer dan het originele IPv4-protocol RFC791 en het lang gereserveerde maar nauwelijks gebruikte 240/4 adresblok om de IPv4-pool met 256 miljoen keer uit te breiden. We hebben een conceptvoorstel met de naam EzIP (fonetisch voor Easy IPv4) ingediend bij IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Kortom, de EzIP-aanpak lost niet alleen problemen met het IPv4-adrestekort op, maar verlicht ook grotendeels de oorzaak van cyberveiligheidskwetsbaarheden, plus opent nieuwe mogelijkheden voor internet, allemaal binnen de grenzen van het IPv4-domein. In feite kan dit schema "heimelijk" worden ingezet voor geïsoleerde regio's waar nodig. Deze zouden de urgentie moeten wegnemen om de IPv6 gedurende een aanzienlijke tijdsperiode in te zetten en de markt van het verhandelen van de IPv4-adressen ongeldig te maken.

Elke gedachte of opmerking wordt zeer op prijs gesteld.

Abe (2018-07-15 17:29)


-4
2017-07-15 21:31



ServerFault is geen IETF WG. - womble♦


Eerlijk gezegd vind ik het niet zo erg als mensen denken. Ja, misschien op sommige plaatsen, maar niet zozeer omdat er niet genoeg adressen zijn. Het is omdat ze allemaal in eigendom zijn. Misschien is het mijn locatie of zoiets, maar ik heb de afgelopen zeven jaar wel eens IT-werk gedaan voor een aantal kleine en middelgrote bedrijven, en alle dingen waar je het over hebt zijn meestal slechts standaardopstellingen. Vrij eenvoudig, tenzij je een waardeloos apparaat hebt, of er is een shitty-opstelling met het netwerk die in de eerste plaats moet worden opgelost.

Persoonlijk gaat het goed met NAT. Het is in het algemeen een extra beschermingslaag. Tenminste ze moeten een extra apparaat doorkomen, of een manier vinden om mijn verbinding indirect te kapen. Wat betreft het draaien van servers, dat is meestal buiten en / of wordt beschouwd als een contractbreuk met uw ISP, tenzij u ervoor betaalt. Natuurlijk kun je het doen, en ze zullen je waarschijnlijk niet irriteren, maar ze zouden het wel kunnen.

Port-forwarding en dat alles is niet bepaald ingewikkeld. Sommige apparaten zijn misschien niet eenvoudig te configureren, maar dat is niet vanwege IPv4. Het biedt nog steeds de meeste compatibiliteit eenvoudig omdat het alomtegenwoordig is.

Niemand hoeft zichzelf te e-mailen en het verzenden van iets naar Drop-box of Google Drive, of een miljoen andere vergelijkbare services is tegenwoordig niet bepaald raketwetenschap en ook niet traag. Ik bedoel, alles synchroniseert. Je laat het in een map vallen. Tenzij je nerdy bent zoals ik, en je alles doet via ssh / sftp (oke niet alles). En als je een reden hebt, wil je echt je eigen server draaien, is cloudhosting goedkoop - ik heb een dedicated virtuele server die linux draait op een ssd. De bandbreedte is snel gek. Het start sneller dan dat ik een pijl naar boven kan typen en druk op Enter. En is schaalbaar. De hele set-up kost tussen de 5 en 10 dollar per maand, met gratis back-ups en geen elektriciteitsrekening.

Heb niet echt een peer-netwerkoplossing nodig. Zelfs de meeste multigebruikersspellen zijn tegenwoordig allemaal ingesteld om te communiceren via een tussenliggende server, alle setup en vooraf geconfigureerd. Aan de andere kant, als wat ik lees in deze post allemaal waar is, zal IT overvol en goedkoop zijn als / wanneer IPv6 opstijgt. Zelfs mobiele telefoons naderen vezelachtige snelheden. Of op zijn minst een kabel.

Als u een interne server uitvoert en deze met dezelfde domeinnaam binnen of buiten uw netwerk moet raken, kunt u altijd het adres vervalsen met behulp van een op linux gebaseerde router en dnsmasq of wat dan ook en aangepaste vermeldingen in de hosts bestand om u door te sturen naar het lokale adres als u zich binnenin bevindt.

Echt, ik denk niet dat het eigenlijk wenselijk is om elk apparaat zijn eigen adres te laten hebben, terwijl het open op het net zweeft. Als iemand zichzelf wil verdoezelen terwijl hij je aanvalt, zal het ongeacht gebeuren. Maar je bent een zittende eend als je daar maar ballen buiten in de open wind zit. Nee, ik neem elke dag mijn IPv4 en mijn NAT mee. Maar het is goed dat het er is.

Anywa, nu in slaap vallen ... waarschijnlijk meer te zeggen, maar ik zal morgen inchecken als ik iets mis heb. Ik weet zeker dat er meer is.


-6
2018-01-29 12:34



Uhm, het is eigenlijk wenselijk vanwege stabielere verbindingen, snellere snelheden, goedkoper internet (ISP's hoeven hun NAT-servers niet te onderhouden, IP-blokkeringen per regio / stad en het rondschudden van dingen om op specifieke piekuren rond te komen). Weet je hoe verwarrend het is voor websockets wanneer een gebruiker op mobiel van de ene cel naar de andere springt en een nieuwe IP krijgt? Er is veel compensatiecode, moeite en energie vereist om het draaiende te houden. Je antwoord luidt als volgt: deze toren mist misschien de fundering, maar is nog niet ten val gekomen, dus het is prima. - Tschallacka
Je hebt een aantal misvattingen over NAT en beveiliging. Gelieve te lezen RFC 4864. - Karl Bielefeldt
In dit tempo is het meer dan een generatie. IPv6 is 20 jaar oud dit jaar. - Michael Hampton♦
RFC 2460 werd gepubliceerd in december 1998. Verschillende delen ervan waren al eerder gepubliceerd en er waren verschillende testbeds opgestart. IPv6 werd in ongeveer zijn huidige vorm voorgesteld in RFC 1883 die dateert van december 1995. Je zou dus kunnen zeggen dat IPv6 zelfs ouder is dan 20 jaar. Maar iedereen beschouwt RFC 2460 als het punt waarop IPv6 volwassen genoeg was om te implementeren. - Michael Hampton♦
Trouwens, terwijl ik het over heb, moet je je ervan bewust zijn dat er al IPv6-gamingplatforms zijn, zoals Xbox One. Een Xbox One met IPv4 en geen IPv6-connectiviteit zet een eigen Teredo-tunnel op om het IPv6-internet te bereiken, wat natuurlijk een straf met latentie en betrouwbaarheid met zich meebrengt. IPv4 is in vrij trieste vorm wanneer een Teredo-tunnel als minder onbetrouwbaar wordt beschouwd dan een typische consumenten-IPv4-verbinding. - Michael Hampton♦