1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f.
Some higher layer protocols embed IP addresses into their data.
These points make changing IP so difficult.
In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.
Thakfully, site local was deprecated.
Thanks,
Jakob.
In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.
AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
try to figure something out, a coincidence that this is in reply to Jakob
from Cisco but is based on what he wrote) relies on Link Local addresses.
I didn't understand why link locals should be there in the first place
seemed klugey and have googled, looked at rfcs and tried to understand why
link local addresses were baked into V6. The only thing I found was that it
enabled interfaces on point to point links to be unaddressed in V6. (To
save address space!??) Can anyone point me in a direction to understand the
reasoning for link local addressing?
dennis
Because there are a lot of corner cases where you may want to talk to the
network before you find out what your network address is. And if it's a
stand-alone network, it may not *have* a well-define network prefix to use
for SLAAC auto-config addressing.
Think about all the places in IPv4 where you toss packets on the net with your
MAC address or a bogus placeholder IP address because you don't have an IP
address yet (ARP, DHCP for starters). Link-Local is basically the same thing
in the IPv6 world.
So you can print whilst your Internet connection is down. IPv6 allowed
people to rethink IPv4 assumptions, and they realised that a lot of IPv4
things were hacks to work around a lack of functionality in the protocol.
NAT has polluted peoples minds when it comes to the distinctions between
local and global addressing.
Why would you use a global address, with an extra code check to make sure
it is on a directly attached interface, to point a route at? "Router 2 on
interface B" makes more sense to me than "Router with global address 12345"
in this context.
I would also have loved it if the all-routers-anycast thing had been better
defined rather than deprecated. One of the potential default behaviours
could have been fe80:: as a default gateway on every segment, with a
logical meaning of "All upstream routers on this interface".
- Mike
EZIP has no transition strategy and is not backwards compatible with IPv4. The scheme is unworkable.
It is not possible to dual stack EZIP because it pretends to be IPv4.
The author of EZIP should demonstrate a working prototype. We need to see a setup with two clients on a shared external IP address. Then demonstrate that the clients can access an EZIP enabled site and also that the clients can access unmodified IPv4 sites such as Google.com and Facebook.com.
The later test will fail and there is no fix. EZIP requires a big bang transition where the whole world implements EZIP on the same day.
EZIP embeds extra address information in IP option headers. The remote site needs to take that extra address information and send back in the replies. The remote site needs to read the extra "source EZIP" option header and put that as an "destination EZIP" option header on reply packets. Legacy IPv4 sites do not know the meaning the extra option headers and can not do send them back. Packets will arrive at the EZIP gateway without option headers. The EZIP gateway will have no option other than to drop the packets, because without option headers nothing will differentiate the multiple clients behind the gateway.
The EZIP gateway could fall back to NAT when the remote site does not have EZIP support. However no method is provided that can tell the EZIP gateway wether the remote has EZIP support or not. Since the EZIP gateway works on the IP level, we can not use some DNS tricks like NAT64/DNS64.
Regards,
Baldur
Many features of IPv6 depends on link local. Take a look at the routing table of your computer - you will find that most routes have a next hop with a link local address. Many buildin protocols, such as RA and DHCPv6, use link local to communicate without depending on any configuration.
Many protocols with automatic discovery will use link local - why would you want your printer or local NAS server to use a public IP when link local works? In fact, you may prefer the printer to be only on link local so it can not be accessed from outside. The public IP is something your ISP assigns to you, so using that unnecessary only makes your setup vulnerable to problems if the internet is down. You could assign an ULA prefix https://en.wikipedia.org/wiki/Unique_local_address for your network but most people wont.
Regards,
Baldur