Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

Fri Dec 30 12:09:50 UTC 2011

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 at 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/