Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt

[Tore Anderson <[e-mail]>]

Good morning,

> Nice draft.
> 
> Why do you restrict the architecture to a per host agent?
> 
> Why do you restrict the IPv4 address binding to a virtual network
> interface?

I'm assuming you're specifically talking about the -2xlat draft here?
The plain architecture doesn't include a host agent at all, the host
agent is intended to be used only in the case where the application
software does not support IPv4, and/or where the application protocol
doesn't support NAT.

I don't mean to restrict the architecture to a per host agent at all.
The -2xlat draft simply seeks to document how the plain SIIT-DC
architecture can be extended to support IPv4-only application software
and/or application protocols which cannot work through NAT. It's a
specific use case with a specific solution. Doesn't mean you can't do
other fun stuff too. :-)

> Wouldn't this dual translation work equally well as a proxy device
> serving multiple legacy application servers, each with their own
> unique static address mapping?

So if I understand you correctly an SIIT-DC topology that uses all
three modes (plain for NAT-friendly HTTP, host agent for NAT-unfriendly
FTP, proxy for a couple of IPv4-only machines) could look something like
this?

  (IPv4-only Internet)
    |
  +-+-[SIIT-DC Gateway]--------------------+
  | xlat prefix: 64:ff9b::/96              |
  | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1 |
  | v4,v6 map 2: 192.0.2.15, 2001:db8::a:a |
  | v4,v6 map 3: 192.0.2.20, 2001:db8::1:2 |
  | v4,v6 map 4: 192.0.2.25, 2001:db8::f:f |
  +-+--------------------------------------+
    |
  (IPv6-only data centre network)
    |
    +-- 2001:db8:a:a HTTP server, IPv6-only, v4 service addr=192.0.2.15
    |
    +-- 2001:db8:f:e FTP server, IPv6-only (native IPv6 service addr)
    |   2001:db8:f:f FTP server via Host Agent, service addr=192.0.2.25
    |
  +-+-[SIIT-DC Proxy]---------------------------+
  | xlat prefix: 64:ff9b::/96                   |
  | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1      |
  | static rt 1: 192.0.2.10 nexthop 169.254.0.2 |
  | v4,v6 map 2: 192.0.2.20, 2001:db8::1:2      |
  | static rt 2: 192.0.2.20 nexthop 169.254.0.3 |
  +-+-------------------------------------------+
    |
  (Proxy's IPv4-only private backend LAN - 169.254.0.0/16)
    |
    +-- 169.254.0.2 IPv4-only machine 1 (192.0.2.10 on loopback)
    |
    \-- 169.254.0.3 IPv4-only machine 2 (192.0.2.20 on loopback)

I.e., that the proxy device essentially takes the role of a CE router
with an IPv4 LAN behind it (for which it's the default router), but
instead of terminating the 192.0.2.x addresses locally, it routes them
to endpoints in that IPv4 backend LAN using host routes? (Or something
along those lines anyway, the IPv4 topology could of course be as
complex as you would like.)

I don't see why this wouldn't work just fine. I guess I just never saw
the use case for myself (for me it would still be easier to just
provision a native IPv4-only VLAN for such a purpose, but I can see the
use case if you have an deep IPv6-only network topology and need to
support a couple of IPv4-only devices in the innermost parts of it. I'm
thinking that describing this SIIT-DC Proxy could be left to a future
draft, though, would you agree?

> I'm thinking that true legacy machines are unlikely to be targets for
> implementations of this new technology.

Definitively not. The current drafts are for greenfield deployments, or
mostly so. The servers must necessarily support IPv6. The application
software and application protocols as well, *unless* you're using a host
agent - in which case the server must implement the host agent (today,
that is equivalent to "the server must be running Linux" as far as I know).

> Nit s/poining/pointing/

Thanks!

Tore