Please note that Nerdica.Net will protest against planned upload filters in the new EU copyright directive and will turn black on Mar. 21st the whole
Find more information.
Items tagged with: IPv6
– a technique that uses the properties of the Universal Plug and Play (UPnP) protocol to get specific IPv4 hosts to divulge their IPv6 address
– keep UPnP disabled (there are other security reasons for doing so)
#upnp #ipv4 #ipv6 #enumeration #infosec #cybersecurity #security
Il existe des tas de #RFC qui concernent #IPv6
et le programmeur qui met en œuvre ce protocole dans une machine risque fort d'en rater certains, ou bien d'implémenter certains qu'il aurait pu éviter. Ce RFC est donc un méta-RFC, chargé de dresser la liste de ce qui est indispensable dans une machine IPv6. Pas de changements spectaculaires, par rapport au précédent RFC mais beaucoup de détails.
February 1, 2019: is the #DNS going to shake? Get ready for #DNSFlagDay https://www.afnic.fr/en/resources/blog/february-1-2019-is-the-dns-going-to-shake.html #Internet #IPv6 #IPv4 #Afnic
In the beginning I was using an IPv6 tunnel provided by SiXXs, but for some years now I have a native IPv6 /48 subnet.
Some years ago Deutsche Telekom activated #IPv6 for their DSL customers. This boosted IPv6 traffic in Germany. But there is room for improvement as shown in this network graph to my webserver:
Last year Georgia Tech’s Internet Governance Project teamed up with ICANN’s Office of the Chief Technology Officer to research the economic factors affecting the decisions of network operators to…
Article word count: 1177
HN Discussion: https://news.ycombinator.com/item?id=18831909
Posted by danyork (karma: 2011)
Post stats: Points: 73 - Comments: 94 - 2019-01-05T14:53:39Z
\#HackerNews #for #hope #ipv6 #there
Last year Georgia Tech’s Internet Governance Project teamed up with ICANN’s Office of the Chief Technology Officer to research the economic factors affecting the decisions of network operators to deploy Internet Protocol version 6 (IPv6). The study was commissioned because we both believe that the Internet community needs a better understanding of the economic incentives affecting the attempt to “upgrade” the IPv4 Internet to IPv6, a new Internet protocol with a huge address space. IPv6 doesn’t work with the old Internet. This report examined quantitative data about current levels and patterns of IPv6 adoption, and tried to explain that data based on an analysis of the economic incentives affecting network operators. We titled the report “The Hidden Standards War: Economic Factors Affecting IPv6 Deployment.”
The ongoing competition between IPv4 and IPv6 has big implications for the future of the internet. Is this mixed-standard Internet a passing phenomenon, or will we get stuck in it? If it is only a transitional phase of a standards war and one will prevail, which one will it be? If IPv6 prevails, how long will it take us to get there? Is it possible that IPv6 actually loses the standards competition, and becomes the proverbial ‘orphan’ of the standards economics literature? Our report tries to answer those questions. We are still vetting the draft report but can release some initial findings.
Some initial findings
There is good news and bad news for IPv6 in our findings. For starters, we don’t think IPv6 will lose the standards war and go into oblivion. IPv6 deployment can make economic sense for network operators that need to grow, particularly mobile networks where the software and hardware ecosystem is mostly converted. While it appears as if IPv6 capability is sometimes turned off in response to incompatibilities, the capability remains and as far as we know is never eliminated; therefore, the “stock” of networks with IPv6 capability can only continue to grow. But based on our findings we’re not sure yet whether we will ever exit the mixed world. It is possible we will remain in it for some time, perhaps forever (for some definition of ‘forever’ appropriate for global technical standards). The general picture of IPv6 deployment today is best summed up in the following chart:
[IMG]Figure 2: Frequency of economy-level IPv6 capability growth trends
The largest group, 169 countries, or 79% of the total, had no appreciable IPv6 deployment, remaining at or below 5% during the entire study period. The next largest group (26 countries, or 12%) were economies with increasing levels of IPv6 capability. The next group (18 countries, or 8%) exhibited a plateau in growth, with IPv6 capability growth stopping at levels anywhere between 8% (Austria) and 59% (Belgium). Even in countries where major network operators have converted, there are plateaus in the level of deployment for a period of two or more years rather than a steady, increasing march towards additional deployments. The full report explains in more detail why these plateaus happen.
[IMG]Figure 5: AS-level IPv6 capability growth trends for the top network operators in Belgium (Source: APNIC)
How to explain this pattern?
It’s all about the costs and benefits. The study investigated the economic incentives to convert. One important economic consideration which has not been appreciated by previous research is that network effects play almost no role in the decisions of network operators to deploy. No one uses IPv6 only. All public network operators, and nearly all private ones, must offer full compatibility with all other network operators and as many end points and applications as possible. Given that fundamental constraint, there are only three basic choices for network operators:
1. Remain on IPv4 (do nothing)
2. Run both IPv4 and IPv6 (implement dual stack)
3. Run native IPv6 among compatible parts of their own network with some kind of tunneling or translation (i.e., converter technologies in economics) at the boundaries to make it compatible with IPv4
Among these viable alternatives, we show that dual stack will never get us across the finish line; it is not economical. It is the third category that shows promise for some growing networks. We also show that there is no difference in the network benefits obtained in all of the three options; all three approaches gain access to essentially the same Internet. Consequently, one network operator’s migration to IPv6 places no pressure on the incentives of other network operators to deploy IPv6. There is also no discernible difference in the Internet service offered via IPv6 and IPv4. Furthermore, the costs of maintaining compatibility between the two standards are borne exclusively by networks that deploy IPv6. Deployers must make one-off investments in infrastructure and training, and incur ongoing compatibility costs, whereas non-deployers only have to pay for additional IPv4 numbers. (And if non-deployers don’t need to grow they don’t incur any new costs).
Because of the additional costs associated with IPv6 deployment, there is a strong positive correlation between a country’s wealth (measured in per capita GDP) and country-level IPv6 deployment levels. Per capita GDP differences explain nearly half (.499) of the variation in IPv6 deployment levels across countries, and the correlation is statistically strong (<.01). The study also found that a lower level of market concentration (as measured by HHI) is correlated with higher country-level IPv6 capability rates. This was true of both wireless (-.267, p = <.01) and fixed broadband (-.347, p = <.01) service markets, though the correlation is stronger in fixed broadband. It is well known that competitive markets accelerate investment in newer, more efficient technologies. The problem in this case, however, is that we found no correlation between IPv6 deployment by a network operator and changes in its market share, so the negative correlation between market concentration and IPv6 deployment is not a product of competitive advantage. It probably exists for two reasons: 1) the presence of more players in a market increases the likelihood that one of them will make an arbitrary deployment decision; 2) a more open market permits the entry of new firms (such as India’s Jio) with newer infrastructures, which have a more favorable cost structure for IPv6.
The good news for IPv6 is that it can make economic sense for some operators who need to grow. The bad news is that many networks don’t need to grow much. And even if they need to grow, they may still be lodged in a slower-moving software and hardware ecosystem tied to IPv4, which will make it less expensive to expand by just obtaining more IPv4 addresses or using NAT. Additional bad news is that the need to maintain backwards compatibility with non-deployers eliminates any network effects that would create growing pressure to convert to IPv6. Not until the very end game, when the number of IPv4-only networks is so small that the older protocol is in danger of being shut off entirely, is there any external pressure on lagging network operators to convert. We will do additional modeling to gain a better understanding of end-game timing and scenarios.
The final report will come out near the end of this month.
HackerNewsBot debug: Calculated post rank: 80 - Loop: 120 - Rank min: 80 - Author rank: 27
Sunday, December 30, 2018 Some of my posts are sourced from observing the kinds of mistakes that people are likely to make. Occasionally, they clump together and present a pattern or two, and then I…
Article word count: 1402
HN Discussion: https://news.ycombinator.com/item?id=18793311
Posted by deafcalculus (karma: 3953)
Post stats: Points: 87 - Comments: 60 - 2018-12-31T06:04:09Z
\#HackerNews #avoid #ipv6 #migrating #potholes #when
Sunday, December 30, 2018
Some of my posts are sourced from observing the kinds of mistakes that people are likely to make. Occasionally, they clump together and present a pattern or two, and then I try to share the finding to help others avoid falling in the same trap.
Watching a bunch of services migrate to dual-stack IPv4 + IPv6 behavior showed me a lot of places where it can go wrong. A lot of it is subtle fiddly stuff which nobody really thought about before in the 4-only world, but that suddenly became important.
For example, how many people have built a service where they pass around connection details as a hostname, a colon, and then a port number? It might be something like this.
leader_host = bigdata.example.org:10443
Parsing that is easy enough, right? In the IPv4 world, you split on the colon. That gives you a host portion which goes to your DNS resolver call, like gethostbyname(). It also gives you a port portion which needs to go through the local equivalent of "atoi", and then gets crammed into a sockaddr struct and handed to connect().
Pretty old hat, these BSD sockets, yeah? Well... what happens when you get handed this?
leader_host = 192.168.200.2:10443
It turns out that this also splits cleanly, and the "dotted quad" notation for that IPv4 address passes straight through gethostbyname().
Odds are good that someone is creating this string by emitting (hostname) + ":" + (port) somewhere. What happens when you start using IPv6 addresses in the system, and then that code runs and generates an address string for another host? You get something like... this:
leader_host = 2001:0db8:f00f::0553:1211:0088:10443
Is your parser still going to work? If itʼs finding the first colon in the string, Iʼm guessing the answer is no. Itʼll end up with "2001" in the host section, and the whole rest of it trying to be parsed as an int. Thatʼs not going to work.
Okay, so, someone will probably change the code to use the LAST instance of the colon in the string. That gives you the split you needed. You get "2001:0db8:f00f:0000:0000:0553:1211:0088" as the host, "10443" as the port, and you can proceed to the resolver step. Obviously, you have to use getaddrinfo() now, but you knew that already.
This version of the code will hold up for a while, but then one day, youʼll start seeing errors like this:
Connect: unable to connect to leader: 2001:0db8:f00f::0553:1211 port 88: connection refused
This one will take a lot of head-scratching to figure out. Hopefully when you see this one, you remember this post and it saves you some time. What happened? Assumptions.
It turned out that the program only did the "split on colon" thing if the string actually HAD a colon in it. There was a standard port the service should run on, which is 10443 for our little story today. You didnʼt have to pass in the port. You could just give it an IP address or hostname and it would use the default.
So what happened is that someone used a generator to put out something like this:
leader_host = 2001:0db8:f00f::0553:1211:0088
Why? Well, they figured the extra ":port" was stupid, since they were always writing out ":10443", and itʼs the default, so why bother?
When the consuming program got a hold of it, the "hey, a colon!" code fired off, and stripped off the ":0088" as the port. It so happens that "0088" will wash through a lot of atoi type functions as decimal 88, and so it tried to use that port. Thatʼs the wrong port.
But, did you notice the actual IP address is bogus, too? Yep, thanks to the embedded "::" which fills in the center of the address with zeroes, the now-missing ":0088" means the "0553" and "1211" parts of that address get shifted down.
Iʼll use a monospaced font and fill in all of the zeroes to show what happened:
Intended: 2001:0db8:f00f:0000:0000:0553:1211:0088 with default port Result: 2001:0db8:f00f:0000:0000:0000:0553:1211 with port 0088
The next thing that probably happens is that someone decrees that everyone will now specify IPv6 addresses in strings just like you do in URLs, using brackets. Parsers will be adjusted to only look for a possible ":port" AFTER those brackets.
The config now looks like this...
leader_host = [2001:0db8:f00f::0553:1211:0088]
... or this, specifying a port number:
leader_host = [2001:0db8:f00f::0553:1211:0088]:10443
Everyone changes their generators and parsers and life goes on for a while.
Then, one day, someone notices that there are too many connections being established based on the list of hosts. This makes no sense because the list is supposed to have a deduplication pass applied to it. Identical entries should just disappear, leaving just unique entries.
It turns out this is actually true. Identical entries are going away. That is, identical strings are going away. But... it turns out you have many ways to express those IP addresses.
Someone decided to be explicit about everything, and decided to spell out the zeroes. Maybe they didnʼt like what the "::" did to them before during the whole port number fiasco that we just talked about. They started generating this:
leader_host = [2001:0db8:f00f:0000:0000:0553:1211:0088]
That gave them a host string of "2001:0db8:f00f:0000:0000:0553:1211:0088". The existing entry is "2001:0db8:f00f::0553:1211:0088". Those strings arenʼt identical. They arenʼt even the same length! So, that must represent two different hosts and we should probably connect to both of them.
An intern is given this problem, and decides to fix it by simply turning all instances of "::" into the requisite number of "0000:0000" blocks. They call it "zero injection". (Meanwhile, another intern at another company is doing it the other way, calling it "zero squashing". This doesnʼt matter at all until years later when the two companies merge, but weʼll leave that story for another day.)
"Zero injection" solves this problem, and life goes on.
Then, one day, it starts happening again. Itʼs again about zeroes, but in a different way. Someoneʼs been making config strings like this:
leader_host = [2001:0db8:f00f:0:0:553:1211:88]
Nothing says you have to zero-pad those things out to four hex characters, after all. 88, 088, and 0088 all mean the same thing: 0x88.
This sort of difference can come about from someone using printf, and person A uses %04x (thus zero-padding out to 4 places), while person B uses just %x. A and B look the same as long as you have values at or above 0x1000, but once you drop below it, things get interesting.
Someone else gets roped into fixing this. Since theyʼre already doing "zero injection", they follow that same logic and just re-write ALL of the address parts to make sure they are always a fixed width using leading zeroes.
Things are pretty good. But you know we canʼt be done yet.
Did you notice that these addresses are hex, and thus contain six letters? Iʼm talking about how you represent the values 10 through 15. You use a, b, c, d, e, f. Or... maybe you use A, B, C, D, E and F.
So, yes, this happens, eventually:
leader_host = [2001:0DB8:F00F:0000:0000:0553:1211:0088]
Even though itʼs been both "zero injected" and "zero padded", thereʼs still the little matter that "0db8" and "0DB8" donʼt match when youʼre talking about dumb string comparisons. Oops.
This, too, can come about from someone using different printf format strings. %04x gives one, and %04X gives the other. getaddrinfo() doesnʼt care, but your de-duplication string compares sure do!
All of this is just one way to discover the data parsing and representation bugs lurking in your system. You will also trip over this when it comes time to look for things in log files or in databases if youʼre using strings to hold these addresses. Imagine this SQL query:
SELECT auth_username FROM ssh_log WHERE host_ip = x;
Just how is ʼxʼ going to be formatted, anyway? Does it have runs of zeroes squished out with ::? Do the numbers have leading zeroes? Does it use A-F or a-f? Or does it mix them up in the same thing? Did they wrap it with because someone said you should always store them that way after that one outage a long time ago?
Strings are hard!
By the way, none of this is intended to scare people off IPv6. Youʼll get there eventually. Hopefully these tales just remind you to make the right choices when you do go for it.
HackerNewsBot debug: Calculated post rank: 78 - Loop: 185 - Rank min: 60 - Author rank: 80
We’ve seen internet-enabled holiday displays before, and we know IPv6 offers much more space than the older IPv4 addressing scheme that most of us still use today, but the two have never been…
Article word count: 550
HN Discussion: https://news.ycombinator.com/item?id=18754687
Posted by fanf2 (karma: 12062)
Post stats: Points: 115 - Comments: 26 - 2018-12-24T22:43:04Z
\#HackerNews #addresses #display #internets #ipv6 #uses #worth #xmas
We’ve seen internet-enabled holiday displays before, and we know IPv6 offers much more space than the older IPv4 addressing scheme that most of us still use today, but the two have never been more spectacularly demonstrated than at jinglepings.com. The live video stream shows an Internet-connected Christmas tree and an LED display wall that you can control by sending IPv6 ICMP echo request messages, more commonly known as pings.
Reading the page, you quickly parse the fact that there are three ways to control the tree. First, you can type a message in the box and press send – this message gets displayed on the crawl at the bottom of the LED screen. Second, you can light up the tree by sending a ping to the IPv6 address 2001:4c08:2028:2019::RR:GG:BB, where RR, GG, and BB are 8-bit hex values for red, green, and blue. This is a neat abuse of the IPv6 address space, in that the tree has 2^24 (around 16.8 million) IPv6 addresses, one for each color you can set. We were impressed by this brute-force use of address space, at least until we read on a little further.
You can also make your own drawings on the LED wall, again by sending pings. In this case, the address to set a pixel to a particular color is: 2001:4c08:2028:X:Y:RR:GG:BB, where X and Y are the pixel coordinates. This seems easy enough: to set pixel (10, 11) to magenta, the RGB value (0xFF, 0x00, 0xFF), you’d simply ping the IPv6 address 2001:4c08:2028:10:11:FF:00:FF. Having an array of addressable LEDs is commonplace in hacker circles today, although each of them having their own live IPv6 address on the Internet seems a little excessive at first. Then it hits you – each LED has an IPv6 address for every possible color, just like the tree: 16.8 million addresses for each LED. The LED display is 160×120 pixels in size, so the total number of IPv6 addresses used is 160x120x2^24, which is 75 times larger than all possible IPv4 addresses! This is a hack of monstrous proportions, and we love it.
In case you’re not running IPv6 yet, we’ve got you covered. To send individual pings using your browser, you can use a site like Ipv6now. If you want to send pixels to the display wall, you’re better off using a 6in4 tunnel that lets you access IPv6 sites using your current IPv4 connectivity. Hurricane Electric offers a free 6in4 tunnel service that we’ve found useful. Then it’s just a matter of writing some code to send pixel values as pings. The python scapy module is perfect for this sort of thing. But, first you’ll have to fill out the form on jinglepings.com and wait to get your IPv6 address whitelisted before you can draw on the display; evidently the usual bad actors have found the site and started drawing inappropriate things.
If you think this use of addresses seems wasteful, you needn’t worry. There are around 3.4×10^38 IPv6 addresses, enough for 10^27 such displays. We’re going to go out on a limb here and say it: nobody will ever need more than 2^128 IP addresses.
If you’re looking to build an LED holiday display on a smaller budget, check out this one that re-purposes normal LED strings.
Thanks to [Ward]for the tip!
HackerNewsBot debug: Calculated post rank: 85 - Loop: 74 - Rank min: 80 - Author rank: 60
HN Discussion: https://news.ycombinator.com/item?id=18218513
Posted by AndrewDucker (karma: 25452)
Post stats: Points: 142 - Comments: 81 - 2018-10-15T09:52:59Z
\#HackerNews #barrier #breaks #ipv6 #the
HackerNewsBot debug: Calculated post rank: 121 - Loop: 295 - Rank min: 100 - Author rank: 89
IPv6 im Congstar Mobilnetz.
Ich nutze Android8 und habe festgestellt, dass ich mir im Congstar Mobilnetz eine IPv6-Adresse geben kann.
Hierzu gehe ich in den Einstelungen zu VERBINDUNGEN - MOBILE NETZWERKE - ZUGANGSPUNKTE - und wähle "hinzufügen".
Folgende Felder habe ich eingeragen:
Name: T-Mobile Internet
Benutzername: telekom (oder congstar eintragen)
Kennwort: tm (oder cs eintragen, wenn als Benutzer congstar gewählt wurde)
Alles andere habe ich nicht angegeben/so belassen.
Jetzt noch speichern, und ich kann den neuen ANP auswählen.
Und zack, hat mein Handy eine gültige globale IPv6 Adresse.
Diese sieht man zB unter Einstelungen, Telefoninfo, Status.
#ip6 #ipv6 #congstar #android
Das war gar nicht so einfach, wie ihr hier nachlesen könnt:
(Thread von Anfang an lesen)
und es hat nur 6 Wochen gedauert....
Does anyone have a better idea?
#ipv6 #pfsense #router #firewall #openvpn