Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Drumming Up More Internet Addresses



[ Consolidating a couple of people. ]

> 4.3 billion addresses... how many are being squatted on due to assignment of
> huge swaths to major organizations...

> It would help if some folks like AT&T, MIT, etc (if they already
> haven't) would give back their class A so it could be parceled out to
> the 'common folks'.

    It really wouldn't matter that much.  MIT's entire /8 is 2.5 weeks
of extra life for the free pool at current allocation rates (we
allocated 20 /8's last year).

    The writing has been on the wall for IPv4 for some time.  4.3
billion is nowhere near large enough to number a planet's worth of
networking.  Africa doesn't have a starbucks with wifi on every other
corner yet.

> I used CTRL-F to search for "routing" and "complex" ... nothing in there
> about just how difficult routing IPv6 addresses will be... what a nightmare
> that will be...

    Depends on what you mean.  96 more bits, no magic.  RIP, OSPF, BGP
work like they always have.

    It is the case that internet core routing has a scaling problem,
ipv6 does nothing to address it, and one of the things that's kept it
under control is prefix scarcity.  IPv6 has enabled some experiments
on this problem (e.g. enough addressing to differntiate between
topology location and host identification), but no clear consensus.

> I'm imaging a transition like that of analog to digital TV... people who are
> behind the times, so to speak, will receive a "converter box" which will
> provide NAT... the rest will be forced to potentially endure a reboot or two
> on a few devices :)

    While there are a number of NAT flavors going every which way,
there are technical land mines throughout.  E.g. the original NYT
article does not work from t-mobile's IPv6 beta, because it embeds
IPv4 literals in some URLs, breaking the NAT64 gatewaying it's built
on.

    Transition is going to be interesting, as another poster said.  In
the chinese sense.

> In IPV6, I think it is the 00ffxxyyxxyy ip addresses (hex here) is
> really a gateway to the IPV4 address space where the xxyyxxyy is the
> hex version of the IPV4 addresses. So all IPV4 folks are not out of
> the water just yet. .... Just a fun fact I heard at a non-BLU LUG
> group.

    I assume you mean the ::ffff:192.0.2.1 (== ::ffff:c000:0201)
syntax.  It's so apps can open a single IPv6 socket, and use both v4
and v6 over the socket.  It doesn't extend past that in any useful
way.  It won't help your v6 only box speak to v4 hosts, isn't useful
as a v6 address for yourself, etc.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org