nanog mailing list archives
Re: Netflix banning HE tunnels
From: Owen DeLong <owen () delong com>
Date: Sun, 12 Jun 2016 17:05:17 -0700
On Jun 10, 2016, at 01:32 , Valdis.Kletnieks () vt edu wrote: On Fri, 10 Jun 2016 07:19:22 +0100, "tim () pelican org" said:All the business systems that sit around it? Not so much. $DAYJOB has plenty of code, database structures etc that are built around "an IP address is no more than 15 characters long and matches '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you need development time - typically expensive analyst time to work out *what* you need to change, not just code-grinder make-the-field-bigger time. IT departments seem reluctant to provide that resource, unless you've got people at the very top of the business bought into the fact that you *need* to do IPv6.
That was a pretty dumb way to store IPv4 addresses, frankly. First, 593.812.904.601 matches your regular expression, and isn’t an IP address. If you were smart (IMHO), you stored IPv4 addresses as 32-bit integers. First, update the software in question to understand IPv4 mapped addresses for parsing/displaying (IPv4->::ffff:i.p.v.4 for parsing and reverse the process for display) and then modify the database schema. With most databases and other software, converting a 32-bit integer field into a 128 bit integer field isn’t particularly hard. Once you’ve done that, make a quick single pass through the database adding 281,470.681.743.360 to all integers < 4,294,967,296. (That should replace the equivalent of 0:0:0:0:0:0:ip:v4 with the equivalent of 0:0:0:0:0:ffff:ip:v4) There are a number of reasons for converting all IP addresses to integers prior to processing in software. 1. Easier and more consistent sorting. 2. Consistent and easier comparisons for equality or ranges In iPv4, this was useful. In IPv6, it’s essential. e.g. IPv4: 90.90 == 90.0.0.90 IPv4: 33280.33288 == 130.0.130.8 IPv6: All of the following are equal 2001:db8::3 2001:0db8::0003 2001:0db8:0:0:0:0:0:3 2001:db8:0::3 etc. Also: 2620::930:0:0:0:200:2 2620:0:930::200:2 etc. 3. Easier to deal with future changes (such as expanding from 32-bit IPv4 numbers to 128-bit IPv6 numbers) 4. Representation can be left to the user interface where it belongs instead of embedded throughout the application. The network stack only deals with integers, why not keep them as integers everywhere else as well. The other expressions are just for human readability. Treat them like any other Locale based UI issue. Yes, you need to get the people at the top bought into the idea that IPv6 must be deployed, but these days, that really shouldn’t be all that hard to do with competent management and a reasonable networking department. Owen
Current thread:
- Re: Netflix banning HE tunnels, (continued)
- Re: Netflix banning HE tunnels Cryptographrix (Jun 10)
- Re: Netflix banning HE tunnels Cryptographrix (Jun 10)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 12)
- Re: Netflix banning HE tunnels [really: IPv6 adoption] bzs (Jun 10)
- Re: Netflix banning HE tunnels Randy Bush (Jun 09)
- Re: Netflix banning HE tunnels Mark Andrews (Jun 09)
- Re: Netflix banning HE tunnels Mark Foster (Jun 09)
- Re: Netflix banning HE tunnels Mark Andrews (Jun 09)
- Re: Netflix banning HE tunnels tim () pelican org (Jun 09)
- Re: Netflix banning HE tunnels Valdis . Kletnieks (Jun 10)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 12)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 12)
- Re: Netflix banning HE tunnels Mark Andrews (Jun 12)
- Re: Netflix banning HE tunnels Valdis . Kletnieks (Jun 12)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 13)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 13)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 13)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 13)
- Re: Netflix banning HE tunnels Seth Mattinen (Jun 13)
- Re: Netflix banning HE tunnels Michael Brown (Jun 07)
- RE: Netflix banning HE tunnels Chuck Church (Jun 08)