[no subject]

Another problem with numbering router links is that you need to break up
your address blocks. This is extremely annoying and wasteful.

>       The problem is not everyone today that considers themselves
> a network operator understands all the ramifications of their current
> practices, be they good or bad.

Very true.

>       Going into fantasy-land mode, if IPv6 addresses were instantly
> used by everyone, people could once again obtain ips that could be
> used for internal private use yet remain globally unique, therefore
> allowing tracking back of who is leaking their own internal sources.

Ok, quick question: how do I number my point to point links in IPv6:

1. /64
2. /126
3. /127
4. IP unnumbered
5. just link-local addresses

I hate to say it, but I don't think IPv6 is ready for prime time yet.

> > Making a good list of best practices (and then have people widely
> > implement them) might also go a long way towards showing concerned parties
> > such as the US administration that the network community consists of
> > responsible people that can work together for the common good.

>       I agree here, I personally think that numbering your internal
> links out of 1918 space is not an acceptable solution unless it's
> behind your "natted" network/firewall and does not leak out.

Agree.

>       Perhaps some of those that are the better/brighter out there want
> to start to write up a list of "networking best practices".

I've started with a list of BGP best practices recently. When I think it's
ready I'll post a link. If anyone has anything to contribute before then
(even just (contructive) criticism), mail me off-list.

> > > But if the best reason we can
> > > come up with is ISIS, the IEEE will just keep laughing.

> > Why is the IEEE laughing?

>       The implication is that IEEE will not change the 802.x specs
> to allow larger [default] link-local mtu due to legacy interop
> issues.

So? We don't stick to IEEE 802.3 anyway...

> imagine your circa 1989 ne2000 card attempting to process
> a 4400 byte frame on your local lan.  a lot of the "cheap" ethernet
> cards don't include enough buffering to handle such a large frame
> let alone the legacy issues involved..

4400 bytes on a 1989 card, you are being _very_ optimistic to even take
the trouble of saying that doesn't work. Many of today's cards 100
Mbit cards (and that's not just the $10 ones) can't even handle 1504 bytes
as needed for 802.1q VLAN tags.

I have to side with the IEEE here: simply changing the spec isn't an
option, since none of the 10 Mbps stuff will handle it, very little of the
100 Mbps stuff and not even all of the 1000 Mbps stuff. (I once complained
to a vendor about this. They sent us new GE interfaces. Those did 64k
frames...)

Having a larger than 1500 byte MTU in backbones would be very good,
because then you have some room to work with when adding extra headers. A
good solution for this would be an neighbor MTU discovery protocol. Maybe
ARPv2? Then boxes with different MTUs can live together on the same wire
and doing more than 1500 bytes over an Ethernet-based public exchange
point wouldn't be a problem.