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). http://ipv4marketgroup.com/ On Mon, Oct 1, 2018 at 6:57 PM, Ross Tajvar <ross@tajvar.io> wrote:
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
Hi Ross Try ripe ncc’s broker list here: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brok... 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 On Mon, Oct 1, 2018 at 6:59 PM Ross Tajvar <ross@tajvar.io> wrote:
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
On 1 Oct 2018, at 6:57 PM, Ross Tajvar <ross@tajvar.io> wrote:
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?
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 <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 On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar <ross@tajvar.io> wrote:
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
If is a new US business and you are working internationally why not go simple and use IPv6 addresses? John Lee On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar <ross@tajvar.io> wrote:
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
On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar <ross@tajvar.io> wrote:
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'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too. On Thu, Oct 4, 2018, 12:00 PM John Lee <jllee9753@gmail.com> wrote:
If is a new US business and you are working internationally why not go simple and use IPv6 addresses?
John Lee
On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar <ross@tajvar.io> wrote:
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
On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar <ross@tajvar.io> wrote:
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
On Thu, Oct 4, 2018 at 11:20 AM Ross Tajvar <ross@tajvar.io> wrote:
I'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too.
On Thu, Oct 4, 2018, 12:00 PM John Lee <jllee9753@gmail.com> wrote:
If is a new US business and you are working internationally why not go simple and use IPv6 addresses?
John Lee
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. - Matt
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.
In article <60afb948-5f6d-8ea8-00c9-6d4d92ff0269@forfun.net>, Marco Davids via NANOG <mdavids@forfun.net> wrote:
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?
Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot easier to stick to v4. Geoff Huston has written about this a lot and it's a well known problem in the DNS community. I'm surprised if it's news to anyone here. https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
On 5/Oct/18 03:07, John Levine wrote:
Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot easier to stick to v4.
Geoff Huston has written about this a lot and it's a well known problem in the DNS community. I'm surprised if it's news to anyone here.
https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
In BIND, I think this can be solved by using the "minimal-responses" knob. Mark.
On 5 Oct 2018, at 3:12 pm, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 5/Oct/18 03:07, John Levine wrote:
Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot easier to stick to v4.
Geoff Huston has written about this a lot and it's a well known problem in the DNS community. I'm surprised if it's news to anyone here.
https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/5/18 1:53 AM, Mark Andrews wrote:
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. -- Brandon Martin
On 5 Oct 2018, at 4:22 pm, Brandon Martin <lists.nanog@monmotha.net> wrote:
On 10/5/18 1:53 AM, Mark Andrews wrote:
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.
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. -- Brandon Martin
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/5/18 3:16 AM, Mark Andrews wrote:
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. -- Brandon Martin
On 10/5/18 1:53 AM, Mark Andrews wrote: 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.
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
On 10/7/18 11:47 PM, Naslund, Steve wrote:
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.
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. -- Brandon Martin
On Oct 7, 2018, at 8:55 PM, Brandon Martin <lists.nanog@monmotha.net> wrote:
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. -- Brandon Martin
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
participants (13)
-
Brandon Martin -
Bryce Wilson -
John Curran -
John Lee -
John Levine -
Marco Davids -
Mark Andrews -
Mark Tinka -
Matt Harris -
Naslund, Steve -
Payam Poursaied -
Ross Tajvar -
Tyler Conrad