...when we're starting to deploy yet another IPv6-only technology :)
Hello all,
as a fairly large ISP (for Greek standards at least), we've been
affected by IPv4 exhaustion for quite some time now. A few years back we
gave LW4o6 a go, as documented here
https://ripe76.ripe.net/presentations/11-lw4o6-deployment-as6799.pdf .
In the end, it did not work out very well. Quoting myself (from v6ops
mailing list), the reasons behind that were:
"In no particular order:
1. CPE (almost OK after ~2 years and god knows how many iterations)
2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF
3. vendor's reluctance to continue (much needed) dev/ment because of
*lack of interest from other ISPs* "
Please take extra note of (3).
In any case, being the optimists we are, and having supportive mgmt, we
decided (once more) against burying ourselves deeper into CGN. This time
we're going with MAP-E (which incidentally was our first choice), mainly
because we understand it and our MAP BR vendor does too :) .
So, as I already mentioned, we're just about to deploy it commercially.
We've tested with 2 CPE vendors sucessfully and we're just ironing out
some provisioning details before launching. Deployment will be gradual
of course and very very cautious.
Unofficially, we are aware of a couple of similar trials from other ISPs
and we'd love to hear about people who have already deployed such
technologies (IPv6-only with IPv4aas) or are thinking about doing so.
After all, that is exactly what this WG is about :)
thanks for reading,
Yannis
Hi,
after now almost 12 years using, working and teaching[1]
IPv6 I've come to the conclusion that IPv6 is a mistake and will
not work.
Therefore the RIPE IPv6 WG should be disbanded and replaced
with a new WG that MUST investigate all possible solutions to
artificially prolong the live of IPv4 till the day a new successor
for IPv4 is created and implemented!
Some great ideas[2] are already proposed, some of them already
implemented:
- Use of NAT
- Use of the first Class-A network 0.0.0.0[3]
- Use of parts of localhost Class-A network 127.0.0.0
- Use of (parts) of Class-D address space (multicast)
- Use of Class-E address space (future use)
- Using part of the UDP / TCP port range as extension for the
address.
Some of the reserved address spaces could also be used. E.g. nobody
is using 192.0.2.0/24 for documentation anyway.
It should also be investigated to take back legacy IPv4 resources,
although the "owners" of these resources might already selling
them on the open market.
It MUST also be considered not filtering on Class-C[4] bounderies
but going for something smaller like /26 or /27 in the global routing
table. Also new Class Designations for these prefixes MUST be created.
The new successor to IPv4 should not make the same mistakes as IPv6.
- IT MUST have NAT
- It MUST have Classes
- IT MUST have DHCP
- It MUST have ARP
- It should be possible to drop ICMP the same impact as in IPv4. Many
experts I talked to over the years told me that blocking ICMP has
no negative impacts.
- It MUST only have numbers and dots "."
- There should be absolutly no reasons to use "[ ]" in URLs
Probably the best way to proceed is to just add one or two octets to the
address.
One of the reasons for the above is that there are so is so many good
documentation already written about IPv4! And people already know about
IPv4! Why waste this knowledge and experience? There is also plenty of
good software out there that can't work with IPv6[5] Change is bad!
People don't want to learn!
IPv4! MUST! NOT! DIE!
Jens
[1] at least trying to teach, as one can see from the great number of
people actually using IPv6 with little success
[2] https://netdevconf.info/0x13/session.html?talk-ipv4-unicast-expansions
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[4] a Class-C network is the equivalent of an /24. I was told by experts
that the definition of some bit set in the first octet of an IPv4
address is complete and utter nonsense
[5] like a 20 year old shell script that is so important for $university
that it would be hard for them to implement IPv6!
