5 ms·

>We are happy to have over 99% of our IPv4 and IPv6 -Space covered under a Route Origination Authorization, and that we are right now dropping RPKI invalid rout

>We are happy to have over 99% of our IPv4 and IPv6 -Space covered under a Route Origination Authorization, and that we are right now dropping RPKI invalid routes in every single Point-of-Presence for AS16509. Does anyone know if AWS is going to push the remaining 1% to implement ROA? Also, it sounds like an unsigned route - which I think most BGP announcements are - is still accepted, right? Any idea when we can start to require routes be signed?

wmf 6y ago
Making RPKI mandatory is like turning off IPv4 after everyone has adopted IPv6.
- tialaramex 6y ago
  I believe it is likely that global IPv4 routing goes away before universal adoption of IPv6 at clients. Transitional technologies allow IPv4 holdouts to have "working" Internet despite an increasing proportion of IPv6 nodes, there's some device somewhere which is mapping your connection to some IPv6-only service as an imaginary IPv4 connection. Such things wouldn't scale with 99% of users and usages, but can handle say, five thousand IPv4 users on your ten million customer ISP who mostly visit Facebook and check email. Eventually the long distance traffic for IPv4 is tiny, because there's a transition device nearer almost all remaining IPv4 users and that's turning their traffic into IPv6 for the long haul anyway. At that point if you're a backbone provider, IPv4 is a sizeable cost (the routing tables for it are horrendous) for negligible benefit (hardly any of your traffic) and its future only looks more dismal. So you start deprecating this service for your customers, and they don't bother to buy a replacement because they have a transition device to help any residual IPv4 users. And so one day, without a fanfare, there just isn't really an IPv4 Internet any more, and the RIRs will just deprecate their management of the numbering for that network because it's obsolete. Ideally this is an obscure nerd event, like a leap second, which your friends at first don't understand, and then when you explain it they realise it's boring and they don't care. I hope to live to see it.
  - p1mrx 6y ago
    > a transition device nearer almost all remaining IPv4 users and that's turning their traffic into IPv6 for the long haul anyway. This is mostly impossible, because an IPv4 packet doesn't have room for an IPv6 destination. The opposite direction (NAT64) is common, but that's for IPv6 clients talking to IPv4 servers.
    - tialaramex 6y ago
      So, what you do goes like this: You provide DNS service, offering A answers even where (if you were to ask the public Internet) there are none. When you're asked for foo.bar.example you do an AAAA query, and you track for a while a mapping from the answer to a (RFC1918 or assigned for this purpose) IPv4 address, and recording it, then you reply to the A? query with your temporary address as the answer and a chosen timeout (maybe you plan to have this work for one hour, so you give 3600 seconds timeout). You then act as a NAT gateway that translates between IPv6 and IPv4 for that address mapping. This doesn't work great, it breaks protocols which assume they're transparent (e.g. some FTP modes), it is slower and clunkier than "just" having IPv4 as we do today, and as I said it isn't viable with huge numbers of users (you run out of address space) but it's good enough that a lot of common application software remains usable this way. This is about the gentle slope down, so it doesn't need to be perfect or even have the potential to be perfect, it just needs to work well enough to reduce the amount of tech support phone calls. Think of it like the way pulse dialling was deprecated. Nobody needed to figure out a way to have pulse dialling be as good as tone dialling, let alone a truly out-of-band system (as is used by your mobile phone, and most other modern systems), they just needed to minimise the situation where lots of customers discover that they were using pulse dialling only because now it doesn't work.
      - p1mrx 6y ago
        You're describing NAT-PT, which the IETF moved to "historic status" in 2007: https://tools.ietf.org/html/rfc4966 https://tools.ietf.org/html/rfc4966 Recent developments like DNS over HTTPS make it even less viable.
    - 6y ago
