Re: [v6ops] Operational Consensus on deployment

[Tore Anderson <[e-mail]>]

* Fred Baker (fred)

> On Aug 9, 2014, at 12:07 PM, Ross Chandler <[e-mail]> wrote:
> 
>> How about the case of an IPv6-only DC network with multiple
>> separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which
>> translation prefix will be used in the case where DNS64 (Sec 3.3)
>> is also being used? It seems like DNS64 might only work easily with
>> a single translation prefix.
> 
> RFC 6147 is designed for one translation prefix. One could imagine a
> translation prefix per tenant, and you would (at least in concept)
> need a DNS64 per tenant. That is unless you got smart and looked at
> the source address of the packet to see which tenant it came from.

I'm thinking that multiple instances is an advanced topic that would be
better documented in a separate draft. I'd preferably like to keep this
draft concise and to the point, thus making it easy to read and understand.

In any case, multiple SIIT instances should be relatively
straightforward. If the applications in questions are server-style ones
that are merely responding to client traffic (think HTTP) then it's
really a no-brainer, as the inbound client traffic will already have a
source IPv6 address within the appropriate SIIT instance's translation
prefix, to which the server will respond accordingly automatically.

If on the other hand it's the IPv6 application that is responsible for
initiating traffic to IPv4 destinations, then it would need to choose
the appropriate translation prefix for synthesising the IPv4-mapped IPv6
address to initiate communication to. It would have to do that even if
there is only one SIIT instance, too.)

If the application is using DNS, then DNS64 could be used for this
purpose, which could be deployed in a number of ways (locally on the
server itself, dedicated DNS64 servers per SIIT instance, one DNS64
server but with multiple views per SIIT instance, ...).

Other options would be for the application to synthesise the IPv4-mapped
addresses itself according to RFC6052, in which case the choice of
translation prefix (and thus the SIIT instance) would be a configuration
options; or finally, you could use the host agent approach, in which
case the translation prefix (and thus the SIIT instance) becomes part of
the host agent's configuration instead.

Tore