Hacker News Reader

Comment by souterrain | Hacker News Reader

I’m in the ARIN region. Two things:

1. My home has Verizon fiber. No native IPv6. I have a tunnel for this, but such solutions aren’t going to work for the masses. The other in-region residential provider, Comcast, has great native IPv6 service, but had layer 2 performance issues versus price.

2. At $dayjob I just ordered a circuit from Level3/Centurylink for a branch site. No IP justification form was required if I needed only IPv4 /30. But for dual IPv4 /30 + IPv6 /126, I was required to provide written justification. Shouldn’t this be the other way around? Unencumbered IPv6 for all, with paperwork for IPv4?

EDIT: these are not site allocations, just point-to-point link addresses, hence the /126. Still, I’m being asked to justify IPv6 but not IPv4.

View on HN

> IPv6 /126

Uh, unless you're running BGP over this or getting a larger subnet statically routed to you, get a larger prefix. A /48 or /56 is the current recommendation [1] for business end site allocations.

[1] - https://tools.ietf.org/html/rfc6177

Of course, this is just a “point-to-point Ethernet” not an allocation.

That said, I think the original intent was that such “point-to-point Ethernets” should have been issued /64, but seems /126 is common practice.

Actually many ISPs do not even give out a fully routable /126, but simply use an LL fe80:: address for the CPE:

* https://www.ripe.net/publications/docs/ripe-690#4-1-2--unnum...

Comcast gives out /64s at least. I got my router to successfully ask for 2 on different interfaces.

Same story on Spectrum. On their residential plans they will give out a /64 by default. However w/ DHCPv6-PD I was able to successfully request a /56. What I found mildly interesting was they wouldn't allocate a /60. (My guess was: whatever silicon they've got pushing IPv6 packets around probably likes segmenting the routing table on a clean byte boundary.)

Providers don't give out publicly routable /126. Generally most providers aren't going to give out anything longer than a /64 partially because they don't need to and partially because routing tables [0]. They want to route to you via a prefix that's pre-allocated to carve up for the region you're in.

[0] https://www.ripe.net/publications/docs/ripe-690