kitteh 6y ago
There can be legitimate use cases why a network maybe have a very few amount of prefixes not signed or even invalid: canaries and beacons. For example, running tests to a signed, unsigned and invalid prefix can provide insight into how other networks are routing to them. One example is a beacon to probe to determine if a network has enabled origin validation. Failure to connect, or a change in the routing path can provide insight into which networks on the internet have enabled origin validation.

wmf 6y ago

Making RPKI mandatory is like turning off IPv4 after everyone has adopted IPv6.

tialaramex 6y ago
I believe it is likely that global IPv4 routing goes away before universal adoption of IPv6 at clients. Transitional technologies allow IPv4 holdouts to have "working" Internet despite an increasing proportion of IPv6 nodes, there's some device somewhere which is mapping your connection to some IPv6-only service as an imaginary IPv4 connection. Such things wouldn't scale with 99% of users and usages, but can handle say, five thousand IPv4 users on your ten million customer ISP who mostly visit Facebook and check email. Eventually the long distance traffic for IPv4 is tiny, because there's a transition device nearer almost all remaining IPv4 users and that's turning their traffic into IPv6 for the long haul anyway. At that point if you're a backbone provider, IPv4 is a sizeable cost (the routing tables for it are horrendous) for negligible benefit (hardly any of your traffic) and its future only looks more dismal. So you start deprecating this service for your customers, and they don't bother to buy a replacement because they have a transition device to help any residual IPv4 users. And so one day, without a fanfare, there just isn't really an IPv4 Internet any more, and the RIRs will just deprecate their management of the numbering for that network because it's obsolete. Ideally this is an obscure nerd event, like a leap second, which your friends at first don't understand, and then when you explain it they realise it's boring and they don't care. I hope to live to see it.
- p1mrx 6y ago
  > a transition device nearer almost all remaining IPv4 users and that's turning their traffic into IPv6 for the long haul anyway. This is mostly impossible, because an IPv4 packet doesn't have room for an IPv6 destination. The opposite direction (NAT64) is common, but that's for IPv6 clients talking to IPv4 servers.
  - tialaramex 6y ago
    So, what you do goes like this: You provide DNS service, offering A answers even where (if you were to ask the public Internet) there are none. When you're asked for foo.bar.example you do an AAAA query, and you track for a while a mapping from the answer to a (RFC1918 or assigned for this purpose) IPv4 address, and recording it, then you reply to the A? query with your temporary address as the answer and a chosen timeout (maybe you plan to have this work for one hour, so you give 3600 seconds timeout). You then act as a NAT gateway that translates between IPv6 and IPv4 for that address mapping. This doesn't work great, it breaks protocols which assume they're transparent (e.g. some FTP modes), it is slower and clunkier than "just" having IPv4 as we do today, and as I said it isn't viable with huge numbers of users (you run out of address space) but it's good enough that a lot of common application software remains usable this way. This is about the gentle slope down, so it doesn't need to be perfect or even have the potential to be perfect, it just needs to work well enough to reduce the amount of tech support phone calls. Think of it like the way pulse dialling was deprecated. Nobody needed to figure out a way to have pulse dialling be as good as tone dialling, let alone a truly out-of-band system (as is used by your mobile phone, and most other modern systems), they just needed to minimise the situation where lots of customers discover that they were using pulse dialling only because now it doesn't work.
    - p1mrx 6y ago
      You're describing NAT-PT, which the IETF moved to "historic status" in 2007: https://tools.ietf.org/html/rfc4966 https://tools.ietf.org/html/rfc4966 Recent developments like DNS over HTTPS make it even less viable.
  - 6y ago

kitteh 6y ago

There can be legitimate use cases why a network maybe have a very few amount of prefixes not signed or even invalid: canaries and beacons. For example, running tests to a signed, unsigned and invalid prefix can provide insight into how other networks are routing to them. One example is a beacon to probe to determine if a network has enabled origin validation. Failure to connect, or a change in the routing path can provide insight into which networks on the internet have enabled origin validation.