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: Fri, 30 Dec 2011 07:09:50 -0500

Well, it seems now you've also added the requirement that we also
dramatically re-write all software that makes use of networking.
Seemingly for the sake of never admitting that you can be wrong.

You seem to think that the OSI model is this nice and clean model that
cleanly separates everything and that you can just freely replace
chunks of it.  That was the idea; but in practice, there is a lot more
grey area, and dependencies.  Again, it's like you live in a
theoretical world where physical limitations and operational realities
don't exist.

Honestly.

Here is a thought:

Go off and write up the RFCs to make this all work, and come back when
you have an model implementation we can all look at.

I think that would be a win-win for everyone.

I normally don't try to dismiss people completely, but you're
exhausting.  You never directly respond to anything except with a one
line assertion like "not at all," or by changing the parameters of the
argument to a model that doesn't exist.

I could do that too:

It can be assumed that default free routing table is small.

Yes, I agree completely.  The default free routing table must have one
route: a default route.

See how frustrating that is?




On Fri, Dec 30, 2011 at 4:49 AM, Masataka Ohta
<mohta () necom830 hpcl titech ac jp> wrote:
Ray Soucy wrote:

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


Multihoming by routing, by the intermediate systems, is against
the end to end principle, which is why it does not scale.


The remote host would
have no knowledge of other available prefixes


As IP layer is connectionless, let transport or application
layer carry the information on the prefixes to try to keep
connections.


(even if there is a path

change, and a different path becomes favorable).


The remote host can use IGP metric to know the initial best
candidate and subsequent path changes.

It can be assumed that default free routing table is small.

In addition, the remote host may also use transport/application
layer timeout to try other prefixes.


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


Not at all.

Transport/application timeout is no different.

Route propagation is no slower. Instead, smaller default free
routing table means more rapid convergence.


This all would be significantly more complex than IPv6


It was IPv6 which was expected to support multiple addresses
to suppress routing table growth. The result is a complex
protocol with halfhearted support for multiple addresses.


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.


Unlike IPv4, IPv6 is poorly operational and still needs protocol
modifications,

For example, multicast PMTUD causes ICMP implosion, which means
rational operators filter ICMP packet too big often including
those against unicast packets, which means PMTUD won't work.

Yes, fixing it requires more than a decade.

Then, it may be a good idea to obsolete SLAAC, which means
IPv6 address can be only 8B long. You know, remembering 16B
addresses is divine, which is an operational head ache.


To be frank, you would have to build a completely new and
parallel network and hope you could somehow convince people to adopt
it


Multihoming with multiple addresses works at transport/application
layer over existing IPv4 and IPv6.

                                               Masataka Ohta


-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


  By Date           By Thread  

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