Re: [v6ops] Operational Consensus on deployment

[Tore Anderson <[e-mail]>]

* Philip Homburg
> If dual stack implies no NAT anywhere what is then the correct term for
> NAT44 or NAT444 along with native IPv6?
> 
> Just curious. I would call that dual stack. But you don't appearently.

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

>> As for additional help needed, well, I'm trying to put my money where my
>> mouth is and coming up with a solution to these problems - you could
>> help by reviewing my drafts. :-) The solution works, there is already
>> running open-source code, so rough consensus is all that's missing...
> 
> My gut feeling is that translating IPv4 packets to IPv6 or vise versa is
> bad idea. Some thing will come up to make your life miserable. In some
> sense it is very similar to tunneling.

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.

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.

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

> The question is then, why not simply run on RFC-1918 addresses internally?
> Afterall, usually the goal is to provide IPv4 services.

I'd like to to it Right from the start, and actually deploy IPv6.
Changing to RFC1918 and NAT44 will do nothing to help me to deploy IPv6,
if anything it would distract me from it. When I do get around to doing
IPv6 as well, I'm stuck with the complexity of running two IP protocols
in parallel, resulting in extra OpEx and reduced reliability I'd rather
go without. (IMHO, IPv4-only is preferable to that, and it looking at
the IPv6 availability graphs it would appear most operators share this
view.)

If I ever want to actually discontinue the IPv4+NAT44 stuff in order to
get rid of that extra complexity and go IPv6-only, then that's another
very time-consuming and non-revenue-generating project to look forward
to. (Not.)

In summary, IPv4 scarcity forces us to change the way we've always done
stuff up until now. I'm not happy about it, but it is unfortunately
inevitable. Considering I need to change all this stuff now anyway I'd
much rather do it in a way that actually solves the problem long-term,
and doesn't just line me up for another big and painful migration
projects a few years down the road.

> Maybe our setup is unique, but we have quite a few servers in remote
> data centers that need to access internal servers. What we do is have
> ACLs in the firewalls to only allow the addresses we know about and keep
> the rest of the Internet out.
> 
> In your model, any IPv4 address in a remote data center would either have to
> translated to an IPv6 address (which of course nobody recognizes) or we
> need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL
> problem in place.

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

The above IPv6 address with the embedded IPv4 dotted quad is
syntactically valid, by the way, you don't even have to convert it to
hex (cf. RFC4291 section 2.2).

I would generally recommend locating the SIIT gateways as close to the
edge of your network as possible. Ideally as a logical function located
inside the border routers. That way, on the inside you can simply treat
everything as IPv6, and have one IPv6 firewall, one IPv6 ACL, one IPv6
IGP topology, and so on, and so on.

Tore