Wildcards in reverse DNS
ccc2716 at vip.cybercity.dk
Sat Jan 6 00:38:47 UTC 2007
There are some benefits from using NAT that have not been discussed yet.
This comment may seem political, but the technology must also enable
solutions to solve those issues.
It has been discussed that there is no need to have any private
namespace with IPv6. Technically that is correct, privacy-wise I do not
necessarily agree. It has also been said that e.g. my next refrigerator
will have internet access and will order new groceries when supply is
low or stuff is getting too old. I don't know about everyone else but in
my house there will be one and only one person with access to my
refrigerator, that person is me; not any store, not any hacker, not any
government health department, not anyone else.
For that reason I will get what amounts to a NAT/firewall with an
effective block against access between my refrigerator and the internet.
A NAT is a very handy thing in that respect, combined with a firewall
that is effective today and probably a long time still.
Now I use a refrigerator as an example, I am sure you can bring up some
example from your future life that you want exclusive access to.
All discussions I have heard so far about the virtues of IPv6 forget the
privacy issue, if there is no path, hacking becomes much harder.
I agree that we need a bigger address space; but the idea that
everything must be reachable from the public internet is plain wrong,
there will be many things that will be better off when not reachable.
Sorry if this is out of line.
Mark Andrews wrote:
>> At 0:24 +1100 1/6/07, Mark Andrews wrote:
>>> NAT is broken by design. It depends upon there being a unique
>>> indentifier in the upper layer protocols to demux the incoming
>>> data stream. No such identifier exist for *all* protocols that
>>> run on top of IPv4.
>> I don't really agree with that. Many protocols were built without
>> unique identifiers, such as DNS, assuming they could rely on IP
>> addresses and port numbers. That could be called "efficient design"
>> and therefore NAT is a malady, or it could be called "a layer
>> violation" that is the reason why NAT makes the protocol stumble.
>> Yes, it is true that NAT causes problems for protocols. But I am not
>> convinced the problem lies with NAT, the cause is at least shared by
>> the protocol designers.
> How could it be the fault of the protocol designer when the
> properties of the network have changed underneath the
> protocol designer. Most of the protocols were written when
> IP addresses in IP header didn't change between source and
> destination. The packets had enough unique information to
> get the responses back to the originator.
> I was really thinking about protocols other than UDP and TCP.
> There are some of them which a node to node not application to
> application so they don't even have a concept like 'port' that
> UDP and TCP have.
>>> Have you run a IPv6 network?
>> I used to but I don't anymore. ;) The IPv6 routing mesh is not
>> resilient enough to be reliable for me. When I set up my first
>> authoritative DNS servers I ran traceroutes from them to the then 4
>> root servers with IPv6 addresses and go through to only 1. I worked
>> on the other 3 until I got to them, for one of the cases, a special
>> tunnel had to be built that was against an ISP's policy for routing
>> to make it work. The tunnel didn't last, it was up for a few months
>> before they decided it was not worth the trouble to maintain. And
>> this was for me, at an "infrastructural institution" to reach a root
>> server. I.e., stuff that should be main-line.
> I rarely have problem today with IPv6 connectivity despite
> my tunnel going into a first generation IPv6 router that
> was a cast off at the remote end. No. it doesn't go directly
> to ISC. It's 10 IPv6 hops vs 14 IPv4 hops between the
> machines I usually work on. The tunnel from my home network
> to the other end if 10 IPv4 hops.
>>> It just works.
>> I hope it will someday. Yes, the protocols work. And there are
>> large pockets of IPv6 working. But it is still immature, at least in
>> my economy. Operationally there are barriers to deployment. Here's
>> a proof by contradiction - if there were no barriers, we wouldn't
>> even be having this discussion.
> No. It's just new for most people so they havn't experienced it.
>> I have no reason to be against IPv6. I have no reason to be for it
>> either. But I am tired of hearing about how "ready it is" now.
>> Don't oversell it, please. Hype causes a bad reputation.
>>> IPv6 is very compatible with IPv4. Just about everything
>>> that works with IPv4 will work with IPv6 provided the
>>> implementations have the socket establishment re-written
>>> to be protocol independent. There are a few exception and
>>> they usually embed IPv4 addresses in the upper layers.
>> Provided everything is "re-written" to me indicates that there isn't
>> compatibility. It's like saying any American can travel easily
>> through China once you learn Chinese. (I.e., learning Chinese for an
>> American is a lot of work, it can be done but it takes a lot of
> No. It mean that if you have legacy code it needs a minor
> re-write. Something that most programers could do in a
>> Again, I am not saying IPv6 is bad. Just don't over sell it. IPv6
>> takes work. Probably the work will payoff - I can't say for sure
>> myself. The fact is that the Internet needs more addresses than IPv4
>> can offer and IPv6 can fill the void. But IPv6 still has routing
>> issues. That's why I can only say "probably" pay off.
> Both IPv4 and IPv6 have routing issues. They are roughly
> the same. However IPv6 was designed to ease the problems
> of renumbering which should, in theory, relieve some of the
> routing issues.
> One of the biggest problem is that people try to apply IPv4
> solutions to IPv6 rather than take advantage of what IPv6
> offers. IPv6 addresses lots of problems identified with
> IPv4, not just the number of addresses.
> NAT is a IPv4 solution to a IPv4 problem. IPv6 eliminates
> the need to do NAT.
>> Edward Lewis +1-571-434-5468
>> Dessert - aka Service Pack 1 for lunch.
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
More information about the bind-users