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

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

Hi Tore,

On 10/7/14, Tore Anderson <[e-mail]> wrote:
> 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.

Thanks! some comments for comments inline.

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

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.

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

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.

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

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

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

Agreed.

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

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.

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

Right.

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

True. :-)

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

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

>
> Tore
>