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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Oct 2014 08:41:53 +1300

Tore,

One substantive comment first, followed by a nit.

The substantive comment is on the positioning of your proposal. Basically
I think it is a Good Thing to describe this solution, and its pros and
cons. But I still think that for many established operators it's not yet
clear that it's the best choice. So I think that

(a) Appendix B.4 (Dual Stack) should cite RFC 6883 as a full exploration
of the dual stack option. It does after all contain a hidden reference to
your draft: "Some ICPs who already have satisfactory operational experience
with IPv6 might consider an IPv6-only strategy, with IPv4 clients being
supported by translation or proxy in front of their IPv6 content servers."

(b) I also think the first lines of1.1 (Motivation and Goals) are a bit too
much like opinion - ultimately it should be each operator's choice what
they do. Rather than deconstructing your text, I suggest the following
friendly amendment:

   Historically, dual stack [RFC4213] [RFC6883] has been the recommended way to
   transition from an IPv4-only environment to one capable of serving
   IPv6 users.  However, for data centre operators and Internet content
   providers, dual stack operation has a number of disadvantages
   compared to single stack operation.  In particular, running two
   protocols rather than one results in increased complexity and
   operational overhead, with a very low expected return on investment
   in the short to medium term while few end-users only have connectivity
   to the IPv6 Internet.  Furthermore, the dual stack approach does not
   in any way help with the depletion of the IPv4 address space.

   Therefore, some operators may prefer an approach in which they only
   need to operate one protocol in the data centre as they prepare for
   the future.  The design goals are:

Nit:

Something very strange has happened in these two references:

10.2. Informative References

   [I-D.anderson-v6ops-siit-dc-2xlat]
              tore, t., "SIIT-DC: Dual Translation Mode", draft-
              anderson-v6ops-siit-dc-2xlat-00 (work in progress),
              September 2014.

   [I-D.gont-6man-deprecate-atomfrag-generation]
              Gont, F., Will, W., and t. tore, "Deprecating the
              Generation of IPv6 Atomic Fragments", draft-gont-6man-
              deprecate-atomfrag-generation-01 (work in progress),
              August 2014.
Regards
   Brian

---

From: Tore Anderson <[email-masked]>
Date: Mon, 06 Oct 2014 08:04:26 +0200

Hi Brian,

* Brian E Carpenter

>    the future.  The design goals are:

Thank you! I've added the reference in B.4 and used your suggested text
for 1.1, so it'll be part of -02. You can see the result here:
https://github.com/toreanderson/ietf/blob/master/siit-dc.raw.txt

>               deprecate-atomfrag-generation-01 (work in progress),

This I do not quite understand. This strangeness seems to originate from:

http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.anderson-v6ops-siit-dc-2xlat.xml
and
http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gont-6man-deprecate-atomfrag-generation.xml

I have no idea what's happened, but I will try to figure it out. Thanks
for pointing it out!

Best regards,
Tore Anderson

---

From: Tore Anderson <[email-masked]>
Date: Mon, 06 Oct 2014 08:18:53 +0200

Hello,

As Brian was quick to notice, I've uploaded a new version of the SIIT-DC
draft. I would like to solicit the WG's input on the draft (and its
companion draft[1]), in particular whether or not the work is seen as
relevant and useful, and any feedback or suggestions big or small on how
to further improve it. (Do feel free to send me minor issues in direct
e-mail if you prefer no to "spam" the WG list with them.)

[1] https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc-2xlat/

Also, since running code is important, I'd like to point out that there
are several implementations that implement an SIIT-DC Gateway (or
something very close to the spec), from the top of my head and in
alphabetical order: Brocade ADX, Cisco ASR1k, F5 BIG-IP LTM, and
Linux/TAYGA. There's also an SIIT-DC Host Agent available at
https://github.com/toreanderson/clatd (using Linux/TAYGA).

Best regards,
Tore Anderson

-------- Forwarded Message --------
Subject: I-D Action: draft-anderson-v6ops-siit-dc-01.txt
Date: Sun, 05 Oct 2014 11:54:23 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Newsgroups: gmane.ietf.announce

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
        Author          : Tore Anderson
	Filename        : draft-anderson-v6ops-siit-dc-01.txt
	Pages           : 30
	Date            : 2014-10-05

Abstract:
   This document describes SIIT-DC, an extension to Stateless IP/ICMP
   Translation (SIIT) [RFC6145] that makes it ideally suited for use in
   IPv6 data centre environments.  SIIT-DC simultaneously facilitates
   IPv6 deployment and IPv4 address conservation.  The overall SIIT-DC
   architecture is described, as well as guidelines for operators.
   Finally, the normative implementation requirements are described, as
   a list of additions and changes to SIIT [RFC6145].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-dc-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Mon, 6 Oct 2014 23:36:28 +0200

Tore,

A few thoughts/nits about both of the drafts.

draft-anderson-v6ops-siit-dc:

"4.1.  Application Support for NAT" might also mention the apps that
use the IP ID (this is mainly diagnostic stuff like tcptraceroute) -
adding the host agent would not get them to work.

