Hi all,
My US-based employer will be starting a new business unit soon that will require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a waitlist (though I’m not sure where they’re getting new IPs from), but the faster way is to buy blocks from people who already have them. I’m aware of Hilco Streambank - are there any other auctions? If I want to buy via private sale, does anyone know of ways to find sellers?
Thanks,
Ross
I’ve used IPv4 Market Group before. Process was pretty painless, and they were trusting enough to allow us to pay by PO (your mileage may vary).
Hi Ross
Try ripe ncc’s broker list here:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers
They would easily find what you need. As the process is usually through escrow.com, there shouldn’t be a serious concern.
This one:
https://www.ipv4auctions.com is doing that. Usually the prices is a bit higher
If need more info, feel free to get in touch with me off-list
-payam
Ross -
No facilitator is necessary, but if you wish to know ones that are aware of ARIN’s procedures,
then you can find them here: https://www.arin.net/resources/transfer_listing/facilitator_list.html
Best wishes,
/John
John Curran
President and CEO
ARIN
Thanks everyone who replied. I got many responses off-list, including a lot of positive endorsements for several different vendors. It’s good to know there are so many reputable options.
-Ross
If is a new US business and you are working internationally why not go simple and use IPv6 addresses?
John Lee
I’m rolling my eyes. We’ll be using IPv6, but obviously we need IPv4 too.
What do you mean you want to be able to reach and be reachable by more than 20% of the internet?
I’m all for IPv6 deployment and I go so far as to push it onto customers (and configure things correctly so that they have a good IPv6 experience) who otherwise wouldn’t even know anything about it or care at all, but to pretend that one can subsist without at least some IPv4 space to facilitate translation at this stage is just unrealistic.
In article <CAJJbKjre2RnEpasbaSevGYO75EU63WQOs4o_LyoEJ4onGfX=2g@mail.gmail.com> you write:
If is a new US business and you are working internationally why not go
simple and use IPv6 addresses?
Just a guess, but it's probably because they would like for the large
fraction of the net that is still v4 only to be able to contact them.
Even if you do have v6, some things like DNSSEC don't work very well
if you can't do them over v4.
Is that so?
In BIND, I think this can be solved by using the “minimal-responses” knob. Mark.
If you don’t want fragmented IPv6 UDP responses use
server ::/0 { edns-udp-size 1232; };
That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically
be fragmented. You will then have to deal with PMTUD failures as the servers switch
over to TCP.
What I find ridiculous is firewall vendor that claim to support adding stateful rules
on demand but don’t add “from <src> to <dst> frag offset != 0” when they add “from <src> to <dst> proto xxx src-port <dst-port> dst-port <src-port>” or don’t do packet reassembly to
work around the lack of passing fragments. This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.
Mark
If you don’t want fragmented IPv6 UDP responses use
server ::/0 { edns-udp-size 1232; };
That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically
be fragmented. You will then have to deal with PMTUD failures as the servers switch
over to TCP.
Speaking of, anyone have any good reports similar to that which was the genesis of this discussion but regarding PMTUD broken-ness on IPv6? Perhaps specifically focusing on its impact w.r.t DNS over TCP?
My understanding is that this is quite common on IPv4 but not as evident due to in-transit transparent fragmentation.
What I find ridiculous is firewall vendor that claim to support adding stateful rules
on demand but don’t add “from <src> to <dst> frag offset != 0” when they add “from <src> to <dst> proto xxx src-port <dst-port> dst-port <src-port>” or don’t do packet reassembly to
work around the lack of passing fragments. This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.
I think the "justification" for not allowing fragments is that they can be crafted specifically to evade filter policies.
Now, I'd argue that, if you want to not be a broken device, you then need to do reassembly so that you can inspect. At minimum, do so for the typical attack case which uses very small fragments and/or large L3 headers to split up application data since the result is presumably something that fits within the MTU of your LAN. Or statefully track whether fragments are expected for a conversation. Or drop fragments that could be used to evade policies but permit fragments that couldn't. Or...something other than breaking things horribly and whining that the protocol is broken.
Of course, a lot of these are also the same boxes that, through design or misconfiguration, break PMTUD, too, I suspect.
If you don’t want fragmented IPv6 UDP responses use
server ::/0 { edns-udp-size 1232; };
That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically
be fragmented. You will then have to deal with PMTUD failures as the servers switch
over to TCP.Speaking of, anyone have any good reports similar to that which was the genesis of this discussion but regarding PMTUD broken-ness on IPv6? Perhaps specifically focusing on its impact w.r.t DNS over TCP?
My understanding is that this is quite common on IPv4 but not as evident due to in-transit transparent fragmentation.
What I find ridiculous is firewall vendor that claim to support adding stateful rules
on demand but don’t add “from <src> to <dst> frag offset != 0” when they add “from <src> to <dst> proto xxx src-port <dst-port> dst-port <src-port>” or don’t do packet reassembly to
work around the lack of passing fragments. This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.I think the "justification" for not allowing fragments is that they can be crafted specifically to evade filter policies.
So require frag 0 to have what you require to do the filtering. Most stacks send maximal sized initial fragments up to 1280 bytes. For DNS the UDP header will be there as there is at least 8 bytes of fragmented packet. Additionally reassembly attacks are much harder as there is 32 bits of fragmentation identifier rather than 16 in IPv4.
IPv6 fragmentation was designed with knowledge of the IPv4 reassembly attacks in mind.
You'll get no argument from me, here. This is not new nor are ways to deal with it unknown. Despite that, it's a common reason I hear for just blindly dropping all fragments. Personally, I consider such devices/stacks broken, but that doesn't mean we don't have to deal with them, unfortunately.
That is true provided that you accept that some people may not be able to respond without the packet getting fragmented due to tunneling or a million other reasons they may not support that MTU. Nonstandard MTU has always and seems will continue to be problematic. It all really began with tunneling which by its nature lowers the MTU available to the application. Firewalls really have to just deal with it and do the re-assembly they need to. It does create tremendous performance issues for these devices at high bandwidth. Bottom line is fragmentation sucks and V6 does not make it any better.
Steven Naslund
Chicago IL
Except that, in IPv6-land, anyone with effective MTU < 1280 has the onus put on them to "make things work" i.e. come up with an adaptation layer or some sort of tunnel-layer transparent fragmentation. If you're relying on The Internet to fragment to <1280 for you, you're bound to see breakage. I'd like to think we can safely ignore this case in terms of operations.
I am interested in what people would suggest as the best practice for dealing with any link of a nonstandard MTU lower than 1500. It’s usually fine for end users such as those with VPNs or other tunnels, but it can cause issues when it’s on an intermediary link. I am personally involved in a project that uses links with an MTU of 1410. It’s high enough that it should not be an issue for the most part, but it does cause me some concern. It’s at an internet exchange of sorts so it could, theoretically, transit data as an intermediate link with neither side of the connection being aware of its existence.
Right now we don’t have much traffic so it’s fine, but it does beg the question of what we would do if we came upon an issue. We could set a “virtual” MTU of 1500 such that it will always fragment even if DF is set, but that’s out of spec so it may be a bad idea.
Thanks ~ Bryce Wilson, AS202313