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

[Andrew 👽 Yourtchenko <[e-mail]>]

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 <[e-mail]> wrote:
> 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: [e-mail]
> Reply-To: [e-mail]
> To: [e-mail]
> 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/
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>