Recent posts in the same categories

2 comments:

  1. Anonymous 22 September 2013 00:43
    Ivan,

    Why there is a translation in only one direction.

    Why not translate in both directions. e.g.

    Sender Host SIIT Gateway
    Src: 203.0.113.50 64:ff9b::203.0.113.50
    Dst: 198.51.0.10 2001:db8::192.51.0.10

    Why do we need to save the mapping for each internal server to its IPv4 address.

    Thanks,

    SJ
    Replies
    1. Tore Anderson 22 September 2013 10:10
      Hi SJ,

      You can certainly do that. Except that you'd end up using the same 96-bits prefix for both source and destination (not 64:ff9b::/96 and 2001:db8::/96 at the same time) you describe is actually "vanilla" SIIT operation, and it's exactly what happen if you do not have a static mapping in place for either the source or the destination. The static mapping feature is not defined in the SIIT RFC, it's actually my idea of a "value-add" feature.

      I'll explain why. In your example above, the server must be configured with a secondary address 64:ff9b::192.51.0.10/128 (in addition to its primary 2001:db8::1/64 one). You must to that so that it will actually respond to traffic destined to that address. The sysadmin responsible for the server must additionally ensure that any software (web servers etc) are configured to accept application traffic to this secondary address, it must be added into any HA/fail-over software, any firewall rules for the public service must be duplicated so that traffic is allowed to both the primary address for native IPv6 clients and the secondary address for translated IPv4 clients, you'll need to set up monitoring and SLA reporting for service availability on both addresses, and so on, and so on. Also, none of this can be done until the network administrator actually assigns the IPv4 address from the pool, because until that point the "IPv4-Mapped IPv6 Address" (as it's properly known as) isn't known.

      The network administrator, on the other hand, must ensure this /128 is actually routed to the server in question. The obvious way to do that, is to set up a static route on the server's default gateway to the /128 using the primary/native address (2001:db8::1) as the next-hop. This route must then be imported into the IPv6 IGP so that it is reachable throughout the IPv6 network. You'll end up with one such /128 host route in your IPv6 IGP for each translated IPv4 service network, and configuration that needs to be pushed to every device that is operating as a default gateway for a system being made available through SIIT.

      At least in my organisation, this is a lot of extra complexity. It's reminiscent of dual stack, actually. Because of this, I consider the static mapping feature a much more elegant end manageable solution. The server operator will only have to deal with native IPv6. The firewall operator will only have to add rules for the server's native IPv6 address. You'll only have to monitor that address. The IPv6 networks remains free of a bunch of external /128 IGP routes, and so on and so on.

      The work flow I picture is one where the server guys just sets up everything on IPv6, and when they're done, puts in an order à la: "I've just set up public internet services on 2001:db8::80, 2001:db8::443, and 2001:db8:babe::, please give me IPv4 frontend service for those". Then the network/SIIT operator will find three free IPv4 service addresses and set up static mappings for them, push them to the translator boxes, and that's it.

      When I think about it, I seem to recall having been told that there is some Brocade router or load balancer that can do this dynamically - when receiving a packet destined for an IPv4 service address for the first time, it'll do a reverse DNS lookup to find the hostname, then look up the hostname and see if there's an AAAA record. If so, it installs a mapping between the two.

      Anyway, as I said earlier, you can certainly use "vanilla" SIIT instead if you prefer. I did so myself, before I got my hands on a SIIT implementation that had the static mapping extension included. Ivan blogged about this last year:

      http://blog.ipspace.net/2012/05/ipv6-only-data-center-built-by-tore.html
      http://blog.ipspace.net/2012/10/skip-transitions-build-ipv6-only-data.html

      The latest post also contains a link to my RIPE presentation about the doing this in "vanilla" SIIT mode.

      Tore
Add comment
Home
Sidebar