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

[Tore Anderson <[e-mail]>]

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

> 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.

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).

> "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.

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.

> "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.

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

> "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..)

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.

> 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
> ?

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.)

> 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.

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

> "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.

Ack.

> "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.

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...

> 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.

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

> 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 ?

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