Home page logo

nanog logo nanog mailing list archives

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
From: Ray Soucy <rps () maine edu>
Date: Thu, 29 Dec 2011 21:18:35 -0500

OK, this is getting ridiculous.
Let's assume that we have a model where host systems receive the
global routing table from service providers.  The stated reason for
this is so that they could make their own routing decisions when
multi-homed environment.  Presumably with each ISP connected to a L2
device; let's say an Ethernet Switch.
So now we have ISP A, B, and let's even add C.  Each are providing all
available routes in the global table, and path information, allowing
the host to make intelligent routing decisions.
Unfortunately, for bi-directional communication, the prefix assigned
to the customer must be provider independent.  It's a residential
service so maybe they have a single 64-bit prefix.  So we now need ISP
A, B, and C to be announcing that prefix.
Congratulations, you have just created a model where every customer
would have their own entry in the global table (since route
summarization and aggregation is now impossible), one that is
exponentially greater than the production IP global table today.
But that is only the case if you let customers have a PI prefix (which
I think is really required in a purist end-to-end model, but for the
sake of argument...).
We could, of course, only provide customers with the global table, and
have each ISP give hosts a different prefix.  This would allow for the
selection of the best path by the host, but once that communication is
established it would be locked into that path.  The remote host would
have no knowledge of other available prefixes (even if there is a path
change, and a different path becomes favorable).  To get around this
we could develop another message that allows a host to announce
alternative addresses to other hosts; which means systems now also
need to keep a table of alternate peer addresses, and have the ability
to quickly detect changes in path availability and quality.
The result is still a very large amount of overhead.  You will still
experience significant change propagation delay (slower than change
propagation under the current model as it would be more complex,
involve exponentially more peers, paths, etc, and be performed on
commodity hardware).
This all would be significantly more complex than IPv6 (which is
already claimed, by the proponents of the beloved end-to-end model, to
be too complex and have too much overhead), it would introduce even
more delay (another complaint) than IPv6 due to that complexity.
Limitations aside.  We now know that it takes well over a decade for
people to move to a protocol, even when it is almost operationally
identical to its predecessor.  Getting buy-in for such a fundamental
shift in how the Internet is build would be almost impossible at this
point.  To be frank, you would have to build a completely new and
parallel network and hope you could somehow convince people to adopt
it (when everything they want works "just fine" on the "old" network).
I honestly can't believe we're even having this discussion.  It's
really bonkers.

2011/12/29 Masataka Ohta <mohta () necom830 hpcl titech ac jp>:
Valdis.Kletnieks () vt edu wrote:

IGP snooping is not necessary if the host have only one next
hop router.

You don't need an IGP either at that point, no matter what some paper from
years ago tries to assert. :)

IGP is the way for routers advertise their existence,
though, in this simplest case, an incomplete proxy of
relying on a default router works correctly.

Beyond that, if there are multiple routers, having a default
router and relying on the default router for forwarding to
other routers and/or supplying ICMP redirects stops working
when the default router, the single point of failure, goes
down, which is the incompleteness and/or incorrectness
predicted by the paper of the end to end argument.

Considering that the reason to have multiple routers
should be for redundancy, there is no point to use
one of them as the default router.

Developing more complicated IGP proxy makes the
incompleteness and the incorrectness not disappear but
more complicated.

                                       Masataka Ohta


Note that the paper was written in 1984, where as RFC791
was written in 1981.

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]