"4.7.  Migration from Dual Stack" says about using the DNS round robin
to migrate from dual stack. Do you mean having IPv6 native, IPv4
native and IPv4-translated addresses in the DNS replies sent to the
client ? Sounds like this would add quite a lot of complexity, but
maybe I am reading it incorrectly.

"4.8.2.  IPv6 Atomic Fragments"

If the application does use the IPv4 ID bit (though it might be deemed
as corner case), and you do the dc-xlat, might be beneficial to always
add the atomic fragments - this way one can recover (at least in
theory) the IPv4 ID back.

"4.8.3.  Minimum Path MTU Difference Between IPv4 and IPv6"

I observed somewhat subtle interactions when translating ICMPv4 into
ICMPv6: ICMPv4 spec (rfc792) says to include just the IP header + 64
bits of the original packet that triggered the ICMP, while the ICMPv6
(RFC4443) has a "MUST" in 2.4c to include as much of original message
as possible without violating the MTU.. - so if an application relies
on extra info *and* the intermediate node does not provide that, it
might fail. (NB: In my tests, some IPv4 boxes do give more than
IP+64bit, some do not..)

Also: since on the v4->v6 path the fragments can be definitely smaller
than 1280 bytes, is it worth mentioning in this section that the
server may have to reassemble the smaller fragments than 1280 and more
?

Another tricky case that might arise in this scenario is if ICMPv4 was
sent big enough to be fragmented on the way. The translator (if it
does not do at least the virtual reassembly) does not know the full
length of the reassembled ICMPv6 packet, but has to add it as part of
the checksum calculation.

"5.2.  Static Address Mapping Function"

There should be discussion or at least a reference about the
translation and checksum neutrality similar to
http://tools.ietf.org/html/rfc6052#section-4.1 - some things that are
possible to do with a checksum-neutral transform, are not possible
without it - as mentioned in
http://tools.ietf.org/html/rfc6052#section-4.1.

"5.4.  Loop Prevention Mechanism"

In the v6->v4 direction, one can send a packet sourced from the server
within a Static Address Mapping IPv6 address to a /128 within SIIT
preffix that maps to the same IPv4 address - as a result causing the
reinjection of an IPv4 packet with src=dst=server_IPv4_public_address,
thus causing a translation into IPv6 with
src=dst=server_IPv6_static_address_mapping address and delivered back
to the server. On quick look it should be harmless, but the fact that
this ambiguity exists, is probably worth mentioning maybe - also since
it was not there in pure SIIT.

draft-anderson-v6ops-siit-dc-2xlat:

Probably discussing a new scenario compared to 464XLAT, namely, the
communication between the two servers within the DC between the IPv4
legacy apps, let's follow a path of (src, dst) pair:

Initial (4A,4B) packet seen by host agent A will be translated into
(S6A, SIIT6B), then sent to the SIIT-DC, where it will be translated
into (4A, 4B), then routed back, then translated as (S6A, S6B), then
sent to  host agent B, then translated to (4A,4B). The reply to this
packet will be sent as (4B, 4A), translated by the host agent B to
(S6B, SIIT6B), then hits SIIT-DC, gets translated to (4B, 4A), hits
SIIT-DC again, gets translated to (S6B, S6A), sent to host A, there
translated by host agent A to (4B, 4A).

This pattern creates a traffic visibility issue and makes a SIIT-DC a
potential bottleneck - since they are located at the edge of the
network - so is worth mentioning/discussing.

On the topic of running code: could be fun to kick the tires of
https://github.com/ayourtch/nat46/tree/master/nat46/modules with
regard to using it as a host agent, it might work though it might
require a bit too much plumbing (routing + ND proxy on the outer
interface) to be practically usable ?

--a

On 10/6/14, Tore Anderson <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tore Anderson <[email-masked]>
Date: Tue, 07 Oct 2014 09:24:10 +0200

Hi Andrew,

Thanks for your feedback, I'll update the drafts to include it sometime
this week and ping you off-list to check if you agree with the changes
further comments in-line.

* Andrew 👽  Yourtchenko

> adding the host agent would not get them to work.

Ack, look into this and see if I can mention something about it.

Though when I'm talking about "application support" here I'm really
referring to the main service itself (e.g., HTTP, FTP, SMTP, and so on).

> maybe I am reading it incorrectly.

Yes, if you have a service that's currently serving IPv4 traffic nativly
using a number of IN A records for load balancing purposes, for example:

service.tld. IN A 192.0.2.1  ; native
             IN A 192.0.2.2  ; native
             [..]
             IN A 192.0.2.10 ; native

You could gradually migrate traffic to SIIT-DC by adding/replacing
individual records pointing to SIIT-DC IPv4 Service Addresses, like so:

service.tld. IN A 192.0.2.1    ; native
             IN A 192.0.2.2    ; native
             [..]
             IN A 192.0.2.9    ; native
             IN A 203.0.113.1  ; SIIT-DC

