Re: [v6ops] Operational Consensus on deployment

[Philip Homburg <[e-mail]>]

In your letter dated Tue, 05 Aug 2014 22:10:35 +0200 you wrote:
>The current IPv6 dual stack transition mechanism is defined in RFC 4213,
>and it makes no reference to NAT whatsoever. This thread started out by
>Fred asking if we needed to update the consensus that dual stack is the
>IETF-recommended transition method, and in that context, no I not
>consider that the current dual stack recommendation includes NAT44*.
>
>It would certainly be possible to update RFC 4213 to mean that the new
>recommendation is to do NAT44* in combination with IPv6, though. But I
>don't think that's a good idea. We find ourselves in a hole, so maybe we
>should stop digging instead of getting ourselves a new shovel...

The IETF has ignored NAT44 for a very long time. Most home users don't
actually have IPv4 access: they have a middle box that breaks things.

Outside the IETF (and I assume to a large extent also inside the IETF) people
will find this line of reasoning overly pedantic. To them, NAT44 is just 
part of the Internet.

We can also be pedantic about 'dual stack' and refer to v6+v4 or v6+NAT44 or
v6+NAT444.

However I think the meaning of dual stack is the concept that IPv4 and IPv6
are independent. Neither is tunneled over or translated into the other.

In that sense, whether IPv4 is native or behind a CGN is not relevant. We
matter is that IPv6 is completely independent of that.

>If you by tunneling are referring to the catastrophe that was 6to4, then
>I disagree. It is more like 6RD or MAP-E as it will typically contained
>within a single administrative domain.

No operator likes tunnels. 6RD is not considered 'native IPv6', it is a
second class citizen. 

Personally I think tunneling IPv6 locally over IPv4 works very well. But
there seem to be very few people who agree with that point of view.

>As for other things failing, if you have some concrete examples, please
>let me know. I'd certainly want to see if I can make those work, or if
>not, make sure the drafts properly document the limitations causing the
>failure.

The thing is that in the IPv4 world, probably every coding mistake you
can imagine is out there somewhere. Anything that differs from the way
IPv4 is normally done, may cause things to fail in some small fraction of
systems.

To give a concrete example. The obvious solution to a lower MTU is actually
path MTU discovery, but that doesn't work, so we do MSS clamping.

Out in the field are middle boxes that break MSS clamping. 

The reason those boxes work is that every server supports an MTU of 1500.
If your server doesn't, things break.

>> I think it is safe to say that in your model you have enough public IPv4
>> address to run your services. What your proposal eliminates is the need
>> for internal IPv4 addresses.
>
>That's right. No addresses lost due to network infrastructure,
>servers/applications performing internal tasks, unused addresses on LAN
>segments due to CIDR ^2 boundaries or space set aside for future growth.
>One public service per IPv4 address only. I'd imagine that most internet
>content providers have a much higher number of internal
>applications/servers than they have public service addresses, so this
>adds up to significant savings.

Except that any truely internal server, you can already run on IPv6-only.
No need to change anything in your front-end to do that.

>Presumably you'll want a firewall inside of the SIIT gateway, to deal
>with IPv6 ACLs? If so, you only need one firewall and only one ACL. If
>you previously had an ACL that said something like in iptables syntax,
>where 192.0.2.100 is the trusted IP address you want to allow:
>
>--source 192.0.2.100 --protocol tcp --dport ssh -j ACCEPT
>
>...with SIIT, you'd instead do, assuming 64:ff9b::/96 is the translation
>prefix):
>
>--source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT

Now we wait for somebody to type 64:ff9b::192.0.2.0/24 instead of
64:ff9b::192.0.2.0/120.

Also, this not in canonical form. So any program that outputs these address
uses a different syntax. Try grepping your firewall config for an address
you see in tcpdump and not finding it.

And I wonder howmany people understand this notation at all.