On Thu, Jan 19, 2012 at 10:57 AM, Felix Kuperjans <[email protected]> wrote: > AFAIK, link-local addresses shall not be used for usual services like > HTTP. They are only for neighbour discovery, local multicasts (all local > NTP servers, all local DHCP servers, and so on) or pinging.
In a well-maintained network, use of link-local addresses for global-scope services may very well be a bad idea. However, that's very much in the realm of possibility, and different network management policies will employ the different tools differently. It's not a decided issue. IPv6 link-local addresses are there, and fully support TCP, UDP and any other packet type you might care to drop on top of an IP packet. Core libraries support them just fine, applications and libraries should avoid breaking them. > > It is possible (by specifying %interface) to access them, but this > remains unimplemented in most programs, as it is not usual / advisable > to use them this way. As with ULA addresses or RFC1918 addresses, you shouldn't put them in globally-visible DNS, certainly. > > I think your intention was probably to do some local testing in a LAN, > IPv6 offers two working possibilities: > > * Usage of site-local addresses: For simple local testing, you could > assign (usually statically) site-local addresses. These are not routed > to the internet, but are not local to a single interface, and therefore > routed as usual IPv6 unicast traffic. However, this method has be > declared as obsolete and should not be used any more, but it still works > in all implementations I've seen. Not sure what the deprecation state is of ULA addresses, but it's my understanding they're a more recent development than "site-local". > > * The "real" way for addresses within a LAN is to assign globally unique > addresses. In IPv6, this usually works this way: The ISP assigns a /64 > subnet to your local router, who propagates this subnet via router > advertisements as the local network prefix. An ISP should assign at *least* a /64, but it's not strictly necessary. If they're ignorant, mean or have a bad upstream, they could choose to assign only, e.g. a /112, and force your router to employ something like ULA (or even LL nat (*shudder*)) or DHCPv6 in order to supply your local network. A decent ISP, IMNSHO, would route you at least a /56 or /48, which your router could then divide into /64s for your local network. > All computers in the network > choose their address within this subnet, either statically (default) or > randomly (privacy extensions). With router announcements, yes. You can also use DHCPv6. I very much prefer RAs myself, but there's currently limited support for DNS configuration that way. > It is then possible, that those addresses > can be used world-wide, in order to isolate machines within your > network, AFAIK the advised way is to set up a proper firewall on your > router (or local machine), denying world wide access. That's definitely the preferred way to set things up, as it's by far the most flexible. > > However, the world of IPv6 changed a lot and many things got obsoleted / > extended, it's sometimes hard to find documentation about the really > advised newest way of doing things... In addition, there's of course > lots of criticism, especially about privacy or security. IPv6 is a massive thing, with an incredible amount of flexibility in how it's employed and deployed. Nothing prevents an operator of an IPv6 network from making it look very much like their RFC1918 IPv4 network, and still have most things work. There's a huge difference between "what will work best" and "yes, you can squeak by that way if you choose to." Regardless, there will be environments where an added layer of indirection such as NAT66 or masq, is an appropriate onion-layer of security, and there will be environments where it won't. IMO, with appropriate baseline firewalls, the environments where NAT is appropriate will be niche and relatively rare. Still, it's going to take a long time before network administrators grow comfortable with the relative openness of IPv6 addressing, and some curmudgeons will never grow comfortable with it. (Then again, some of us curmudgeons prefer to spend most of our time in a text terminal.) > > I used to try out site-local addresses first btw, despite they were > already obsoleted some time ago. > > Regards, > Felix > > Am 19.01.2012 16:25, schrieb Michael Mol: >> Grant Edwards wrote: >>> How do you specify a link-local ipv6 address in /etc/hosts? >>> >>> For example, I can ping/telnet/ssh to fe80::02c0:4eff:fe07:0005%eth1, >>> but I can't figure out how to put that address in /etc/hosts so I can >>> access it by name. >> Tried several different approaches, can't get any of them to work. I >> don't know where the bug is, though. >> >> I did find that if I leave off the %iface in /etc/hosts, I get an >> "invalid argument" error from ping6. I suspect there's a bug in ping6. >> Working directly and extensively with link-local interfaces is *bound* >> to reveal a bunch of bugs, because that's not intended SOP in IPv6, you >> have to be more aware of which link scope you're talking to, and I doubt >> most developers take it into account. >> >>> Similarly, how do you enter an ipv6 link-local address in Firefox or >>> Opera? curl seems to accept such an address and return the proper web >>> page, but I can't find any interactive browser (graphical or >>> command-line) that will accept a link-local address. So far I've >>> tried Firefox Opera w3m links. According to RFC2732 it looks like the >>> format should be >>> >>> http://[fe80::02c0:4eff:fe07:0005%eth1]:80/ >>> >>> But none of the browsers accept that. >> That's probably a bug in each browser. >> >> > -- :wq
