Re: V6 still not supported
>The only far ressemblance with 6to4 is the thing that was actually nice in the > design, the automatic word in automatic tunnel. Which for the rest of us mean >s stateless. Compared to CGNATs that is huge. Any form of communication with the current IPv4 internet requires some sort of CGNAT. We no longer have enough IPv4 addresses to give each customer an unique one. So some ISPs are forced to map multiple customers to a single IPv4 address. Which results in CGNAT. Technically, A+P (address plus port) mapping is a bit different, but for the customer that doesn't make a lot of difference. And A+P has serious scalability problems. >Beyond that the proposal is not a tunnel and more akin to a nat64 since it all >ows v6 nodes to talk to v4 nodes. The network can be pure v4 or pure v6 if the > method is implemented as a bump in the stack at the wrong end. You mostly ignored the routing problems I brought up. With NAT64 each ISP is in full control over all routing. Your problem has routing aspects that are not under control of the ISP. >Your response is also missing the capability to extend the IPv4 network a mill >ion times. Or drop it completely while maintaining IPv4 applications. Extending IPv4 is fine (except for the installed base of IPv6). It is not fine if the extension leads to problem in other areas, like routing. There are other problems to consider. For example, IPv6 can be added transparently to a network with legacy IPv4-only hosts. Hosts can get a public IPv6 address and a RFC 1918 IPv4 address. I wonder how in your approach such a mix of legacy and new hosts will work out. >6to4 was meant for early v6 to interconnect islands. A solution for a problem >that never really existed. Solutions without a problem aren?t usually popular. We seem to have a different recall of history. 6to4 was extremely popular. Popular enough that major content providers did not turn on IPv6 until host stacks were modified to essentially kill 6to4. (in case we are talking about different 6to4 protocols. I meant the one that interconnects with the non-6to4 IPv6 internet. So more than just islands)
Re: A straightforward transition plan (was: Re: V6 still not supported)
> > If there is a magical transition technology that allows an IPv6-only host t > o > > talk to an IPv4-only host, then let's deploy it. > > DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition > protocol and see what happens! (with more coming every year...) The problem with these is that they are not full solutions. That's why we get new ones every year: everybody picks the subset of the problem they want solve. To go over the ones you listed: - 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4 infrastructure. Very useful when there was not a lot of IPv6 native. Not a good approach for organisations that lack IPv4 addresses. Also not a good approach if you want to switch off IPv4 at some point. - DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an IPv6-only backbone. Downstream from the CPE is dual stack. For this reason those protocols do not see much use outside ISP networks. Got a great transition technology because hosts will keep IPv4 until the last IPv4 on the internet is gone. It is a bit of an IETF failure that we have so many ways to connect a CPE to IPv4aaS. - NAT64/DNS64. This is the closest to an actual transition technology. Unfortunately it is completely flawed in too many ways. - 464XLAT fixes many issues with NAT64/DNS64. The downside is again that hosts have to have an IPv4 stack until forever and in addition to that a complex IPv4-to-IPv6 translation module. That fails the requirement that an IPv6 stack should have roughly the same complexity as IPv4 and talk to IPv4-only. Basically, there is no solution to the transition problem. There are lots of partial solutions, each with their own advantages and disadvantages. If we could go back in time, then developing NAT64 along with IPv6 and making sure the translation really works including edge cases like IPv4 literals, DNS A records, NAT traversal, etc. would have made a difference. I don't know if such translation gateways were considered, I can't recall much discussion about them. By the time the IPv6 socket API was created it was already too late to get things like IPv4 literals right.
Re: V6 still not supported
>A host in the Internet that wants to talk to a host in China would require an >update to parse new DNS double-A (realm, address) records to encapsulate the p >acket IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that ser >ves the shaft at level 1 attracts 240.0.0.0/8 within realm 1 and routes up the > elevator for more specific (host) routes within that prefix. The router that >serves the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the s >aid packet it would swap the inner and outer destination and the packet would >reach the Chinese address with classical routing within realm 2. > >Routers serving the shaft need an update, but then, only those do. Obviously t >he host in China can only reply if its stack is updated to understand the form >at. But all the other hosts and routers in China can be classical IPv4 as we k >now them long as their traffic stays in China. To migrate to IPv6 what you can > do is map the elevator shaft prefix in, say, 400::/3 (sadly cannot use F00/3 >that would map 240 neatly but is already assigned). > >The current internet would own 400:1::/32, China would own 400:2::/32, etc... >You encode the double-A of the host in the prefix, reserve a well known suffix > for IPv4 mapped double-A, and you have an IPv6 address that can be mapped bot >h ways statelessly. When migrating to v6, each IPv4 node that owns a public IP >v4 address in one realm gets a full IPv6 /64 for free. >" Somehow this sounds a lot like 6to4: packets get routed to special devices in the network and ISPs have little control over this. Not a popular architecture. Or another way to look at it is the resemblance with the ill fated 'Provider-Based Global Unicast Addresses' (RFC 1884, Section 2.4.7). This was not very popular either.
Re: A straightforward transition plan (was: Re: V6 still not supported)
>If by ?straightforward transition plan? one means a clear and rational set of >options that allows networks to plan their own migration from IPv4-only to IPv >6, while maintaining connectivity to IPv4-only hosts and with a level of effor >t reasonable comparable to just running IPv4, then I would disagree, as such a >n "IPng transition plan? was achievable, expected, and we collectively failed >to deliver on it (as noted below) I'm a bit confused about the achievable part. Obviously, the adoption of IPv6 without a clear transition plan was a process failure. However, it is not clear to me that waiting a few years would have brought something much better. And waiting more than a decade would mean that today there would not be a mature IPv6. Transition to IPv6 so far seems to have consisted of 3 phases: 1) Lots of tunnels due lack of a wide spread IPv6 backbone. 2) Early adopters being happy that they can run IPv6 native, usually as dual stack. 3) Lots of people looking into IPv6-only. I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels worked. Obviously, deploying IPv6 using tunnels is a lot more complex than deploying native IPv4 without NAT. >From a technical perspective 2) just works. From an operational perspective it is about twice as expensive as IPv4-only. So 2) is popular with people who really want IPv6. The big issue is 3). If we look at the current internet, there are parties who lack IPv4 addresses and want to switch to IPv6. Obviously, they want to be IPv6-only. The lack of IPv4 address makes dual stack even harder. On the other hand, there are parties who have enough IPv4 addresses and have no reason to switch to IPv6. So we are clearly in the situation of 'migration from IPv4-only to IPv6, while maintaining connectivity to IPv4-only hosts' It should be clear that an IPv4-only host only speaks IPv4. This means that communication with an IPv4-only host has to be IPv4. So either the IPv6-only host or something in the network has to speak IPv4. If the IPv6 host speaks IPv4 then we get dual stack, which has been rejected as a broken solution. Technically, it is also possible to tunnel IPv4 packets, then the host is in some sense dual stack, but most of the network is not. However, automatic tunnel configuration is hard, and tunnels tend to be fragile. So the only option is a device in the network that translates between IPv6 and IPv4. Currently we have such a protocol, NAT64. And from a technical point of view it is a disaster. Looking back, we can say that the only feature of IPv6 that makes people invest in IPv6 is the bigger address space. So it is safe to say that most of the internet would have waited to invest in IPv6 until we were (almost) out of IPv4 addresses. So by its very nature this transation between IPv6 and IPv4 would have NAT component. In my opinion, It is clear that during the time IPv6 was developed, any solution involving NAT would have been rejected. So I'm confused, what transition technology was achievable (also in the political sense) but not delivered? If there is a magical transition technology that allows an IPv6-only host to talk to an IPv4-only host, then let's deploy it.
Re: Recent NTP pool traffic increase
>What I mostly meant is that there should be a regulated, industry-wide >effort in order to provide a stable and active pool program. With the >current models, a protocol that is widely used by commercial devices is >being supported by the time and effort of volunteers around the world. My employer has a budget 'for the good of the Internet' So I'd suggest that people involved in NTP (certainly pool) submit proposals. Likewise, there are country code DNS registries that are non-profits and have budgets for research, etc. Given that time is important for DNSSEC, it maybe worth contacting them.
Re: REMINDER: LEAP SECOND
In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote: >Philip Homburg wrote: >> >> For UTC the analog approach would be to keep time in TAI internally and >> convert to UTC when required. > >This is much less of a solution than you might hope, because most APIs, >protocols, and data formats require UT. (Usually not UTC but a >representation isomorphic to traditional UT which ignores leap seconds.) Supporting legacy formats can be annoying. In some cases it would be no problem. For example NTP. If there is a defined way to convert between TAI and UTC then converting TAI to NTP timestamps is easy except during an actual leap second. Which is not really a problem. Unix systems would probably need a few new system calls to accept time in TAI. File formats like tar are unlikely to matter much: find a consistent way of encoding time around the leap second and most likely nobody will care. In any case, it would be nice if future formats and systems could have a sensible time keeping system.
Re: REMINDER: LEAP SECOND
In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote: >Leap years and DST ladjustments have never caused us any major >issues. It seems these code paths are well tested and work fine. I seem to remember that they were not tested that well on a certain brand of mobile devices a few years back... In any case, we can abstract from time zones and DST by using UTC internally and then converting to local time in the UI. For UTC the analog approach would be to keep time in TAI internally and convert to UTC when required. There is however a big problem with that. UTC as a time scale is not predictable. There is no way of computing the number of seconds between 2000-01-01 00:00 and 2100-01-01 00:00 because that value is undefined. The net results is that representing, say, 2020-01-01 00:00 as a TAI timestamp is impossible until about 6 months before that date. One way forward for people who for some reason feel attached to representing the rotation of the earth in civil time is to have a scheme for leap second just like leap years. For example, insert a leap second every 18 months. And then revise that scheme once a century to cope unexpect changes in the earth's rotation. (Or just get rid of them all together and move to a different time zone every 4000 years).
