multiple prefixes

[Bernd Walter]

On Mon, Feb 11, 2013 at 03:01:09PM -0800, Doug Barton wrote:
> On 02/11/2013 02:47 PM, Tim Chown wrote:
> >
> >On 11 Feb 2013, at 22:26, Doug Barton <dougb at dougbarton.us
> ><mailto:dougb at dougbarton.us>> wrote:
> >
> >>On 02/11/2013 02:13 PM, Tim Chown wrote:
> >We've had a production IPv6 network for maybe 10 years. It's not PI, as
> >our provider is pretty much a shoe-in, but it could be, and in similar
> >networks in the US, it is.  For the complexity of network and
> >applications, I'd not want to have to live with address translation,
> >even NPTv6.  Maybe it's because most universities have lived without any
> >form of NAT due to being early IPv4 adopters, with their internal
> >network being largely or exclusively on public IPs, and the same
> >"thinking" is being happily, even if you think it's naively, applied for
> >IPv6.
> 
> I'm not saying it's naive, and I'm certainly not saying that everyone 
> should do what I'm suggesting. If your org can absorb the costs of using 
> PI space internally, more power to you!
> 
> My point (and I think I've made it sufficiently by now, so hopefully 
> this is the last repetition) is that for the overwhelming majority of 
> enterprises that is just not possible, nor is it even desirable. The 
> thing that most IETF'ers (and other ivory tower dwellers) really 
> seriously don't "get" is that in the world outside people actually 
> _like_ NAT. Maybe for the "wrong" reasons, almost certainly in part 
> because they don't understand the difference between NAT and a SPIF, but 
> they _do_ like it. And when we come along and say, "Ok, that's lovely, 
> but you're doing it all wrong, and now you have to do it this way 
> instead" they react pretty much like you did. "Um, no ... what I have is 
> working for me just fine, please go away."

NPTv6 is not a bad thing for companies.
They usually should have the knowledge to handle it and also handle the
cases where it won't work - FTP is named, but not a driving factor anymore.
SIP is another thing and a system not known it's public address is bad.
But for most companies systems shouldn't be reachable from outside and
also SIP goes through proxies.

> It's even _more_ important to understand this in the context of end-user 
> networks. Currently they have absolutely ZERO motivation to deploy IPv6. 
> There is no IPv6-only content now, nor is there likely to be in the next 
> 5 years certainly, maybe even 10. So NATv4 is a perfectly good solution 
> for them, and they have no motivation at all to stop using it. (Note, 
> I'm purposely excluding ultra-large enterprises who have outgrown all of 
> 1918 space, since they are an edge case.)

End-user networks is the point I fear most.
A long time they lived with dynamic single address as workaround for not
getting full static network address space.
I always saw this as a temporary workaround.
This is partly Ok - I'm not going into deep discussion about n:1 NAT
problems here as we all know them, but mentioning some points are
required to explain.
The internal addresses are reachable for the knowledged persons by
doing static port based translations and their internal systems run
with static RFC1918 addresses, so dynamic addresses at redial-in only
touches the outside view, which is handled by dynamic DNS, which produces
a diffrent class of problems.
As some providers run out of piblic adress space, they don't even hand out
a single public IPv4 address anymore.
Cell phone providers do since a long time, and this year in Germany
some wired providers based on cable-TV lines started.
They have no choice as they don't have a public address for everyone.
Users get native IPv6, but with dynamic prefix, and a single RFC1819
via tunnel over IPv6.
This means end users are not reachable via IPv4 internet anymore, all
they can do is consume.
On the other side home users start doing internet services, not classic
www-Servers or such, which is still left for expirienced users, but they
have home automation for room temperature, TV-recorders, ...
With the current IPv4 situation they put everything into clouds with all
the security implications.

My hope was that with IPv6 the return of static addresses will come back
again the way I was used from the early days when I started using the
internet.
But they get dynamic prefixes and most providers (of which some have
little choice) only offer static address option for commercial customers.
Same as with IPv4, where end users can't opt for static address(es).
You need a registered business to get such a contract - sigh.
With IPv6 there is an implication because it is not only the single
public address which change - the whole internal network gets renumered
on redial-in.
The IPv6 based light switch can't talk to the IPv6 based light bulb anymore
for some time fraction because your DSL flapped.
There are some slow transition mechanics, but those are limited to a small
overlapping time - don't forget another ISP customer might use your
prefious network now.
The public addresses changes - no matter how you handle this situation.
The only option is to use internal addresses.
Link local addresses won't allow a split network, although many people
live with a single flat network at home this is not really advised with
home automation in place.
ULA addresses are required as the only solution since PI are even less
available than static PA.

The question is NTPv6 or multihomed.
With NTPv6 the systems don't know their public address, which creates
many problems.
Compared to current IPv4 situation it's better as it is 1:1, but still
a workaround with drawbacks.
With multihomed systems need to decide which outgoing address to use.
RFC3484 handles it - not absolutely perfect, but it does.
Unfortunately RFC3484s suggested default table didn't know about ULA, so
systems handle them the same as public addresses and the RFC6724, which
has a revised default, is quite new (Sept 2012) and not even made it into
FreeBSD-current yet (wrote emax, but should better opened a PR) and likely
not into many other OS.
RFC6724 is important because it says that when you connect to an ULA
address, then try to use an ULA sender address and if you connect a public
address, then don't use an ULA sender.
This is a configuration issue, but you can't expect end users to do this
and it has to be done on every multihomed system as there is no service
to distribute site policy changes.

Both things however won't handle the requirement for split DNS and dynDNS,
because public addresses are still dynamic, but as systems know their
addresses it has more functionality.
It would be much better if ISPs won't do dynamic prefixing at all, at
least as an option for everyone as both things are still workarounds.
Renumbering on ISP change it not that much of a problem for end users
and many companies as it is for some companies, but for redial-in it is.
I know there is a technical reason why ISPs do dynamic prefixe, but IMHO
they break too much.

> That doesn't mean that I don't think IPv6 is important, or necessary; 
> it's actually becoming more of both every day. But we have to be 
> realistic about the environment we're working in, and what will and will 
> not "sell" in that market.

Most users are happy if they can get web pages and all the other fancy
things as online games, of which they don't even understand how it can
work over internet as they didn't started the internet app.
You can't expect them to vote for technical details, which also means
that they can't use their vote on the market.
A few, and not only technical people, however do care if they can reach
their home automation directly or via cloud provider and only offering
them to use cloud providers let them stay away from such systems
completely.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.