A /48 is the minimum folks will pass via bgp on the internets (it's the /24 of the ipv6 world).

Also another fyi: if you're rolling commodity hw (bcm tridents etc) after a /64 up to /128 you are dipping into another constrained forwarding table - can't fill your box with too many of those.

> A /48 or /56 is the current recommendation [1] for business end site allocations.

I can get a /56 even at my apartment just by setting my router to request it.

Many VPS providers (for ex. OVH) also do the same thing and provide a single IPv6 address.

Here's another fun one: how many usable IPs do you get out of the 4 consumed by that /30? Not sure about L3 specifically but it seems a lot of ISPs haven't yet figured out that it's not necessary to waste half the IPs in every /30 allocation with gateway and broadcast IP.

Spectrum/Charter and Verizon have finally started allocating a single IP out of a /24 instead of giving me a whole /30 when all I need is one routable address. Too little too late though.

I think you're missing the parent's point, that you can use a /31 without separate network (not gateway) and broadcast addresses.

Putting multiple customers on the same /24 introduces all kinds of issues. Either you leave it open leaving IP's vulnerable to hijacking, or you have to create static ARP and/or MAC entries, and deal with all the hassle of managing that. Presumably, you're describing consumer service where they don't really have to care about your security unlike a business/enterprise level service.

Unfortunately we're just not at a stage yet where anyone can easily associate a static IPv6 to an EC2 instance and expect it to "just work". My phone isn't always happy visiting IPv6 addresses. Many coffee shops and university wifi I regularly use don't support IPv6. My home router doesn't seem to route IPv6 correctly (or maybe it's Comcast's problem; I don't know; I gave up because everything I use can work over IPv4 as well :-/). My work internet connection doesn't route IPv6, either.

I'm all for IPv6 but it's not widespread enough to ditch the need for static IPv4 addresses.

Transitioning to native IPv6 requires running dual stack for quite some time, we'll never get there if we don't start

Not necessarily. A network can go entirely IPv6 internally and just have adaptors at the edge to translate parts of the Internet that aren't IPv6 yet.

Doing this means all IPv4 network addressing headaches vanish internally. Oh there are going to be 260 remote offices instead of 100 like you said at the kick off meeting? No problem, my subnets are easily big enough either way.

And with this approach your budget for the edge reduces over time as more of the network supports IPv6, whereas with a NAT gateway your budget increases as throughput rises.

You do need to be really firm during purchases, if the "IPv6 support" in that shiny new product is actually more of a wishlist item than an actual feature, you're getting a full refund, no second chances. That goes for desk phone (if your outfit still has those), printer/ copiers, IoT devices, and everything.

I’ve heard some variant of that for over two decades and still here we are.

In the early 2000s the issue was the routing hardware did ipv6 shitty. That took a few years to get to a better spot (and a few years more to get it almost at IPv4 parity feature wise). Then it took a few more years for transit providers to roll it out...then the broadband networks. Now we're in a time when v6 support is mixed across cloud companies and there are large swaths of geographical areas that are lagging (sup Central and South America + china). Were closer...

A /126, seriously? Comcast Business gave us a /56, unprompted, as part of our account setup.

This sounds like a simple P2P link to do BGP over. I highly doubt CL is using /126’s as standard allocation sizes.

That makes a lot more sense! Good call.

My home connection has a /56 (o2/telephonica de) ....

Yeah, I too got a /56, same country, different ISP. It just showed up one day, which confused me at first.

> It just showed up one day, which confused me at first.

I've heard this pretty often. One day it gets rolled out without any notice, and surprise, you're on V6. Plays havoc.

Maybe their thinking is that if you are just requesting IPv4 you probably aren't set up to support IPv6, but if you ask for IPv4 + IPv6 then they want to know why you can't just use IPv6 for everything and so ask for justification for using IPv4?

Which would be about the most braindead reasoning ever?!

Can you really use ipv6 for everything? I thought only ipv4 could do that?

If you are a user sure. There are ways to bridge IPv6 to IPv4 (A router someplace translates for you, I suppose NAT but I'm not an expert on how this works), while going the reverse is harder because there is no way to bridge IPv4 to IPv6. There are a lot of people running IPv6 only who don't even know it. (most cell phones for example)

Only server administrators need to care, and there they have a problem. If you run real IPv4 only: then IPv6 only users can talk to your server no problem and won't even realize anything is happening. If you run IPv6 only there are a lot of IPv4 only users who cannot connect to you. Thus if you run a server it is critical to have a real IPv4 address.

Did you notice the "real" qualifier to IPv4 in that last paragraph? many (most?) IPv4 only users are behind a NAT system such that they cannot run a server anyway. If you are running a IPv4 Server you need an address of the type that RIPE just ran out of. If you are a user you can use a fake IPv4 address and keep on working.

If you are a server administrator you should ensure that all your servers have IPv6 addresses. You should then collect statistics on use. There may be a date in the future where you can suggest to your management that you can cut off [small number]% of your users by going IPv6 only and selling your existing IPv4 address to the highest bidder for $$$. That is a business decision, but once it starts happening it will make headlines, but I wouldn't want to be first. (if you wait too long enough others will have gone IPv6 only that there isn't a real customer cost to being IPv6 only and then the market for IPv4 will disappear - and interesting value maximization problem if you want to play that game)

NAT is an acronym for "Network Address Translation" so that's the right term to use.

NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-IPv4 NATs, that is to say pretty poorly: but we've long since adjusted the architecture of Internet-enabled software to cope with the flaws, so practically speaking they work just fine.

We've been down a road for a while now of funnelling all of the Internet's services into something-over-HTTP, so running a server might need a public IPv4 address, but as the supplies already assigned to LIRs by the RIPE NCC (and other RIRs) start to dwindle I expect we'll see more services offered whereby you can share an HTTP front end with a bunch of other people, proxied to an IPv6 (or private space) server you run.

I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. While you can easily map the entire IPv4 address space into an IPv6 subnet of your choosing this is obviously not possible the other way around. Address mapping would have to be highly dynamic to work at all and there would be no real guarantee addresses stay the same that way. Additionally in order to make this work more or less transparently DNS responses have to be modified breaking in presence of DNSSEC validation (the same as DNS64 in reverse). One could probably avoid this by using something like reverse DS-Lite which is more or less NAT with tunneling combined.

A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly.

Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.

> I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones.

Not only has CGNAT existed doing this at scale for many years in SE Asia, it commonly happens on cell networks in the US now even, so yes, it’s feasible.

that would be quite uncommon. what happens often though is the reverse. maybe you misread my point?

One more reason to reconsider the design of DNSSEC and take it back to the drawing board, since it has virtually no meaningful deployment today anyways, and is already badly flawed.

There's nothing wrong with the design of DNSSEC. It's just doing its job, making sure that the addresses in the DNS replies match the RRs configured by the domain owner and preventing MitM attacks against the DNS system. The issue is DNS64, which for all intents and purposes is a form of MitM attack: If you can run a transparent DNS64 service you can redirect traffic however you want. You're not limited to faking "equivalent" AAAA records which send traffic to the correct IPv4 server. This is incompatible not only with DNSSEC in particular but with any attempt to ensure the end-to-end integrity of domain resolution. Anyway, we already have a solution to the problem of IPv6-only networks connecting to IPv4 servers which doesn't depend on manipulating DNS entries: DS-Lite.

The job it does has very little operational value, and it breaks things we care about. In just a few months of deployment, DoH has done more to protect DNS queries than DNSSEC has in almost 25 years of work. Any time you look at something that DNSSEC makes harder, your first thought should be, "is the real problem here that we're trying to do tree-PKI DNSSEC in the first place"? I'd content that's always the case.

DoH and DNSSEC are orthogonal systems. DoH protects the connection from the client to the resolver from eavesdropping or tampering, but doesn't do anything to ensure the integrity of the records reported to the resolver (which still uses regular DNS) and doesn't prevent the resolver itself from tampering with the data. The aim of DNSSEC is to provide for the end-to-end integrity of the RRs so that a client can be sure that the reported data matches the data entered by owner of the domain. This is essential for protocols such as DANE. The introduction of DoH does not eliminate the need for DNSSEC and the two protocols can be used together.

At this point, I'd say DANE is more essential for DNSSEC than DNSSEC is essential for DANE. But both are solutions casting about desperately for a problem to solve; in DNSSEC's case, for more than 20 years, through repeated false starts in design.

The comparison with DoH is imperfect, certainly, but still probative. DoH does something, today; it protects queries to sites all around the Internet, and doesn't depend on a boil-the-ocean deployment that must occur simultaneously in two directions (from the service operators who must sign their zones and from the end systems which must upgrade and enable DNSSEC). DoH is a relatively young protocol and will, within the next year or two, be almost completely mainstream, a feature of most of the deployed base of browsers. DNSSEC will still be languishing, because we aren't humane enough to drag it out to the yard, rifle in hand, to put it out of its misery.

Reply on news.ycombinator.com