Re: [v6ops] Operational Consensus on deployment

[Tore Anderson <[e-mail]>]

* Philip Homburg

> As far as I can tell, your proposal maps every public IPv4 address to a
> unique IPv6 address.

Correct.

> In that context, why not just use, for example, host routes to route IPv4
> traffic to the right interface of an IPv4 host.

That would work, but there's a few reasons why I don't consider that
optimal either:

- It would not help me with IPv6 deployment at all, it distracts me from
it. Having a fully IPv6-enabled infrastructure is the goal I want to be
moving towards. SIIT-DC, like MAP and DS-Lite, *requires* IPv6.

- I'd still need to maintain IPv4 throughout my infrastructure. If I'm
also doing IPv6 at the same time, this means I incur extra operational
overhead and cost compared to single stack - "dual everything", as Gert
said.

- There would be no way to aggregate all the host routes, it would
severely pollute my IGP as every single /32 route must be distributed
throughout my network. SIIT-DC, on the other hand, requires no host
routes, as IPv4 traffic will be typically be translated to the server's
primary IPv6 address, creating no extra IGP routes beyond the /64 or
whatever that's routed to the LAN segment anyway.

- You get interesting routing challenges if the servers need occasional
Internet access through a stateful NAT (e.g., to download software
updates). You'll want to route the traffic sourced from the public
address directly out to the Internet, while traffic from RFC1918 sources
needs to be routed through the NAT instance. But both the NAT and no-NAT
route must necessarily be represented as an IPv4 default route. I'm sure
this could be solved with the use of PBR and/or VRFs, but that incurs
extra complexity. An SIIT gateway is on the other hand reached with a
normal /96 route, and does not need to interfere with default routing at
all. Same goes for a NAT64 instance that could be used for occasional
Internet access analogous to the above.

- You'll actually need special configuration on the servers, setting up
and monitoring a secondary service address. With SIIT-DC, there is no
need to touch the servers at all, except in the case where a host agent
is needed to facilitate applications that do not support NAT and/or IPv6.

- The host routes would need to be installed on each the upstream
routers serving as default gateways for the servers' LAN segments, which
scatters these assignments all over the place. With SIIT-DC, the SIIT
gateways have a complete overview of all configured mappings and what
service addresse are available.

All in all it feels to me more like a stop-gap solution that only deals
with IPv4 depletion, rather than something that also facilitates real
progress towards an single-stack IPv6 infrastructure.

(BTW: I've made the assumption that you mean that the server's primary
IPv4 addresses is a private/RFC1918 one, which is then used as the
next-hop for a public /32 assigned to the loopback interface. Let me
know if this assumption was incorrect.)

Tore