Now you could expect that ~10% of your IPv4 client traffic will move to
the SIIT-DC system, while ~90% remains native. If you're happy with the
way it works, you can continue migrating until there's no native
addresses left, at which point you can remove them from the servers/load
balancers if you want. I was thinking this would be a more gentle
approach than switching all traffic at once, particularly for
high-volume servers.

> theory) the IPv4 ID back.

True, but are there any actual applications (as in, not network
diagnostics, but actual services) out there that care about the IPv4
Identification value?

> might fail. (NB: In my tests, some IPv4 boxes do give more than

Right.. This is a property of SIIT/RFC6145 though, it's not specific to
SIIT-DC. The translator will just translate whatever information is there.

> server may have to reassemble the smaller fragments than 1280 and more

I don't think there's any requirement in any spec that a reassembled
IPv6 packet must be larger than or equal to 1280 in size for it to be
valid? I think it's worth mentioning only if it is likely to cause
problems. My gut feeling says it isn't, but do you have any examples
that demonstrate otherwise?

(Individual fragments being smaller than 1280 is certainly valid and
common too.)

> the checksum calculation.

Yep, fragmented ICMP messages will not be translated, cf. RFC6145
section 1.2.

> http://tools.ietf.org/html/rfc6052#section-4.1.

Ack.

> it was not there in pure SIIT.

That's a clever way for a server to do a health test of the SIIT-DC GW,
actually. :-) But it would be a bit unreliable, as it could trip uRPF
filters along the way back. I agree it doesn't seem like a security
issue though, as the server can send packets to itself in much less
complex ways, too...

> network - so is worth mentioning/discussing.

Ack. I'll try to add a section on hairpinning.

> interface) to be practically usable ?

Well, routing and ND proxy you can handle from user space. If you look
at my clatd, it's basically just a perl script that discovers the
required network environment, sets up routing/ND proxy/etc and fires up
TAYGA with the right configuration. If your module supports basic
RFC6145 plus the static mapping stuff, it is probably possible to adapt
the script to use your module instead of TAYGA. I'll try to play a bit
with it later, thanks for the pointer!

Tore

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 7 Oct 2014 11:51:01 +0200

Hi Tore,

> further comments in-line.

Thanks! some comments for comments inline.

> referring to the main service itself (e.g., HTTP, FTP, SMTP, and so on).

Right. I didn't know if there are corner cases that are similar to
this one, so it is a strawman indeed. A single-session
client-initiated protocols should generally be fine.

> approach than switching all traffic at once, particularly for

Right, from dualstack you are moving to "triple-stack", with the third
connection having the clientside properties of IPv4 and server-side
properties of IPv6. I thought that would be tricky from the
troubleshooting standpoint for the same reasons as dual-stack is
trickier than single-stack. But I might be seeing a problem where
there isn't.

> diagnostics, but actual services) out there that care about the IPv4

I don't know of any. But we can't claim that CLAT+DC-SIIT is fully
equivalent to just IPv4 without it. I'm being pedantic, I know :-)

> SIIT-DC. The translator will just translate whatever information is there.

Agreed.

> (Individual fragments being smaller than 1280 is certainly valid and

You're right. For some reason I thought that the standards-compliant
initial fragment should not be less than 1280, but that's not correct,
thanks.

> Yep, fragmented ICMP messages will not be translated, cf. RFC6145

Right.

> issue though, as the server can send packets to itself in much less

True. :-)

> with it later, thanks for the pointer!

Oh, nice! So you'd "just" need to have forwarding enabled and install
the correct IPv6 route to that interface in addition. I've neglected
to do some parts of 6145 because of the module's original place (in
tandem with iptables, in a small CPE) , balancing with my bug creation
abilities. Unicast me on how it goes - I did an OS X clat proof of
concept using the core functions from it, but always useful to have
someone else to kick the tires.

--a

---

From: V6ops <[email-masked]>
Date: Wed, 8 Oct 2014 07:45:03 +0200

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?

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?

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

Nit s/poining/pointing/

> On 06 Oct 2014, at 08:18, Tore Anderson <[email-masked]> wrote:
> 
> Hello,
>

---

From: Tore Anderson <[email-masked]>
Date: Wed, 08 Oct 2014 08:57:08 +0200

Good morning,

> Why do you restrict the IPv4 address binding to a virtual network

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?

> 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

---

From: Ray Hunter <[email-masked]>
Date: Wed, 08 Oct 2014 09:10:39 +0200

> Tore Anderson <mailto:[email-masked]>
> 8 October 2014 08:57
> Good morning,
>
>> Nice draft.
>>
Correct. Subject line was just taken from a digest message.

> to endpoints in that IPv4 backend LAN using host routes?
Correct.
>   (Or something
> support a couple of IPv4-only devices in the innermost parts of it.
Indeed. Depends on the DC infra. If you have a multi-site DC connected 
via DWDM and/or dot1qinq and/or private MPLS, sure.
If you have deep IPv6-only inter-connected DC sites, or a campus 
network, then that IPv4 VLAN could be expensive.
>   I'm
Agreed. Although I'm not sure it's a whole lot of work to incorporate it 
into this draft.
> ------------------------------------------------------------------------

-- 
Regards,
RayH