Short version: Renumbering of end-user networks can never be
sufficiently testable, reliable or secure to
be in any sense "routine".
Therefore, we cannot expect to have a routing
scaling solution which depends on such
"routine" renumbering be accepted by the vast
majority of end-user network administrators -
which is a requirement, since we need to get
almost all such networks to adopt it.
Hi Brian and Ran,
Regarding:
http://tools.ietf.org/html/draft-carpenter-renum-needs-work-00
I don't think it will ever be practical (while retain existing
Internet protocols) to solve the routing scalability problem in a
way which requires end-user networks renumber in order to use
another ISP.
Even if we ignore the problem of keeping sessions alive during a
renumbering operation, I think there are fundamental problems with
your intention (I assume) to find a way of making either IPv4 or
IPv6 renumbering "a relatively routine event", as your I-D mentions.
Even if you ignored the problems of implementing the requisite
automated renumbering functions in existing equipment (primarily
hosts, including printers and in routers, access points and other
networking gear) I think there are fundamental problems with what
needs to be done beyond this.
To be practical, something with the extreme impact of renumbering
needs to be extremely reliable. In order for this to be the case, I
think it needs to be:
1 - Highly or completely automated, so it can all be done under
central control.
2 - Secure - against hackers or accidental activation.
3 - Fully testable. There must be a sham approach to implementing a
renumbering operation in order to prove to the administrators
that all required numbers are changed, in the right time, to
the correct new numbers. But as I discuss below, this is
nowhere near sufficient to prove the whole renumbering
operation would in fact succeed.
IP addresses turn up in DNS zone files and ACLs all over the place -
often well beyond the physical network in question and often in
places which are no suitable for secure, automated control by the
administrators of the end-user network.
Let's say the end-user network is a hosting company. Each host in
that network has a single IP address. Each such host handles the
websites sites of 20 companies: www.fu1.com, www.bar2.com etc.
Each such company has an IP address for one of these hosts in its
own DNS.
So in order to securely, automatically, renumber the hosting
company's network, that company would need to already have installed
secure, automated, testable, IP address changing mechanisms into all
the master nameservers of all its customer companies. This is
clearly impractical. Furthermore, those customer companies
generally wouldn't run their own DNS, so each such company fu1 and
bar2 etc. would need to negotiate and authorise their DNS company to
enable some hosting company (unknown to the DNS company) to be able
to automatically update a particular IP address, and only that
address, within the customer company's DNS records.
What about caching times?
If you are going to make IP addresses unstable, compared to the
current situation, then everywhere you have an IP address, in an
ACL, or whatever, and you haven't already got a secure, automated,
testable, renumbering system, you need to replace it with some
construct which is either remote controlled, as just suggested, or
by a DNS lookup. Then some software process needs to check that DNS
entry frequently - but how frequently? Not only must you substitute
an IP address with a DNS entry, but you need to specify a caching
time. Ideally, those times should be long, to avoid overly
burdening the DNS system. However, if you want to renumber, it
would be good to make the times short instead, just before the
renumbering operation. There's no obvious way a "DNS company"
(whoever runs the DNS of fu1.com) is going to be able to let fu1's
hosting company control this. The administration for this would be
costly and error prone, even if it was technically easy to do.
(Maybe it is technically possible with RFC 3007.)
Overall, I can't imagine any administrator of a substantial network
would come to accept that renumbering was a safe, non-disruptive,
thing to do to their network. Unless all the world's hosts and
applications use new protocols which assume dynamically changing IP
addresses, there's no way an administrator is going to be able to
assure the owners of the network that renumbering will work as expected.
It is bad enough that renumbering completely changes the IP
addresses of every device in the network to some other one or more
values. The whole network has to be commanded to do this, securely,
quickly - and yet as soon as the process starts, everything is in
flux. How are these security arrangements meant to work when hosts
may have one or the other or both IP addresses?
Networks are already fragile enough, without having them depend on
another one or more layers of supposedly secure stuff which is
supposed to change their whole addressing structure without anything
going wrong.
How could the administrators know their renumbering management
system would work as intended? To add some extra layer to simulate
the renumbering process would be helpful, but how could anyone be
sure this was adequate? The only way to test a renumbering system
is to run it - to actually renumber the entire network.
If this could somehow be done in a few seconds, it might be workable
- renumber, test and renumber back to the original addresses, all in
about 10 or 20 seconds.
However, this will never be practical. DHCP servers need new
marching orders and it would take minutes or hours or whatever for
the various changes to propagate to hosts. Likewise, there are DNS
caching times to consider.
The only real test would be when all hosts have their new addresses
and all the cached, old, DNS values have been flushed from all hosts
around the world which are using them. Likewise, ACLs or any other
settings in hosts outside the network need to be reconfigured before
it is possible to establish whether the renumbering operation was
completely successful.
This would be inordinately disruptive, not least because it will
probably require automated or manual effort on the part of systems
outside the physical network. Any such automated effort requires
manual effort to set up the appropriate software, configure it
properly, set up security arrangements etc. Then, these automated
systems need to be individually tested, which is a manual process.
Since networks are generally changing, how could the administrators
be sure their renumbering system would really work for 100% of the
network as it is from day-to-day? I don't see how they could,
except by doing a test renumbering, and then somehow finding out
what parts, if any, were not renumbered as expected.
If this sort of "routine renumbering" requires new features in
hosts, then there is a major problem developing the protocols and a
many year delay - such as 5 to 10 years - before such protocols are
likely to be found in many or most printers, NAS devices, access
points, mobile devices etc. which are commonplace in many networks.
(The same problem of lack of IPv6 support in printers etc. no-doubt
holds back many networks from switching to IPv6.)
In short, I think there profound and unchangeable reasons (assuming
we are still relying on TCP, UDP, existing applications etc.) why
administrators of any network with more than a handful of IP
addresses will never accept that renumbering their entire network
should be a routine event.
Imagine giving the command, and watching as the whole network
attempt to reorganise itself by the individual efforts of each
device - as the TCP session through which the command was given dies
due to the renumbering process itself! It is bad enough commanding
a server in another country to "reboot" - but it sounds like a
nightmare telling an entire network to renumber itself, in the hope
that it will still be manageable and actually function enough as a
network, even if not fully operational, after the process is completed.
If the renumbering involves the DNS servers used by internal hosts
and/or the outside world, how is the administrator going to be
confident that internal hosts will behave as expected, when they are
asynchronously changing their IP addresses, while even their local
DNS server is changing its IP address too? Only the root DNS server
addresses remain valid, so each host would need to frequently
rediscover the IP address of local DNS servers, since it could not
rely on any actual IP address in a config file, or in a DHCP lease.
I suppose the saving grace is being able to define multiple DNS
server IP addresses - with only one needing to be operational.
I believe a requirement that end-user network renumbering be secure,
reliable and sufficiently low in cost to be "routine" cannot be an
essential part of any routing scaling solution.
Fortunately, there are promising, potentially practical, approaches
to solving the routing problem without routine renumbering of
end-user networks and without any changes to host operating systems
or applications: LISP, APT, Ivip and TRRP. For IPv6, maybe
Six/One Router will be practical.
An architecturally cleaner approach would be to scrap existing
protocols and therefore operating system stacks and applications.
Then we could develop new protocols for which IP addresses could be
fluidly changing without impact on applications. If that could be
done with a new approach to routing, or perhaps the existing BGP
system plus SHIM6 etc. to scalably provide multihoming, with
portability between ISPs being handled through "routine renumbering"
then this *might* be a scalable solution which is reasonably
elegant. But that would only be for IPv6, since renumbering from
one IP address to another, without having both during a changeover
period sounds unworkable to me.
However, this is never going to happen. We need to work with
existing hosts and protocols.
We need to make something which is highly attractive to the very
first adopter, in five or so years time. So it can't rely on host
changes etc. and must provide immediate benefits over costs,
irrespective of how many or how few other networks have adopted the
system.
I intend Ivip to meet these requirements. LISP with PTRs is in
principle capable of meeting these requirements too, but I think
Ivip is a better approach. APT has a backwards compatible approach
for handling packets sent from non-upgraded networks, so perhaps
that could be attractive to end-users too, without there needing to
be many other APT adoptors. However, the granularity of the EIDs
for this support would not be finer than /24 unless there was a
single "APT Island".
I think your I-D is useful, since it identifies many of the barriers
to making the renumbering of end-user networks a "routine" process.
I hadn't thought about some things you mention, such as IP addresses
being stored in cookies, or perhaps in proxies.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
