Short version:
I am opposed to any host-based solution to the
routing and scaling problem - for reasons mentioned
in recent messages. Below is a fictitious
document for a routing scaling solution which
I hope will remain fictitious:
RACHH - Routing and Addressing Changes Handled in Hosts
Folks who want to pursue this approach might like
to consider how they will convince the vast
majority of:
OS programmers x,000
Application programmers x0,000
ISPs x0,000
End-users x00,000,000
to spend time and money on implementing the
host-based scheme (and the shift to IPv6). Until
all (or almost all) of these people act to adopt
the new scheme, we will all remain dependent on
IPv4 - or IPv6 without a scalable routing.
None of these people will derive any direct benefit
from their efforts until virtually everyone all of
them - including almost all of the end-users - has
adopted RACHH etc. fully.
In contrast, with a good router-based core-edge
separation scheme, such as Ivip, LISP etc, early
adoptors gain direct and immediate benefits,
irrespective of how many other people have adopted it,
in the form of portable, multihomable, address space
at lower costs and without BGP involvement than would
otherwise be possible.
Skip to the end - Q32 - for a summary.
Assuming for the moment we decide on a host-based solution, here's a
rough draft of how we might want to bring a public relations company
team up to speed with the challenges of developing a successful campaign.
- Robin
Team,
Here is our first draft of the key elements of the RACHH campaign - a
brief pep-talk followed by a longer FAQ. As you can see, we have
drawn a blank at certain points - so we look forward to your creative
suggestions!
{Main announcement / pep-talk}
RACHH - The Internet is Changing for the Better
-----------------------------------------------
The Internet has grown from being a small research network in the
1980s to today's global digital network - with billions of users
depending on it daily for their personal and business
communications.
To ensure the Net continues to function reliably, as more and
more people use it more and more intensively, we will need to
change the way the Internet works. The I**F has determined that
in the next few years, all Internet users will need to upgrade
the operating systems and application programs on all their
Internet-connected computers to a new standard of performance:
RACHH - Routing and Addressing Changes Handled in Hosts
"Host" is the name for an Internet connected computer, such as
a desktop computer, cellphone or server.
We will also need to change our Internet connections to
a RACHH-compatible service. This will happen automatically
as ISPs adopt the new system, but this will often require
a new DSL or cable modem - or a new cellphone.
RACHH application programs will perform just like they do
now. Once the transition is complete, all Internet activities
will be as easy as they are now, and some may be easier.
Best of all, the Net will have a secure and robust future
for decades to come - serving us all reliably as we use it for
voice, video and many other purposes, as well as for Web-surfing,
IM and email.
{Team: the FAQ is where it gets tricky. How can we shorten this and
make people happy with the first few answers, rather than asking
more and more questions?}
The RACHH FAQ
-------------
Q1 What is the I**F?
A The I**F designs many of the Internet protocols and works
with other bodies to coordinate IP addresses and the Domain
Name System (DNS). Anyone can join the IETF and participate
in devising new protocols.
Q2 What is an "Internet protocol"?
A A clearly specified set of rules by which two or more
Internet connected computers can communicate. For instance
the HTTP protocol is used by browsers to request pages from
web servers. A DSL modem uses several protocols to set up
the Internet connection with your ISP and to carry the data
back and forth over the phone line.
Q3 Who else creates these protocols?
A Many companies and individuals create protocols in addition
to the I**F's - such as protocols for instant messenger
programs, games, streaming sound and video, peer-to-peer file
sharing.
Q4 Can the I**F force anyone to change their software? If not,
why should I take any notice of them?
A The I**F doesn't control the Internet - no one organisation
does. The Internet is made up of the ISPs and end-users who
connect together to form the global network. However, the
basic protocols and addressing system which makes all this
work have been devised and is administered by the I**F and
associated organisations.
The I**F can't force anyone to use the Internet or not, or
to change how they use it.
{Team: we need some help on the next para.}
If ISPs and end-users do not follow the I**F's advice to
change to the new RACHH Internet, then the Internet will
become progressively more expensive to run and less reliable.
Furthermore, more and more end-users who need "multihoming" -
a reliable connection via two or more ISPs - will continue
to be unable to obtain this.
Q5 So the I**F is telling my ISP, all other ISPs, me and
all other users that we need to change our operating systems,
probably our modems and change to new RACHH-compatible
versions of all the programs we use, in order that the
Internet can keep functioning?
A Yes. The I**F has determined that this is the best solution
to the scaling problems of the Internet.
Q6 Why doesn't the I**F change the Internet so it keeps working
without me or my ISP having to spend money and fuss around
with complex technical things? I have enough trouble keeping
my computer working and safe from viruses as it is!
A
{Team?? This is where we need your expertise. All our
answers to this are highly technical and will just
bamboozle most users.}
Q7 What are the Internet's "scaling problems"?
A The first and best-known problem is that the currently
widely used Internet (IPv4) does not have enough IP
addresses to cope with the growing number of people
using it. There are about 3.7 billion IP addresses,
and supplies of fresh space - like farmland to be
turned into suburbs - have dried up. Although
only a fraction of these addresses are actually used
the current approaches to utilising IPv4 addresses
can't do much better. So we need another Internet
to replace the IPv4 Internet - the IPv6 Internet.
The IPv6 Internet has about 200 billion, billion,
billion, billion IP addresses.
The other problem is "the routing scaling problem".
It concerns the "routers" in the core of the Internet -
whether it is IPv4 or IPv6. These are like post-office
sorting rooms - sending packets out one link or another,
depending on each packet's destination IP address.
Many end-user networks, from universities and
corporations to small offices and home users want or
need highly reliable connections, and to be able to
choose another ISP without having to change all the IP
addresses of the computers and other devices in their
networks.
Without RACHH (or without major changes to the routing
system which the I**F has decided against), the only way
each such end-user network can multihome their network is
by all the hundreds of thousands of routers in the "core" of
the Net having to know about that network, and how it
connects to the Net via one ISP or another. This
information can change from moment-to-moment, and
collectively the burden of all this information and updates
about these connections is too much for the core routers.
Unless we do something - and the I**F has decided that
RACHH is the best approach - the routers would need to
be more and more expensive and the stability of the
entire Internet is threatened by the volume and complexity
of this information.
These routers are purchased and operated by ISPs, so the
cost of running the core of the Internet is borne by
all Internet users.
Q8 OK - I understand the address shortage problem, but how
bad is it really? We have already had knowledgeable people
crying wolf over Y2K - and I have been reading about
the IPv4 address shortage and the need for IPv6 since
about then. Yet the Internet still seems to work and many
big companies are planning much more intensive uses for it,
such as downloading entire DVD's worth of video for a few
dollars.
Doesn't the Internet work fine now? Can't everyone use IP
addresses more efficiently? Can't we share IP addresses?
I can connect as many PCs as I like to my DSL modem and
they all work fine - so what is the problem?
A
{Team - we are working on the answers to these questions.}
Q9 Waddya mean the "IPv4 Internet" and the "IPv6 Internet"???
A All Internet users today use the IPv4 Internet, though
a few also use the IPv6 Internet too. IPv6 was devised
in the mid-1990s and has been available since then, but
has not been adopted by most users, mainly because it
doesn't provide access to anything which cannot already
be accessed via IPv4.
The IPv4 and IPv6 Internets are two separate networks,
even though they can run together over the same routers
and links. For instance both IPv4 and IPv6 packets can be
sent along a DSL link at the same time, and computers with
suitable operating systems and applications can work with
both types of packet at the same time.
To operate on either Internet, the computer needs one
or more IP addresses within the address space of that
Internet. Due largely to the IPv4 address shortage, each
DSL customer gets one IP address and special Network Address
Translation (NAT) software in the DSL modem creates a private
address space for all the connected PCs. The NAT software
and translates the source and destination addresses of
packets going to and from the rest of the Internet so all the
packets from the local computers go out with their
destination address being the one IP address.
The NAT software keeps a track of this is (usually) able to
figure out which local computer to send a packet to, when
response packets arrive from the Net. This means the local
computers cannot be seen from the outside world - so no
external computer can initiate a session with them. (There
is a way around this, with the NAT software providing
a direct "port" to the outside world, so that a
peer-to-peer program, for instance, can accept
communications initiated by such programs on other
computers all over the world.)
IPv6 has so much address space that there is no need
for NAT - though it is possible that some people may
use it for security reasons. NAT is a problem for many
applications, because it is difficult or impossible for
computers on private addresses to communicate with other
computers on private addresses. There are techniques
to help with this, but they don't work very well.
There is no way of sending a packet from an IPv4 address
to an IPv6 address or vice-versa. IPv4 packets only have
32 bits for the destination address and IPv6 addresses are
128 bits long.
A single host computer, such as a web server, can have
both an IPv4 and an IPv6 address - so it is available on
both the IPv4 and the IPv6 Internet, but these are
still two separate Internets. Some protocols can be
made to work between computers which are not on the same
Internets - such as the email protocols and a few others.
Apart from that, IPv4 and IPv6 are two separate Internets.
Q10 So what is the RACHH Internet?
A RACHH is the IPv6 Internet, with new capabilities built
into the operating systems and application programs
of all connected computers.
When all, or almost all, users are using RACHH exclusively
then there will be no problem with address shortages (since
all RACHH users will be using IPv6) and there will be no
routing scaling problem, because the RACHH capabilities in
each "host" computer (each end-user's computer) means the
routing system can continue to operate as it does today,
but without having to be concerned with large numbers of
end-user networks having their own address space. This
means the routing system only needs to know about ISP
networks - which is practical and desirable.
Q11 So the I**F has decided that it is better to upgrade all
the Internet's computers - all their operating systems
and their applications - rather than alter the routing
system?
A Yes.
Q12 What if only a tenth, a half or nine tenths of ISPs and
end-users adopt RACHH? Won't there still be a scaling
problem and IPv4 address shortages? Won't all end-users
and ISPs need to maintain IPv4 connections and applications
to keep in touch with the end-users who haven't upgraded
yet?
A If a large majority of ISPs and end-users convert to
RACHH, then the routing scaling problem and address
shortage problems will be greatly diminished. However
they will not be diminished to any meaningful extent
if half or less of the ISPs and end-users adopt RACHH.
Q14 By upgrading my Internet service, my operating system and
my applications to RACHH, will I be able to do anything,
or access any service, website etc. which I can't access
already?
A No.
Q13 How will my RACHH upgraded computer work with computers
which are not upgraded?
A Operating systems and applications which are upgraded
to RACHH work fine communicating with other hosts
which are still using IPv4 - or IPv6 without RACHH.
However, in order for many of these programs to work
with those non-upgraded hosts, you will still need
an IPv4 address and service from your ISP. Also,
those applications which assume stable IP addresses
will need to be upgraded to work with RACHH. This
will sometimes means that their protocols will need
to be changed, so the RACHH mode of operation will
not be compatible with the pre-RACHH mode. (The
pre-RACHH mode will generally be IPv4 only, and
RACHH mode is purely IPv6 - a similar problem would
occur simply due to making the application work
only from IPv6.)
If you are using your RACHH-upgraded computer on an
end-user network which is multihomed (using two or
more ISPs for real-time switching and continued
session connectivity if one ISP fails) then the
multihoming will only work for sessions with other
computers which are also upgraded to RACHH and
where the session is with an application program
there which is also upgraded to RACHH.
Q14 So - assuming everyone needs to maintain an Internet service
which gives them full connectivity to all other users'
computers - no-one can do without their IPv4 service until
almost everyone has RACHH, or at least IPv6?
A That is correct.
Q15 It has taken me ten minutes to read and understand this
FAQ so far. Why should I keep reading? Why should I be
the first one to adopt RACHH, IPv6 etc. Wouldn't it
be easier and more prudent to wait until most other people
have adopted it before I do so?
A
{Team??}
Q16 What about old applications, old games, etc. which only
work for IPv4 and are not being maintained? Likewise,
I have printers and Wi-Fi gear which only works with
IPv4.
A Those old applications can't be upgraded. They will
still work with a RACHH-upgraded operating system, but
you will need an IPv4 connection to use them.
Since the RACHH upgraded applications works only over
IPv6, you will need new Wi-Fi gear if it does not
already support IPv6. IPv6 compatible Wi-Fi gear itself
does not need to be upgraded to handle RACHH traffic,
but its management interface software should, ideally,
be RACHH compatible.
Q17 Where is a list of major end-users, universities, corporations
etc. - or people like me in my home or SOHO setting - who have
upgraded their systems properly to RACHH.
A
{Team - this won't be possible at first.}
Q18 Where are the RACHH compatible operating systems and
applications? I have never heard of them?
A
{Team - this won't be possible at first either. We
need to convince all the operating system suppliers
and at least some of the major application suppliers
to adopt RACHH before we can try to convince end-users
to adopt it - though to some extent RACHH adoption will
occur via automatic updates and the installation of
new operating systems and applications. However, in order
to do this, we need to show the programmers we have a
credible campaign to get end-users to recognise and adopt
RACHH-upgraded software.}
Q19 So worldwide adoption of IPv6 alone is sufficient to solve
the IPv4 address shortage, but RACHH is required on top of
this to solve the routing scaling problem too?
A Yes.
Q20 Is it an essential part of RACHH's solution to the routing
scaling problem that no end-user host can have a stable IP
address - and that multihoming must be done by each host having
two or more IP addresses from two or more ISPs?
A Yes.
Q21 Wasn't the big attraction of IPv6 that everyone could have
their own IP address space, because there was so much
available?
A Not really - IPv6 was never intended to provide this, because
it has been known since the early 1990s that the routing
system in its form then (and as we are maintaining it now
and into the future) could not scale to so many end-user
networks having their own PI address space.
Q22 OK - but didn't the RIRs all decide in 2007 and 2008 to give
end-user networks PI IPv6 space if they asked for it?
(Not that many took up the offer...)
A Yes, because hardly anyone was adopting it and this was
seen as the only way of making any progress away from
IPv4 dependence. There was no scalable routing solution
then - although SHIM6 was promised for many years.
Now, once most networks are using RACHH, there won't
be any need for those IPv6 PI assignments.
Q23 Isn't RACHH like SHIM6 - which no-one really wanted?
A SHIM6 didn't require a new API or rewritten apps.
RACHH does, and when applications are rewritten,
including to avoid all assumptions about stability
of IP addresses, the system will really work.
Like SHIM6, RACHH is a host-based solution to
multihoming, for IPv6 only, in which benefits only
accrue to adoptors when their host is communicating
with another upgraded host.
Q24 I am a network operator. How am I supposed to keep control
of my routers, servers etc. when they are on shifting
sands of having two or more sets of addresses, one for each
upstream ISP, and I need to add or delete one of these
sets of addresses?
A Put your routers on stable private addresses and use the
tools the I**F is developing. See the answer to Q29
regarding Access Control Lists.
Q25 I am a network operator. With current BGP-based mulithoming
the network itself is untouched - all the hosts have their
IP addresses remaining stable. I pull some router levers
to switch from one upstream ISP to another - or program the
router to do this automatically when needed.
I don't need to know or care about how many hosts are in my
network, or what OS or applications they are running.
With RACHH, how can I know all hosts in my network are RACHH
capable - such as if someone plugs in a laptop, or uses it
a laptop or some VoIP handset with the corporate WLAN?
A RACHH will only work as expected for hosts which fully
implement RACHH.
{Team: the rest of the FAQ is for programmers, not the general
public. We are working on this section ourselves, but if
you have any suggestions...... especially regarding Q31 & Q32.}
Q25 I am an application developer. Are you saying that I need
to rewrite my entire application to work with two networking
APIs?
A Yes. It will probably be best to select at runtime whether
your app uses the RACHH or the old API, according to
whether the OS has a RACHH API.
The RACHH API enables you to do most things you currently
do in IPv4 or IPv6. You could use both APIs at the same
time - for instance the old API for IPv4 hosts and the
RACHH API for all IPv6 hosts.
Q26 OK - that sounds nutty, but let me just check:
1 - The app needs to work fine when the RACHH API is not
available - to IPv4 hosts and, if it is running on an
IPv6 host (which it isn't at present, since it assumes
IPv4 and I haven't ported it yet), to IPv6 hosts and to
IPv6 hosts with RACHH OSes and apps.
2 - The app needs to work fine with the RACHH API instead
of the current one, which involves a completely different
set of calls, new ways of thinking about IP addresses
etc. when the app is dealing with a mixture of other
computers, on IPv4 and on IPv6 with and without RACHH.
This sounds like a debugging and user-support nightmare.
I may also need to fundamentally redesign my protocol, which
means it will be impossible to retain backward compatibility
with pre-RACHH IPv6 versions of my software. Compatibility
isn't possible anyway between IPv4 and IPv6, which is a major
reason why I haven't tried to rewrite it to run on IPv6
already.
A Yes, you will need to completely re-engineer how your
app works if any part of it is concerned with IP
addresses. In RACHH, you only use hostnames, and the
OS handles the rest. However, as noted below (Q29),
to the extent that your app contains its own ACK
systems, you will need the app to tell the OS if it
looks like a packet has not been acknowledged.
Also, the RACHH version of your app can never use IP
addresses in referrals.
Q27 So everything depends on DNS? A new kind of DNS where
the hostname query typically returns multiple IP addresses
for the OS to use, with a list of priorities and the OS
does its own reachability testing and probing of alternative
IP addresses if it looks like sending one or more packets to
the currently preferred IP address did not produce a response?
A Yes, everything depends on DNS and the RACHH OS functions -
except of course the DNS itself, which will remain rooted
with a handful of fixed IP addresses. IP addresses can
be expressed as hostnames so your app can still send
packets to explicit addresses - but you generally won't
want to do this, because that is the old sort of programming
which can't be supported by RACHH's host-based multihoming.
Q28 What about caching times? How can the DNS operate so as
to stop me having to check every ten seconds, if I need
ten second multihoming recovery time?
A The RACHH OS does all the reachability testing. It needs
to sense whether sending a packet to an IP address really
worked. Sometimes, it will receive an ICMP message if
that address was unreachable. But to be more robust,
your app needs to tell the OS when it suspects a packet
was not received successfully, so the OS should try to
send it again. This won't work at all if your app uses
UDP and the protocol has no ACK system. TCP will be
fine - the OS will detect lack of ACKs and will attempt
another address.
However, you your app and its protocols will need to
be rewritten if they ever pass IP addresses between
hosts, or store IP addresses for later use. To ensure
your app works with RACHH host-based multihoming,
you must always identify each host by its hostname alone.
This means that all hosts you communicate with will need
their own hostname in the DNS.
It also means your app will need to cope with a host
on private address space, which has its own hostname
there, but which accesses the Net via NAT (ideally this
would not be the case, but it may happen), and so
the packets from this host actually arrive from an
IP address which is different from any of the
addresses returned when the DNS is queried with the other
host's hostname. We are still working on how the RACHH OS
and applications will handle this.
Q29 I am an application developer and/or someone who is involved
in mobile devices, including ultra-low-power battery operated
wireless embedded devices. I understand RACHH involves hosts
sending hostnames to each others, initially at least, and
in a much greater real-time dependence on the DNS.
Hostnames are variable length fields - and are potentially
very long. Also, there are some complexities with non-ASCII
domain names, with Punycode etc. which sound like a nightmare
to program.
It looks tricky to implement an ACL with RACHH. Wouldn't
the device need to do regular DNS lookups to find the current
IP addresses of the allowed (or excluded) hosts and networks?
Thus, an ACL entry would involve the text name of a host
or network, with some mechanism to look this up in DNS,
convert it into an IP address or subnet address and prefix
length. Then there would need to be frequent, repetitive,
DNS lookups, and/or some interaction with the RACHH code if it
decides the host or network has a new address now . . .
Also, with RACHH multihoming, a host might have any number
of potential IP addresses and a network could have any
number of prefixes and prefix length pairs. This sounds
like it would be onerous to program. Variable numbers of
IP addresses, constant DNS checking to update them according
to the primary definition of the ACL entry, which is in the
form of a text string, of arbitrary length, in ASCII or in
some other format.
I also understand that a failure to receive an ACK (at the TCP
or application layer) will need to be treated as evidence that
the remote host is now unreachable by the current IP address.
I understand this will involve the OS in sending the same
packet to another IP address, complete with hostname and
probably some nonce or other crypto stuff (won't that make
the packet longer, raising MTU and PMTUD problems?), so the
session can continue. I am not sure how the applications at
both ends are supposed to cope with these retransmissions and
potentially duplicate receptions. Will there be an option
for not resending time-sensitive packets?
Whatever the answer to these questions, doesn't this mean
that:
1 - There will be more traffic on the mobile link, taking
more time and chewing more battery power?
2 - A more complex stack will be required, with more
storage and perhaps crypto stuff?
3 - The flaky, slow and long-latency nature of wireless will
slow down DNS requests and responses and contribute to
false alarms about the other host not being reachable,
particularly when my protocol involves previously
lightweight UDP packets?
A Yes, all this is true.
UDP can't be lightweight in any host-based multihoming
system such as RACHH while still retaining current
assumptions about IP address stability.
Q30 How does RACHH work with a hosting company changing one
or more of the IP addresses a web-server works on? That
server may be mentioned in the DNSes of several dozen
customers. How can those customers securely allow this
particular entry in their DNS to be updated by the
hosting company at any time?
A This is administratively and technically complex,
but possible.
Q31 I am an operating system developer and I like to think I know
something about the Internet's routing system. Why did the I**F
decide to keep the current routing system architecture untouched
and instead create a bunch of host-based protocols to be added
to the responsibilities of hosts?
A Because we decided firstly that the scaling problem couldn't
be solved with any upgrade to BGP, or any single alternative
to BGP - even if a way could be found to introduce an
alternative without disruption.
Secondly, we decided on a host-based solution because:
1 - We didn't like the idea of adding a new architectural
structure to the interdomain routing, such as was
proposed in the core-edge separation schemes of LISP, APT,
Ivip, TRRP and Six/One Router.
2 - We thought that the current assumptions that a host could
assume its IP address was stable, and that the hosts it
is communicating with would likewise have stable addresses
- at least for the current session - was unreasonable.
This assumption developed over the years in an ad-hoc
fashion when there was no scaling problem. We decided
it was a mistake to consider any host (apart from the root
DNS servers) should have a stable IP address.
3 - It fits well with the tradition of "smart host - dumb
network".
Q32 So how is this any different from:
* The I**F being averse to sullying the supposedly "pure"
architecture of the routing system,
* regarding end-users as being uppity for thinking they
could have their own IP addresses (despite the vast
supply in IPv6),
* therefore deciding to punt the responsibility for
handling long-term and short-term changes in the
routing system from the routing system itself, all
the way to the host operating system - with:
# consequently increased network related management
traffic to and from each host,
# a greater number of potential combinations of
OS, app and circumstances at each end, making
for a greater number of potential failure conditions
and - at least from the network manager's point of
view - greater difficulty monitoring and debugging
multihoming etc.,
# more storage in the host etc
# the need to develop a new API and to force all
applications to be rewritten for the API, and to be
redesigned to the extent that they previously made
any direct use of IP addresses, or assumed that IP
addresses resulting from conventional DNS lookups
could be regarded as stable?
A
{Team??}
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
