Wildcards in reverse DNS
blueCommand
I'm playing around with my nameserver (BIND9.3.3) and it's IPv6 support.
My reverse is this:
;$ORIGIN .
$TTL 3600 ; 1 hour
@ IN SOA ns1.cmd.nu. dns.cmd.nu. (
2006122211 ; serial
5400 ; refresh (1 hour 30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
IN NS ns1.cmd.nu.
; Out of bounds
$ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
* IN PTR out-of-bounds.ipv6.cmd.nu.
; Beef sub
$ORIGIN f.e.e.b.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR brownie.cmd.nu.
7.b.7.b.2.6.e.f.f.f.9.2.c.0.2.0 IN PTR electron.cmd.nu.
a.6.c.3.3.4.e.f.f.f.9.2.c.0.2.0 IN PTR hermes.cmd.nu.
c.b.6.e.4.5.e.f.f.f.1.8.0.0.e.2 IN PTR thunder.cmd.nu
4.0.9.2.1.e.e.f.f.f.2.2.0.5.2.0 IN PTR mars.cmd.nu
3.3.e.8.f.8.e.f.f.f.3.b.2.0.2.0 IN PTR constella.cmd.nu
* IN PTR not-active.ipv6.cmd.nu.
; Dead sub
$ORIGIN d.a.e.d.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR brownie.cmd.nu.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.cmd.nu.
* IN PTR tunnel.ipv6.cmd.nu.
And my entity in named.conf is like this:
zone "4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa" IN
{
type master;
file "zone/prim/rev-pub";
};
The problem is that it's only the out-of-bounds wildcard that works, even if
I split them to different files and / or move around / remove the oter
wildcards.
I simply can't get any beef sub och dead sub wildcards to work.
Anybody spot anything very wrong with this approch?
Greetings and marry Xmas!
Joseph S D Yao
> Hello!
> I'm playing around with my nameserver (BIND9.3.3) and it's IPv6 support.
>
> My reverse is this:
...
> The problem is that it's only the out-of-bounds wildcard that works, even if
> I split them to different files and / or move around / remove the oter
> wildcards.
> I simply can't get any beef sub och dead sub wildcards to work.
>
> Anybody spot anything very wrong with this approch?
>
> Greetings and marry Xmas!
Merry Christmas back, and a happy new year as well!
> ;$ORIGIN .
It's good that this is commented out - it could mess up the whole file
if it weren't. You do NOT want to declare that your zone file is
authoritative for the root domain! [Unless it is, but it's not.]
> $TTL 3600 ; 1 hour
> @ IN SOA ns1.cmd.nu. dns.cmd.nu. (
> 2006122211 ; serial
> 5400 ; refresh (1 hour 30 minutes)
> 900 ; retry (15 minutes)
> 604800 ; expire (1 week)
> 3600 ; minimum (1 hour)
> )
> IN NS ns1.cmd.nu.
>
> ; Out of bounds
> $ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
> * IN PTR out-of-bounds.ipv6.cmd.nu.
>
> ; Beef sub
> $ORIGIN f.e.e.b.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR brownie.cmd.nu.
> 7.b.7.b.2.6.e.f.f.f.9.2.c.0.2.0 IN PTR electron.cmd.nu.
> a.6.c.3.3.4.e.f.f.f.9.2.c.0.2.0 IN PTR hermes.cmd.nu.
> c.b.6.e.4.5.e.f.f.f.1.8.0.0.e.2 IN PTR thunder.cmd.nu
> 4.0.9.2.1.e.e.f.f.f.2.2.0.5.2.0 IN PTR mars.cmd.nu
> 3.3.e.8.f.8.e.f.f.f.3.b.2.0.2.0 IN PTR constella.cmd.nu
>
> * IN PTR not-active.ipv6.cmd.nu.
You need to explicitly wildcard the subdomains that were used above:
* IN PTR not-active.ipv6.cmd.nu.
*.0 IN PTR not-active.ipv6.cmd.nu.
*.2 IN PTR not-active.ipv6.cmd.nu.
*.0.0 IN PTR not-active.ipv6.cmd.nu.
*.2.0 IN PTR not-active.ipv6.cmd.nu.
*.e.2 IN PTR not-active.ipv6.cmd.nu.
*.0.0.0 IN PTR not-active.ipv6.cmd.nu.
*.0.2.0 IN PTR not-active.ipv6.cmd.nu.
*.5.2.0 IN PTR not-active.ipv6.cmd.nu.
*.0.e.2 IN PTR not-active.ipv6.cmd.nu.
...
*.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR brownie.cmd.nu.
*.3.e.8.f.8.e.f.f.f.3.b.2.0.2.0 IN PTR constella.cmd.nu
*.6.c.3.3.4.e.f.f.f.9.2.c.0.2.0 IN PTR hermes.cmd.nu.
*.b.7.b.2.6.e.f.f.f.9.2.c.0.2.0 IN PTR electron.cmd.nu.
*.0.9.2.1.e.e.f.f.f.2.2.0.5.2.0 IN PTR mars.cmd.nu
*.b.6.e.4.5.e.f.f.f.1.8.0.0.e.2 IN PTR thunder.cmd.nu
[81 subdomains total]
> ; Dead sub
> $ORIGIN d.a.e.d.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR brownie.cmd.nu.
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.cmd.nu.
> * IN PTR tunnel.ipv6.cmd.nu.
Same here, only easier, 16 subdomains total:
* IN PTR tunnel.ipv6.cmd.nu.
*.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
*.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR tunnel.ipv6.cmd.nu.
--
Joe Yao
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
Joseph S D Yao
f.e.e.b and d.a.e.d:
$ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
* IN PTR out-of-bounds.ipv6.cmd.nu.
*.b IN PTR out-of-bounds.ipv6.cmd.nu.
*.e.b IN PTR out-of-bounds.ipv6.cmd.nu.
*.e.e.b IN PTR out-of-bounds.ipv6.cmd.nu.
*.d IN PTR out-of-bounds.ipv6.cmd.nu.
*.e.d IN PTR out-of-bounds.ipv6.cmd.nu.
*.a.e.d IN PTR out-of-bounds.ipv6.cmd.nu.
If you want to worry about all the little subdomains, then you need to
add the following:
$ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
b IN PTR out-of-bounds.ipv6.cmd.nu.
d IN PTR out-of-bounds.ipv6.cmd.nu.
$ORIGIN f.e.e.b.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
0 IN PTR not-active.ipv6.cmd.nu.
2 IN PTR not-active.ipv6.cmd.nu.
0.0 IN PTR not-active.ipv6.cmd.nu.
2.0 IN PTR not-active.ipv6.cmd.nu.
e.2 IN PTR not-active.ipv6.cmd.nu.
...
$ORIGIN d.a.e.d.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
0 IN PTR tunnel.ipv6.cmd.nu.
0.0 IN PTR tunnel.ipv6.cmd.nu.
...
Steve K.
eye appearance (I frankly find it difiuclt to make any sence of show
it's structured, where as ipv4 a.b.c.d is so easy to understand), why
would anyone want to use it? I really am curious.
Joseph S D Yao wrote:
> I should add that you need those also for subdomains leading up to
> f.e.e.b and d.a.e.d:
>
> $ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
> * IN PTR out-of-bounds.ipv6.cmd.nu.
> *.b IN PTR out-of-bounds.ipv6.cmd.nu.
> *.e.b IN PTR out-of-bounds.ipv6.cmd.nu.
> *.e.e.b IN PTR out-of-bounds.ipv6.cmd.nu.
> *.d IN PTR out-of-bounds.ipv6.cmd.nu.
> *.e.d IN PTR out-of-bounds.ipv6.cmd.nu.
> *.a.e.d IN PTR out-of-bounds.ipv6.cmd.nu.
>
> If you want to worry about all the little subdomains, then you need to
> add the following:
>
> $ORIGIN 4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
>
> b IN PTR out-of-bounds.ipv6.cmd.nu.
> d IN PTR out-of-bounds.ipv6.cmd.nu.
>
> $ORIGIN f.e.e.b.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
>
> 0 IN PTR not-active.ipv6.cmd.nu.
> 2 IN PTR not-active.ipv6.cmd.nu.
> 0.0 IN PTR not-active.ipv6.cmd.nu.
> 2.0 IN PTR not-active.ipv6.cmd.nu.
> e.2 IN PTR not-active.ipv6.cmd.nu.
> ....
>
> $ORIGIN d.a.e.d.4.c.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
>
> 0 IN PTR tunnel.ipv6.cmd.nu.
> 0.0 IN PTR tunnel.ipv6.cmd.nu.
> ....
Karl Auer
> I am curious, why are you using ipv6 in the first place? Aside from it's
> eye appearance (I frankly find it difiuclt to make any sence of show
> it's structured, where as ipv4 a.b.c.d is so easy to understand), why
> would anyone want to use it? I really am curious.
Address space exhaustion is the global warming of the Internet. Nobody
*really* believes it's coming, but it is. There are various short term
strategies, like NAT, that alleviate the symptoms but do not actually
fix the problem.
IPv6 fixes quite a few problems that plague the Internet - it delivers
automatic addressing for smaller networks, almost automatic addressing
for larger networks, automatic renumbering, much more efficient ways of
finding servers, no more broadcasts, finer grained control of
subnetting, way better route aggregation, faster processing due to a
simplified header...
As to how it's structured in the DNS, it's *exactly the same* as IPv4,
with obvious exceptions:
- the entries are longer because the addresses are bigger
- it's hex, not decimal (about time!)
- addresses are divided on nibble boundaries instead of byte boundaries
- reverse lookups are in "ip6.arpa" instead of "in-addr.arpa".
Get into it. Or you'll be sitting on top of your house waiting for the
coastguard while the rest of us enjoy our lovely new ocean views.
Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
Edward Lewis
>I am curious, why are you using ipv6 in the first place? Aside from it's
>eye appearance (I frankly find it difiuclt to make any sence of show
>it's structured, where as ipv4 a.b.c.d is so easy to understand), why
>would anyone want to use it? I really am curious.
This really isn't the forum for this question.
There's another answer out there already that I would could be
simplified that IPv6 is just 96 more bits in address space. A lot of
the innovations introduced for IPv6 have already been rolled back
into IPv4 (like IPSEC), and there are band-aids like NAT that
alleviate other shortcomings.
IPv4 won't allow the Internet to grow to a global scale. (Contrary
to reports, the Internet still has a lot of growth left.) IPv6
removes the address depletion factor.
OTOH, whether IPv6 is still the answer (it was selected to replace
IPv4 about 10 years ago) is something I question. Route table
capacity issues dog the technology and are the primary reason holding
it back.
So far, the dancing KAME turtle has been the only thing available on
IPv6 that is not available on IPv4. If a dancing turtle couldn't
make IPv6 popular, what can?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
dhott...@harrisonburg.k12.va.us
benefits and speed increase in ipV6. I remained critical during the
entire seminar. What it essentially boiled down to is the city is
getting ready to crank up a city wide wireless network using ipV6.
Great for the city. But if we are an island in the middle of all ipv4
routers, all the traffic has to be encapsulated in ipv4 packets.
Hence all speed increases are null because everything suddenly becomes
ipv4 instead of ipv6. I think the main reason they went with ipv6 was
because of the availibility of ipv4 addresses. Although NATING would
handle the issue quite well. I wouldnt think that every device would
need a public ip. Also IPv4 addresses were handed out quite willy
nilly. Some institutions own huge blocks of addresses and dont use
them. I have 3 class C's and only use a fraction of them. But, I
wont give them up. Although my ISP is really eager for me to give
some up. If the internet continues to grow, IPv6 will just be a
stopgap measure. Those addresses are not infinite.
ddh
Quoting Edward Lewis <Ed.L...@neustar.biz>:
--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools
Karl Auer
wrote:
> Great for the city. But if we are an island in the middle of all ipv4
> routers, all the traffic has to be encapsulated in ipv4 packets.
> Hence all speed increases are null because everything suddenly becomes
> ipv4 instead of ipv6.
The islands will join up. It's a chicken and egg thing. IPv4 started out
as islands too, don't forget, and it had competition from many other
protocols, whereas IPv6 has competition really only from IPv4.
People can win a lot from IPv6 without having IPv6 connectivity to the
Internet. Autoaddressing, IPSEC, no broadcasts, VAST private address
space, etc.
> I think the main reason they went with ipv6 was
> because of the availibility of ipv4 addresses. Although NATING would
> handle the issue quite well.
NAT is a Bad Thing for the Internet. It is a classic
treat-the-symptom-not-the-disease response, and while it has saved our
bacon for now, the waters are still rising...
> I wouldnt think that every device would need a public ip.
Even quite small organisations are running out of *private* address
space. IPv6 delivers a vast amount of private address space too...
Don't fall for what Richard Dawkins calls the Argument from Personal
Incredulity. The fact that you don't see it, don't get it, don't
understand it, don't believe it, don't want it or don't need it doesn't
prove anything. We cannot imagine what things the future will dream up
to do with almost unlimited address space.
> Also IPv4 addresses were handed out quite willy
> nilly. Some institutions own huge blocks of addresses and dont use
> them. I have 3 class C's and only use a fraction of them. But, I
> wont give them up.
That's the problem, thanks for being part of it. There are people
sitting on largely empty /8 (!) and /16 networks who won't give them up
either.
> Although my ISP is really eager for me to give
> some up. If the internet continues to grow, IPv6 will just be a
> stopgap measure. Those addresses are not infinite.
No, and there are already disturbing signs both of incompetence in
applying for stupidly large spaces and worse, of incompetence in
allocating stupidly large spaces. And of outright land-grabbing. The US
Government, for example, wanted an IPv6 /8 network. All for itself.
We will need to be *extremely* profligate with addresses to put a dent
in that vast address space. Sadly some people are already being
extremely profligate.
Edward Lewis
>I just recently attended an ipV6 seminar that touted the great
>benefits and speed increase in ipV6. I remained critical during the
Don't hold the touting against the technology. IMHO, IPv6 zealots
oversell and over hype the technology. The raised expectations
either will be missed or seen as 21st century snake oil.
Faster? Did they also say it whitens your teeth too?
Faster is quirky - I've seen that used to over hype everything. IPv6
could make your network faster in part because is may require you to
buy all new equipment.
My message is - don't let the "touts" get you down or against the
technology. Staying skeptical is a good thing until it raises your
blood pressure.
>entire seminar. What it essentially boiled down to is the city is
>getting ready to crank up a city wide wireless network using ipV6.
>Great for the city. But if we are an island in the middle of all ipv4
>routers, all the traffic has to be encapsulated in ipv4 packets.
>Hence all speed increases are null because everything suddenly becomes
>ipv4 instead of ipv6. I think the main reason they went with ipv6 was
>because of the availibility of ipv4 addresses. Although NATING would
>handle the issue quite well. I wouldnt think that every device would
>need a public ip. Also IPv4 addresses were handed out quite willy
>nilly. Some institutions own huge blocks of addresses and dont use
>them. I have 3 class C's and only use a fraction of them. But, I
>wont give them up. Although my ISP is really eager for me to give
>some up. If the internet continues to grow, IPv6 will just be a
>stopgap measure. Those addresses are not infinite.
Keep in mind that one reason to move to IPv6 is to reach out to those
that can't get IPv4 addresses, they exist even if some organizations
are "hoarding" them.
It's not clear what interfaces will have public IP addresses (meaning
fully routable) in the future. NAT does complicate protocol design
and can mess with security; a NAT box is one more thing that can fail
out in the network beyond your reach. (NAT is a band aid, it helps
but it isn't a permanent solution.)
Don't dis IPv6, it's just a technology, it's not a cultural invasion.
dhott...@harrisonburg.k12.va.us
wont let me. So, hence I am part of the problem, but not by my own
doing. I inherited most of what I have, and although it works quite
well there are several things Im working on changing that being one.
I agree that ipv6 has quite a few good things, but I am not quite sure
it is the answer to the problem. I think the US goverment has already
implemented ipv6, they use it extensively for troop communications in
IRAQ. Yea, chicken and egg. But with quite a bit of cost associated
with it. Which is why Im taking a wait and see approach. As I remove
equipment and install new, the new will be ipv6 compat. I know its
coming. No way around it.
Quoting Karl Auer <ka...@biplane.com.au>:
> On Thu, 2007-01-04 at 08:25 -0500, dhott...@harrisonburg.k12.va.us
> wrote:
>> Great for the city. But if we are an island in the middle of all ipv4
>> routers, all the traffic has to be encapsulated in ipv4 packets.
>> Hence all speed increases are null because everything suddenly becomes
>> ipv4 instead of ipv6.
>
> The islands will join up. It's a chicken and egg thing. IPv4 started out
> as islands too, don't forget, and it had competition from many other
> protocols, whereas IPv6 has competition really only from IPv4.
>
> People can win a lot from IPv6 without having IPv6 connectivity to the
> Internet. Autoaddressing, IPSEC, no broadcasts, VAST private address
> space, etc.
>
>> I think the main reason they went with ipv6 was
>> because of the availibility of ipv4 addresses. Although NATING would
>> handle the issue quite well.
>
> NAT is a Bad Thing for the Internet. It is a classic
> treat-the-symptom-not-the-disease response, and while it has saved our
> bacon for now, the waters are still rising...
>
>> I wouldnt think that every device would need a public ip.
>
> Even quite small organisations are running out of *private* address
> space. IPv6 delivers a vast amount of private address space too...
>
> Don't fall for what Richard Dawkins calls the Argument from Personal
> Incredulity. The fact that you don't see it, don't get it, don't
> understand it, don't believe it, don't want it or don't need it doesn't
> prove anything. We cannot imagine what things the future will dream up
> to do with almost unlimited address space.
>
>> Also IPv4 addresses were handed out quite willy
>> nilly. Some institutions own huge blocks of addresses and dont use
>> them. I have 3 class C's and only use a fraction of them. But, I
>> wont give them up.
>
> That's the problem, thanks for being part of it. There are people
> sitting on largely empty /8 (!) and /16 networks who won't give them up
> either.
>
>> Although my ISP is really eager for me to give
>> some up. If the internet continues to grow, IPv6 will just be a
>> stopgap measure. Those addresses are not infinite.
>
> No, and there are already disturbing signs both of incompetence in
> applying for stupidly large spaces and worse, of incompetence in
> allocating stupidly large spaces. And of outright land-grabbing. The US
> Government, for example, wanted an IPv6 /8 network. All for itself.
>
> We will need to be *extremely* profligate with addresses to put a dent
> in that vast address space. Sadly some people are already being
> extremely profligate.
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h)
> http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
>
>
>
--
Marc Haber
> Hence all speed increases are null because everything suddenly becomes
> ipv4 instead of ipv6.
IPv6 is not going to increase speed. Who sells IPv6 because it's
faster did miss something.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Mark Andrews
For those of you who think NAT's are great try connecting
to a port forwarded service from behind a NAT. I've yet
to see a NAT box do this right. The NAT box should be
able to loop the traffic around. Instead we are forced
to kludge solutions to this in the DNS.
Look back through the archive of this list and you will
see some of the problems NAT's cause.
IPv6 is a significant step forward. It has enough address
space the every home can have it's own network with global
address for each device in the home if they want.
There are lots of things you can do when you have a
globally routable IP address that you can't do from
behind a NAT.
Bring on IPv6.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Clenna Lumina
> On Thu, 2007-01-04 at 08:25 -0500, dhott...@harrisonburg.k12.va.us
> wrote:
>> Great for the city. But if we are an island in the middle of all
>> ipv4 routers, all the traffic has to be encapsulated in ipv4 packets.
>> Hence all speed increases are null because everything suddenly
>> becomes ipv4 instead of ipv6.
>
> The islands will join up. It's a chicken and egg thing. IPv4 started
> out as islands too, don't forget, and it had competition from many
> other protocols, whereas IPv6 has competition really only from IPv4.
>
> People can win a lot from IPv6 without having IPv6 connectivity to the
> Internet. Autoaddressing, IPSEC, no broadcasts, VAST private address
> space, etc.
But what's the point of using it on a Private LAN? It just adds
confusion and lack of clarity. Not to mention for privat subnets, it'll
just be overkill. What's wrong with using 10.0.0.0 or 192.168.0.0 or any
other private subnet?
I find that the *appearance* of an IPv6 address is confusing in and of
it self. It actually look like an IPX address (maybe a cross between an
IPX address and a MAC address.) Don't get me wrong, I like HEX, but I
think it's nto such a good idea to change such a basic idiom... sice
TCP/IP came out, people have used DEC octets, any one wh oworks with
networks thinks DEC when thinking of IP addresses... I'd imagine IPv6
turns that way of thinking inside out and upside down.
Wouldn't it be better to have a better solution that could be somewhat
compatible with IPv4 so we don't have to get used to something so
radically different?
>> I think the main reason they went with ipv6 was
>> because of the availibility of ipv4 addresses. Although NATING would
>> handle the issue quite well.
>
> NAT is a Bad Thing for the Internet. It is a classic
> treat-the-symptom-not-the-disease response, and while it has saved our
> bacon for now, the waters are still rising...
I disagree. If you think NAT is bad then you don't know how to properly
use one. For home and busienss LANs, you can have one IP and share it
among the whole LAN? How is this a BAD thing? It's a money saver. I
suppose that's a BAD thing too.
>> I wouldnt think that every device would need a public ip.
>
> Even quite small organisations are running out of *private* address
> space. IPv6 delivers a vast amount of private address space too...
Then they have the wrong class (or length) subnet. I dare you find a
small organization using a private 10.0.0.0 subnet and is running out of
them.
> Don't fall for what Richard Dawkins calls the Argument from Personal
> Incredulity. The fact that you don't see it, don't get it, don't
> understand it, don't believe it, down't want it or don't need it
> doesn't prove anything.
Thats exactly what you're doing with NAT, while ignoring it's obvious
benefits.
> We cannot imagine what things the future will
> dream up to do with almost unlimited address space.
I don't deny it, just probably not with IPv6 as we know it.
>> Also IPv4 addresses were handed out quite willy
>> nilly. Some institutions own huge blocks of addresses and dont use
>> them. I have 3 class C's and only use a fraction of them. But, I
>> wont give them up.
>
> That's the problem, thanks for being part of it. There are people
> sitting on largely empty /8 (!) and /16 networks who won't give them
> up either.
Sooner or later they will probably need to give part of them up.
You're also forgetting that private space is completely seperate form
public (Internet) space. Most large chuncks of network space are used by
ISPs, and hosting companies. Private addresses are only visible to the
private network. Anyone can sue thme on their own networks. IE,
192.168.0.0 or 10.0.0.0 can and are used on man MANY private networks.
>> Although my ISP is really eager for me to give
>> some up. If the internet continues to grow, IPv6 will just be a
>> stopgap measure. Those addresses are not infinite.
>
> No, and there are already disturbing signs both of incompetence in
> applying for stupidly large spaces and worse, of incompetence in
> allocating stupidly large spaces. And of outright land-grabbing. The
> US Government, for example, wanted an IPv6 /8 network. All for itself.
How the hell do you eve ndefine how big an IPv6 /8 network is? Deos it
equate to an IPv4 /8 or is it everything up to the last octet? The way
IPv6, it's eanything but clear and this is one of the many problems that
seems to be stiffling IPv6 and why most just don't use it.
> We will need to be *extremely* profligate with addresses to put a dent
> in that vast address space. Sadly some people are already being
> extremely profligate.
You you don't think any of it at all is at least partly do to the
inherently confusing nature of IPv6? (At least when compared to IPv4.)
Clenna Lumina
> For those of you who think NAT's are great try connecting
> to a port forwarded service from behind a NAT. I've yet
> to see a NAT box do this right. The NAT box should be
> able to loop the traffic around. Instead we are forced
> to kludge solutions to this in the DNS.
No, a *properly* behaving NAT should always allow looping back. If you
Are runnign a NAT that doesn't allow this, then it is broken. You cannot
put down NAT just because of broken implimentations.
> Look back through the archive of this list and you will
> see some of the problems NAT's cause.
Again, bad NAT or improperly configured NAT software/hardware is the
problem, not NATs in and of them selves, it's a fundemental difference.
> IPv6 is a significant step forward. It has enough address
> space the every home can have it's own network with global
> address for each device in the home if they want.
Yes, but in order to use it you have to turn your network world as you
se it upside down, and for many it doesn't seem worth all that. I think
many are just waiting for a much beter soution.
> There are lots of things you can do when you have a
> globally routable IP address that you can't do from
> behind a NAT.
Name one. With properly configured NAT, I've not had one single problem
routing things between various servers, no matter what they run. A
proper NAT will allow you to set up routes to services and also allow
the preservation of ports (other wise ceratin service do indeed break if
they aren't routed back to an expect port and instead to a
random-un-priv, etc etc.)
It all depends on the implimentation, and if it's behaving correctly.
NAT32e is a good example of how a properly configured NAT should behave.
> Bring on IPv6.
Bring on something better, and more compatible with IPv4, please.
Karl Auer
> > People can win a lot from IPv6 without having IPv6 connectivity to the
> > Internet. Autoaddressing, IPSEC, no broadcasts, VAST private address
> > space, etc.
>
> But what's the point of using it on a Private LAN? It just adds
> confusion and lack of clarity. Not to mention for privat subnets, it'll
> just be overkill. What's wrong with using 10.0.0.0 or 192.168.0.0 or any
> other private subnet?
Private LANs are not the whole world. The private space offered by IPv4
is already too small for many medium to large networks. The problem is
partly the overall size of the address space, the other problem is the
waste due to subnetting. Together they make things very cramped.
There's nothing "wrong" with using IPv4 - it's just that pretty soon you
won't be *able* to, because there will be no more address space.
> Wouldn't it be better to have a better solution that could be somewhat
> compatible with IPv4 so we don't have to get used to something so
> radically different?
If you just mean the appearance - well, I think that's pretty
irrelevant. Most systems are administered by software, not the human
eye. I don't find IPv6 addresses particularly onerous.
> I disagree. If you think NAT is bad then you don't know how to properly
> use one. For home and busienss LANs, you can have one IP and share it
> among the whole LAN? How is this a BAD thing? It's a money saver. I
> suppose that's a BAD thing too.
Careful who you talk down to, there. I certainly do know how to
configure NAT.
NAT stops you offering a service from behind it (or makes it
cumbersome). NAT behind a dynamic address stops you doing things like
SPF. NAT slows down every packet, especially in the typical cheap, slow
hardware used in home Internet connections. NAT resists new protocols,
especially if the protocol carries a source address in the payload. NAT
resists multi-connection and back-channel protocols. NAT blocks
troubleshooting from outside the NATted network (loss of end-to-end
transparency). NAT, by blocking connections from outside, is seen as a
security measure, when in fact it is no more than an obfuscation, so NAT
gives a false sense of security.
Because there are so few available IPv4 addresses, many connections are
multiply NATted, making some things completely impossible, in particular
the provision of services from within the NATted network.
As to it being a money saver, yes, it's a temporary solution that is
better than not having a consumer Internet at all. With IPv6, however,
you can have many, many addresses at home, with as many or as few as you
wish exposed to the Internet. These addresses come at a very low
marginal cost - WAY lower than even the one, single, RFC1918 address you
probably get from your ISP.
> > Even quite small organisations are running out of *private* address
> Then they have the wrong class (or length) subnet. I dare you find a
> small organization using a private 10.0.0.0 subnet and is running out of
> them.
I said "quite small", not "small". Maybe your idea of "small" is too
small :-) A /8 is only 16 million addresses. The population of
Australia, where I live, is 20 million. Australia is a small part of the
Internet. You do the maths - then think about giants like AOL, which
itself shrinks to insignificance beside (say) China in twenty years...
32 bit addressing is very, very cramped.
> Thats exactly what you're doing with NAT, while ignoring it's obvious
> benefits.
Nat at all. See above.
> I don't deny it, just probably not with IPv6 as we know it.
Perhaps. But absolutely 100% definitely NOT with IPv4.
> You're also forgetting that private space is completely seperate form
> public (Internet) space.
No, Clenna, I am not forgetting that.
> How the hell do you eve ndefine how big an IPv6 /8 network is? Deos it
> equate to an IPv4 /8 or is it everything up to the last octet? The way
> IPv6, it's eanything but clear and this is one of the many problems that
> seems to be stiffling IPv6 and why most just don't use it.
If you don't know that, I am mystified as to why you think yourself
qualified to make such confident pronouncements about IPv4, let alone
IPv6.
The short answer is that it works exactly as it does in IPv4, just with
way bigger addresses. A /8 in IPv4 has 24 bits of addresses, with an
8-bit prefix. A /8 in IPv6 has 56 bits of addresses, also with an 8-bit
prefix. The address space can be further subnetted of course, just like
IPv4 address space.
> You you don't think any of it at all is at least partly do to the
> inherently confusing nature of IPv6? (At least when compared to IPv4.)
We find new things confusing. IPv6 is no more complicated than IPv4, we
are just not used to it.
Mark Andrews
> Karl Auer wrote:
> > On Thu, 2007-01-04 at 08:25 -0500, dhott...@harrisonburg.k12.va.us
> > wrote:
> >> Great for the city. But if we are an island in the middle of all
> >> ipv4 routers, all the traffic has to be encapsulated in ipv4 packets.
> >> Hence all speed increases are null because everything suddenly
> >> becomes ipv4 instead of ipv6.
> >
> > The islands will join up. It's a chicken and egg thing. IPv4 started
> > out as islands too, don't forget, and it had competition from many
> > other protocols, whereas IPv6 has competition really only from IPv4.
> >
> > Internet. Autoaddressing, IPSEC, no broadcasts, VAST private address
> > space, etc.
>
> confusion and lack of clarity. Not to mention for privat subnets, it'll
> just be overkill. What's wrong with using 10.0.0.0 or 192.168.0.0 or any
> other private subnet?
There are not enough addresses in 10.0.0.0/8 for some private
networks. I'm aware of organisations which have outgrown
all of the address space from RFC 1918.
> I find that the *appearance* of an IPv6 address is confusing in and of
> it self. It actually look like an IPX address (maybe a cross between an
> IPX address and a MAC address.) Don't get me wrong, I like HEX, but I
> think it's nto such a good idea to change such a basic idiom... sice
> TCP/IP came out, people have used DEC octets, any one wh oworks with
> networks thinks DEC when thinking of IP addresses... I'd imagine IPv6
> turns that way of thinking inside out and upside down.
>
> Wouldn't it be better to have a better solution that could be somewhat
> compatible with IPv4 so we don't have to get used to something so
> radically different?
Nibble is a presentation format. For ip6.arpa is actually
make delegation on arbitary bit boundaries easier. It also
provides twice as many natural break points than breaking
on the octet.
It's also easier to work out which addresses fall within
a given mask and which don't.
> >> I think the main reason they went with ipv6 was
> >> because of the availibility of ipv4 addresses. Although NATING would
> >> handle the issue quite well.
> >
> > NAT is a Bad Thing for the Internet. It is a classic
> > treat-the-symptom-not-the-disease response, and while it has saved our
> > bacon for now, the waters are still rising...
>
> I disagree. If you think NAT is bad then you don't know how to properly
> use one. For home and busienss LANs, you can have one IP and share it
> among the whole LAN? How is this a BAD thing? It's a money saver. I
> suppose that's a BAD thing too.
NAT works for a limited set of protocols. There are lots of
things that just won't work through a NAT. That is a bad thing.
If all you want is HTTP and SMTP then NAT kind of works. Even
then you have to work around the limitations of the NAT devices
to make things work in all cases.
As for being a money saver, it is a money saver in the IPv4
world where address are scarse. For IPv6 the default end
user allocation is a /48 which gives 65536 /64 networks.
Address space is being allocated to ISP's so that they can
handout that much addresses space to their clients the
way they hand out a single IPv4 address today.
> >> I wouldnt think that every device would need a public ip.
> >
> > Even quite small organisations are running out of *private* address
> > space. IPv6 delivers a vast amount of private address space too...
>
> Then they have the wrong class (or length) subnet. I dare you find a
> small organization using a private 10.0.0.0 subnet and is running out of
> them.
>
> > Don't fall for what Richard Dawkins calls the Argument from Personal
> > Incredulity. The fact that you don't see it, don't get it, don't
> > understand it, don't believe it, down't want it or don't need it
> > doesn't prove anything.
>
> Thats exactly what you're doing with NAT, while ignoring it's obvious
> benefits.
>
> > We cannot imagine what things the future will
> > dream up to do with almost unlimited address space.
>
> I don't deny it, just probably not with IPv6 as we know it.
>
> >> Also IPv4 addresses were handed out quite willy
> >> nilly. Some institutions own huge blocks of addresses and dont use
> >> them. I have 3 class C's and only use a fraction of them. But, I
> >> wont give them up.
> >
> > That's the problem, thanks for being part of it. There are people
> > sitting on largely empty /8 (!) and /16 networks who won't give them
> > up either.
>
> Sooner or later they will probably need to give part of them up.
>
> You're also forgetting that private space is completely seperate form
> public (Internet) space. Most large chuncks of network space are used by
> ISPs, and hosting companies. Private addresses are only visible to the
> private network. Anyone can sue thme on their own networks. IE,
> 192.168.0.0 or 10.0.0.0 can and are used on man MANY private networks.
And that causes all sorts of problems due to address ambiguity.
> >> Although my ISP is really eager for me to give
> >> some up. If the internet continues to grow, IPv6 will just be a
> >> stopgap measure. Those addresses are not infinite.
> >
> > No, and there are already disturbing signs both of incompetence in
> > applying for stupidly large spaces and worse, of incompetence in
> > allocating stupidly large spaces. And of outright land-grabbing. The
> > US Government, for example, wanted an IPv6 /8 network. All for itself.
>
> How the hell do you eve ndefine how big an IPv6 /8 network is? Deos it
> equate to an IPv4 /8 or is it everything up to the last octet? The way
> IPv6, it's eanything but clear and this is one of the many problems that
> seems to be stiffling IPv6 and why most just don't use it.
A individual IPv6 address is a /128. A net the size of a IPv4
/8 is a /102.
> > We will need to be *extremely* profligate with addresses to put a dent
> > in that vast address space. Sadly some people are already being
> > extremely profligate.
>
> You you don't think any of it at all is at least partly do to the
> inherently confusing nature of IPv6? (At least when compared to IPv4.)
Marc Haber
> Mark Andrews wrote:
> > For those of you who think NAT's are great try connecting
> > to a port forwarded service from behind a NAT. I've yet
> > to see a NAT box do this right. The NAT box should be
> > able to loop the traffic around. Instead we are forced
> > to kludge solutions to this in the DNS.
>
> Are runnign a NAT that doesn't allow this, then it is broken. You cannot
> put down NAT just because of broken implimentations.
Just show me how to do IPSEC AH via NAT. Or how to connect to a
service that does RFC1413 ident lookups and actually does something
with the returned value.
Even trying to have a mail server HELO with the right host name,
regardless of whether the machine connected to is on the internal or
an external network, is a challenge if NAT is in the game.
> > IPv6 is a significant step forward. It has enough address
> > space the every home can have it's own network with global
> > address for each device in the home if they want.
>
> Yes, but in order to use it you have to turn your network world as you
> se it upside down, and for many it doesn't seem worth all that. I think
> many are just waiting for a much beter soution.
IPv6 _IS_ this much better solution.
> > There are lots of things you can do when you have a
> > globally routable IP address that you can't do from
> > behind a NAT.
>
> Name one. With properly configured NAT, I've not had one single problem
> routing things between various servers, no matter what they run.
Then you have not tried a lot of things.
> > Bring on IPv6.
>
> Bring on something better, and more compatible with IPv4, please.
You're trying to be washed without getting wet. IPv4's fundamental
problem is too small address space. IPv6 is simply just IP with longer
addresses. And it is very compatible.
This whole thread sounds like you're desperately trying to find a
problem for _your_ solution because you're afraid to learn something
new.
Karl Auer
> The short answer is that it works exactly as it does in IPv4, just with
> way bigger addresses. A /8 in IPv4 has 24 bits of addresses, with an
> 8-bit prefix. A /8 in IPv6 has 56 bits of addresses, also with an 8-bit
> prefix. The address space can be further subnetted of course, just like
> IPv4 address space.
Er, obviously I meant "a /8 in IPv6 has 120 bits of addresses"! I've
been puddling around in 64-bit subnets too long :-)
Mark Andrews
> Mark Andrews wrote:
> > For those of you who think NAT's are great try connecting
> > to a port forwarded service from behind a NAT. I've yet
> > to see a NAT box do this right. The NAT box should be
> > able to loop the traffic around. Instead we are forced
> > to kludge solutions to this in the DNS.
>
> No, a *properly* behaving NAT should always allow looping back. If you
> Are runnign a NAT that doesn't allow this, then it is broken. You cannot
> put down NAT just because of broken implimentations.
>
> > see some of the problems NAT's cause.
>
> Again, bad NAT or improperly configured NAT software/hardware is the
> problem, not NATs in and of them selves, it's a fundemental difference.
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.
You can usually get away with it for TCP, UDP and ICMP if you
initiate the connection from inside. If you want to have multiple
servers on the inside you loose out.
> > IPv6 is a significant step forward. It has enough address
> > space the every home can have it's own network with global
> > address for each device in the home if they want.
>
> Yes, but in order to use it you have to turn your network world as you
> se it upside down, and for many it doesn't seem worth all that. I think
> many are just waiting for a much beter soution.
Have you run a IPv6 network?
As long as you can get external IPv6 connectivity (achievable
via tunnels if you ISP doesn't yet support IPv6). You just
enable IPv6 on the machines, add their addresses to the DNS
if they havn't done that themselves and most things just
work.
I don't call that "turning the network upside down".
If you look at the headers of this email you will see
that the outbound mail from my machine at home leaves here
via IPv6.
It just works.
> > There are lots of things you can do when you have a
> > globally routable IP address that you can't do from
> > behind a NAT.
>
> Name one. With properly configured NAT, I've not had one single problem
> routing things between various servers, no matter what they run. A
> proper NAT will allow you to set up routes to services and also allow
> the preservation of ports (other wise ceratin service do indeed break if
> they aren't routed back to an expect port and instead to a
> random-un-priv, etc etc.)
Try running multiple ntp daemons from inside syncing to the
same external time sources. It doesn't work properly. There
is not enough information to demux the replies correctly.
Try running a active FTP client.
Try running a passive FTP server.
Try running multiple servers.
Try running multiple VOIP phones with default configurations.
You have to do a whole lot of workarounds or limit the
available modes.
> It all depends on the implimentation, and if it's behaving correctly.
>
> NAT32e is a good example of how a properly configured NAT should behave.
>
> > Bring on IPv6.
>
> Bring on something better, and more compatible with IPv4, please.
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.
Anything that just does or the equivalent on the client side
will work.
gethostbyname()
socket()
connect() / sendto()
Anything that does just this on the server side will just work.
socket()
bind()
listen() + accept() / recvfrom()
That's the majority of network programs.
Mark
Edward Lewis
> 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.
> 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.
> 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.
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
dedication.)
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.
Clenna Lumina
> > > For those of you who think NAT's are great try connecting
> > > to a port forwarded service from behind a NAT. I've yet
> > > to see a NAT box do this right. The NAT box should be
> > > able to loop the traffic around. Instead we are forced
> > > to kludge solutions to this in the DNS.
> >
> > No, a *properly* behaving NAT should always allow looping
> > then it is broken. You cannot put down NAT just because
> > of broken implimentations.
>
> to a service that does RFC1413 ident lookups and actually does
> something with the returned value.
My last company I worked for was running IPSEC (VPN, etc) through their
(properly) NATed firewall without any problems. Again, this is a
difference between poor implimentations and the concept your self.
You're attacking the wrong one here.
> Even trying to have a mail server HELO with the right host
> name, regardless of whether the machine connected to is on the
> internal or an external network, is a challenge if NAT is in
> the game.
I can't say I've ever seen that be a problem behind a NAT. The HELO is
usually generated by the address of the server the connecitng mail
server is trying to reach, so if it's generating a bad HELO, then thats
the fault of the foreign mail server, which is likely not configured
correctly to begin with.
My personal mail server which sits behind my home NAT, has never faield
to get a proper HELO from proper foreign hosts.
> > > IPv6 is a significant step forward. It has enough address
> > > space the every home can have it's own network with
> > > global address for each device in the home if they want.
> >
> > Yes, but in order to use it you have to turn your network
> > world as you sse it upside down, and for many it doesn't
> > seem worth all that. I think many are just waiting for a
> > much beter soution.
>
> IPv6 _IS_ this much better solution.
It may be.
Just to clear something up, when I said "turn your network world upside
down" I mean in the way you think about IP addresses and the like, will
be radically different. You can't tell me that
11.22.33.44.55.66.77.88.99.AA.BB.CC.DD.EE.FF.00 is the same as typing
out 111.222.333.444 , be it in geenral speak or entering into a conf
file or passing along an IP to a friend for setting up a friendly
private Quake match.
Can you really tell me you can easily remember an address that long? I
can remebmer a 4 section IP with out any trouble. Remembering an IPv6
address might be possible, no doubt, but you'd likely have to known it
rather well, and have a rather good memory.
It's a whole you way of thinking about TCP/IP that going to be a rough
adjustment for many and while I DO LIKE the advantages (roomy address
space, using HEX, etc) of IPv6, I really do wish a solutuion could be
devised to make such adjustments much more easiler.
> > > There are lots of things you can do when you have a
> > > globally routable IP address that you can't do from
> > > behind a NAT.
> >
> > Name one. With properly configured NAT, I've not had one
> > single problem routing things between various servers,
> > no matter what they run.
>
> Then you have not tried a lot of things.
>
> > > Bring on IPv6.
> >
> > Bring on something better, and more compatible with IPv4,
> > please.
>
> You're trying to be washed without getting wet. IPv4's
> fundamental problem is too small address space. IPv6 is
> simply just IP with longer addresses. And it is very compatible.
>
> This whole thread sounds like you're desperately trying to
> find a problem for _your_ solution because you're afraid to
> learn something new.
I'm not afriad to try it. I *have* tried it already. I find the huge
addresses to be rather big adjustment for someone who has spent all
their life looking at 4 eight bit number seperated by periods. I didin't
say it was impossible, however. Hell, I will probably end up enabling
IPv6 on my home network to try to get a better feel for it.
I just simply wish they didn't deviate so much in how an IP address
looks like. Even if that's a cosmetic thing, I don't doubt most people
are used to 123.123.123.123 and that a 16 section HEX string is no where
near as elegant or easy to pass around (especially verbally) as you
could with IPv4 addresses.
While that's far from being the most important factor, I think that it
does carry *SOME* importantance, as people would have to use them, look
at them, enter them, etc. Entering 4 three digit numbers is a breeze.
Entering 16 sets instead just wouldn't be the same, you know :)
Actually a couple years ago, after hearing about IPv4 address slowly
becoming scarce, I actually sort of invisioned IPv4 being expanded in a
similar way telephone numbers were introduced into area codes (and
country codes) to furthur divide things. What I envisioned then was
anywhere for 1 to 4 extra sections (8 byte IPs.)
When I first saw an IPv6, it immediately looked like over kill. Like I
said, I will be trying it on my own local network to get a real feel for
it. On this note, are there any good documents out ther that describe
what the general conventations are for IPv6 IPs? FOr instance, in IPv4,
192.168/16, 172.16/12, 10/8, are considered LAN-only IP blocks, 127/8
being loopback block.
Clenna Lumina
> 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.
I'm just curious, what sort of problems does DNS have behind NAT in your
experience? I'm running Bind 9 behind a NAT that both manages a couple
domains I own and acts as the main DNS server for my tiny network, thus
queries going either way - seeking athorative answeres for the domains I
own, and the other way seeking google.com, etc - without any problems.
I just simply aware people had so much trouble. NAT32e seems to handle
NATing very well IMHO. Maybe it's the fact it has the ability to
preserve port numbers properly for internal servers that seperates it
from many of the broken NATs out there.
In other words, for example, my DNS server's randomly allocated query
port (current 33595) on it's local interface (192.168.1.4) send
something to the outside, NAT32e will attempt to allocate the same port
nubmer (if possible) itself (I can clear see this in it's status page,
that "0.0.0.0:33595" is currently allocated) where as most would use
random port instead. This is probably why I don't really have the kind
of problems I've seen desribed in this thread reguarding NAT. It seem to
all come down to *what* NAT you're using.
[...]
>> 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
> dedication.)
>
> 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.
What I think could be a solution would be to have IPv6 became the main
protocol, with IPv4 transparrently "existing" within it, so to speak,
for backwards compatibility, I'd imagine no programs that rely on IPv4
would have to be rewritten.
Say every ISP in the world just switches over to IPv6. Existing Internet
(IPv4) IPs could be preserved and transported in the IPv6 layer, while
your "true" internet address becomes an IPv6 address. Teh IPv4 would
then exist inside of IPv4, in sort of the way an IP Packet exists inside
of an Ethernet Packet - each level Ethernet, IP), has it's own
respective set of Src and Dest addresses. I see no reason why this
wouldn't be possible to encapsulate IPv4 inside of IPv6 packets in the
same manner.
In fact, I'm actually suprised the designers of IPv6 didn't do this.
(Well, if they actually did, then I apologize, though I can find no info
on that.)
Marc Haber
> (Well, if they actually did, then I apologize, though I can find no info
> on that.)
They actually did. Both ways.
Marc Haber
> > On Thu, Jan 04, 2007 at 02:24:11PM -0800, Clenna Lumina wrote:
> > > Mark Andrews wrote:
> > > > For those of you who think NAT's are great try connecting
> > > > to a port forwarded service from behind a NAT. I've yet
> > > > to see a NAT box do this right. The NAT box should be
> > > > able to loop the traffic around. Instead we are forced
> > > > to kludge solutions to this in the DNS.
> > >
> > > No, a *properly* behaving NAT should always allow looping
> > > back. If you are running a NAT that doesn't allow this,
> > > then it is broken. You cannot put down NAT just because
> > > of broken implimentations.
> >
> > Just show me how to do IPSEC AH via NAT. Or how to connect
> > to a service that does RFC1413 ident lookups and actually does
> > something with the returned value.
>
> My last company I worked for was running IPSEC (VPN, etc) through their
> (properly) NATed firewall without any problems.
I guess that this was IPSEC tunnel mode. I specifically asked for
IPSEC AH for a reason.
> Again, this is a difference between poor implimentations and the
> concept your self. You're attacking the wrong one here.
I am obviously "attacking" somebody who considers herself able to
judge things that she has not the necessary background knowledge
about. "It just works for me" is not enough.
> > Even trying to have a mail server HELO with the right host
> > name, regardless of whether the machine connected to is on the
> > internal or an external network, is a challenge if NAT is in
> > the game.
>
> I can't say I've ever seen that be a problem behind a NAT.
Then you need to be around the block a few more times.
> The HELO is usually generated by the address of the server the
> connecitng mail server is trying to reach,
No. Please read the RFCs before you continue embarrassing yourself
even more.
> so if it's generating a bad HELO, then thats the fault of the foreign
> mail server, which is likely not configured correctly to begin with.
>
> My personal mail server which sits behind my home NAT, has never faield
> to get a proper HELO from proper foreign hosts.
It's the connecting server who says HELO, not the server connected to.
> Just to clear something up, when I said "turn your network world upside
> down" I mean in the way you think about IP addresses and the like, will
> be radically different. You can't tell me that
> 11.22.33.44.55.66.77.88.99.AA.BB.CC.DD.EE.FF.00 is the same as typing
> out 111.222.333.444 , be it in geenral speak or entering into a conf
> file or passing along an IP to a friend for setting up a friendly
> private Quake match.
::1 is even shorter than 127.0.0.1.
and 2001:1b18:f:4::4/128 is not _that_ bad. Yes, that's an actually
workin address.
> Can you really tell me you can easily remember an address that long? I
> can remebmer a 4 section IP with out any trouble. Remembering an IPv6
> address might be possible, no doubt, but you'd likely have to known it
> rather well, and have a rather good memory.
If DNS is properly used, you don't need to remember IPv6 addresses.
And, usually, you only need to remember the prefix anyway.
> Actually a couple years ago, after hearing about IPv4 address slowly
> becoming scarce, I actually sort of invisioned IPv4 being expanded in a
> similar way telephone numbers were introduced into area codes (and
> country codes) to furthur divide things. What I envisioned then was
> anywhere for 1 to 4 extra sections (8 byte IPs.)
Very good idea. Just another migration in ten years. I know people who
have gone through four phone numbers in three different area codes in
the last fifteen years.
Geez, this is _one_ thing that we germans did right. No splits, no
overlays. Only newly assigned numbers get longer. This is based on the
convenient fact that our number length was never fixed in the first
place, and we started making them longer long before the existing
space was depleted so that we had ample _new_ number space to put into
use which saved us from doing the splits.
> When I first saw an IPv6, it immediately looked like over kill. Like I
> said, I will be trying it on my own local network to get a real feel for
> it. On this note, are there any good documents out ther that describe
> what the general conventations are for IPv6 IPs? FOr instance, in IPv4,
> 192.168/16, 172.16/12, 10/8, are considered LAN-only IP blocks, 127/8 being loopback block.
http://en.wikipedia.org/wiki/Ipv6 seems pretty good to me.
Greetings
Mac
Mark Andrews
> 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
> 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
> dedication.)
No. It mean that if you have legacy code it needs a minor
re-write. Something that most programers could do in a
afternoon.
> 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.
Mark
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-571-434-5468
> NeuStar
>
> Dessert - aka Service Pack 1 for lunch.
Sten Carlsen
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.
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
Mark Andrews
> Hi
>
> 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.
This is a classic example of applying a IPv4 solution to a
IPv6 network.
I really don't see why people insist that they need port /
address translation. A statefull firewall is just as good
at providing protection and doesn't have the down sides
introduced as a side effect of the port / address translation.
If you don't want there to be any path to the equipment
don't let it use a global prefix. Use a link local or a
locally assigned local addresses if you have more than one
internal network.
Remember a IPv6 node will often have 3 or more addresses
on each NIC.
Mark
Sten Carlsen
>
> This is a classic example of applying a IPv4 solution to a
> IPv6 network.
>
thing in real life too get a feel for what is possible and what is
"natural" for any new system. This underlines that transition from IPv4
to IPv6 is not just more bits, but rather completely new ways to think.
> I really don't see why people insist that they need port /
> address translation.
IPv4 network. Isolation and hiding. If other mechanisms, not known in
IPv4 networks, can provide that, it is fine with me.
For some things I want that they can initiate a connection to the net,
but are hidden so NO connection can be made from the outside to those
devices. How can that be achieved without NAT in an IPv6 system?
> A statefull firewall is just as good
> at providing protection and doesn't have the down sides
> introduced as a side effect of the port / address translation.
>
I will take your word for that, I still feel there might be more risk.
That could be missing time and effort on my side. On the other side that
suggests a lot of misconfigured firewalls in the future until people
learn how to do it. "A hackers paradise"?
> If you don't want there to be any path to the equipment
> don't let it use a global prefix. Use a link local or a
> locally assigned local addresses if you have more than one
> internal network.
>
Does that mean that a local DHCP server is needed? Or is a fixed address
the best way?
This is an example of what could be the misunderstandings that create
this kind of debate, it also underlines that the transition is NOT
simple as has been said.
> Remember a IPv6 node will often have 3 or more addresses
> on each NIC.
>
That worries me a bit, I guess that will resolve itself as IPv6 becomes
more common in discussions.
> Mark
Marc Haber
> I really don't see why people insist that they need port /
> at providing protection and doesn't have the down sides
> introduced as a side effect of the port / address translation.
I have to agree with the conservative people here that NAT is an added
layer of protection against configuration errors. I have once seen a
case where an accidental "allow all" was inserted into a stateful
packet filter, which caused a server with an official IP address that
was supposed to be "protected" by that packet filter to be r00ted in
no time. Had this server behind a NAT gateway with only tcp/80 DNATted
to the site local IP address of the server, this configuration error
wouldn't have been remotely as bad.
Greetings
Marc
Marc Haber
> On Fri, Jan 05, 2007 at 10:31:23AM -0800, Clenna Lumina wrote:
> > My last company I worked for was running IPSEC (VPN, etc) through their
> > (properly) NATed firewall without any problems.
>
> I guess that this was IPSEC tunnel mode. I specifically asked for
> IPSEC AH for a reason.
Additionally, even IPSEC in tunnel mode does not traverse NAT
naturally. There is a number of (mutually incompatible) mechanisms to
add NAT traversal to IPSEC (most of them using one or another kind of
UDP encapsulation), but since these are not well standardized, these
mechanisms are the main cause of the fact that IPSEC is a real pain to
get running if both sides of the connection are not made by the same
vendor.
IPSEC was supposed to be interoperable in between vendors just as IPv4
is. NAT has successfully broken this interoperability, and it has done
so while successfully making things look like it's all IPSECs fault.
Karl Auer
> I have to agree with the conservative people here that NAT is an added
> layer of protection against configuration errors. I have once seen a
> case where an accidental "allow all" was inserted into a stateful
> packet filter, which caused a server with an official IP address that
> was supposed to be "protected" by that packet filter to be r00ted in
> no time. Had this server behind a NAT gateway with only tcp/80 DNATted
> to the site local IP address of the server, this configuration error
> wouldn't have been remotely as bad.
How does that differ from misconfiguring a NAT to pass all incoming
connections to a particular machine?
NAT is not immune to misconfiguration. The default configuration is
typically conservative - as is the typical firewall config. You get in
there changing stuff, you have to be careful.
Marc Haber
> On Sat, 2007-01-06 at 10:25 +0100, Marc Haber wrote:
> > I have to agree with the conservative people here that NAT is an added
> > layer of protection against configuration errors. I have once seen a
> > case where an accidental "allow all" was inserted into a stateful
> > packet filter, which caused a server with an official IP address that
> > was supposed to be "protected" by that packet filter to be r00ted in
> > no time. Had this server behind a NAT gateway with only tcp/80 DNATted
> > to the site local IP address of the server, this configuration error
> > wouldn't have been remotely as bad.
>
> How does that differ from misconfiguring a NAT to pass all incoming
> connections to a particular machine?
Not much, but at least in the setup affected, configuring NAT is
a different step, so the same result would have needed the same
mistake at a different place.
But I agree that NAT is not a security measure.
Clenna Lumina
> On Fri, Jan 05, 2007 at 10:31:23AM -0800, Clenna Lumina wrote:
>>> On Thu, Jan 04, 2007 at 02:24:11PM -0800, Clenna Lumina wrote:
>>>> Mark Andrews wrote:
>>>>> For those of you who think NAT's are great try connecting
>>>>> to a port forwarded service from behind a NAT. I've yet
>>>>> to see a NAT box do this right. The NAT box should be
>>>>> able to loop the traffic around. Instead we are forced
>>>>> to kludge solutions to this in the DNS.
>>>>
>>>> No, a *properly* behaving NAT should always allow looping
>>>> back. If you are running a NAT that doesn't allow this,
>>>> then it is broken. You cannot put down NAT just because
>>>> of broken implimentations.
>>>
>>> Just show me how to do IPSEC AH via NAT. Or how to connect
>>> to a service that does RFC1413 ident lookups and actually does
>>> something with the returned value.
>>
>> My last company I worked for was running IPSEC (VPN, etc) through
>> their (properly) NATed firewall without any problems.
>
> I guess that this was IPSEC tunnel mode. I specifically asked for
> IPSEC AH for a reason.
AH (auth header), which can be part of an IPSEEC tunnel, does indeed
choke on most NATs, but it IS possible to get it to work, if a bit
tricky, and down right impossible on many forms of NAT.
>> Again, this is a difference between poor implimentations and the
>> concept your self. You're attacking the wrong one here.
>
> I am obviously "attacking" somebody who considers herself able to
> judge things that she has not the necessary background knowledge
> about. "It just works for me" is not enough.
Yet you are free to make assertions which are not always right. My my so
I'm not perfect. I never said I considered my self an ultimate authority
on all things. I know I'm not perfect. (Btw, I'm not a she, and it's
pronouned Clenn-aye (like a french sounding ending... just one of those
really weird names that dont sound like they are spelt.)
Furthur, I never claimed that if it was enough for me, ti was good
enough for all. I was pointing out that deficiencies you and other point
out in NAT are more do to poor implimentations than anything else, as
with the right NAT (and configuration) you can make it do neearly
anything you need.
Stop trying to brand all of one thing as poor when you have various
manufactures making completely defferent behaving versions.
>>> Even trying to have a mail server HELO with the right host
>>> name, regardless of whether the machine connected to is on the
>>> internal or an external network, is a challenge if NAT is in
>>> the game.
>>
>> I can't say I've ever seen that be a problem behind a NAT.
>
> Then you need to be around the block a few more times.
Or maybe I've just been using properly configured NATs instead of broken
or shoddy implimentations. Maybe I took the time to research and test
several before finding one that actually did things properly. Can you
say the same?
>> The HELO is usually generated by the address of the server the
>> connecitng mail server is trying to reach,
>
> No. Please read the RFCs before you continue embarrassing yourself
> even more.
I have read them before. I think you simply read what I wrote too
quickly. Foreign mail server connects. Foreigh server says HELO
remote-mail-host.domain.com, where remote-mail-host.domain.com IS being
generated from this connecting foreign host. This is how it's always
worked.
>> so if it's generating a bad HELO, then thats the fault of the
>> foreign mail server, which is likely not configured correctly to
>> begin with.
>>
>> My personal mail server which sits behind my home NAT, has never
>> failed to get a proper HELO from proper foreign hosts.
>
> It's the connecting server who says HELO, not the server connected to.
That *is* what I said - s/foreign/connecting/
" so if it's generating a bad HELO, then thats the fault of the
foreign mail server "
^^^^^^^
If you weren't so busy insulting everything I say you might have caught
this one.
>> Just to clear something up, when I said "turn your network world
>> upside down" I mean in the way you think about IP addresses and
>> the like, will be radically different. You can't tell me that
>> 11.22.33.44.55.66.77.88.99.AA.BB.CC.DD.EE.FF.00 is the same as
>> typing out 111.222.333.444 , be it in geenral speak or entering
>> into a conf file or passing along an IP to a friend for setting up
>> a friendly private Quake match.
>
>>> 1 is even shorter than 127.0.0.1.
>
> and 2001:1b18:f:4::4/128 is not _that_ bad. Yes, that's an actually
> workin address.
How does that equate to a full 16 octet IPv6 address? I'm not all the
keen on all forms of IPv6 ips, but I've never seen it written like you
have. If you can connect to an IP using a short hand like this (withotu
breaking anything) that would be great. It's a new concept to get used
to, but (if it pans out), a welcome one.
If you could suggest a good page to look at that desribes these sorts of
things, I would appreciate it.
>> Can you really tell me you can easily remember an address that long?
>> I can remebmer a 4 section IP with out any trouble. Remembering an
>> IPv6 address might be possible, no doubt, but you'd likely have to
>> known it rather well, and have a rather good memory.
>
> If DNS is properly used, you don't need to remember IPv6 addresses.
> And, usually, you only need to remember the prefix anyway.
Well you still need to enter them at _some_ point or another into DNS
(unless you used a $GENERATE to setup a whole block, and even then,
sometimes manual entries have to be added, ie: myhost.mydomain.com A ip
and ip PTR myhost.mydomain.com)
>> Actually a couple years ago, after hearing about IPv4 address slowly
>> becoming scarce, I actually sort of invisioned IPv4 being expanded
>> in a similar way telephone numbers were introduced into area codes
>> (and country codes) to furthur divide things. What I envisioned then
>> was anywhere for 1 to 4 extra sections (8 byte IPs.)
>
> Very good idea. Just another migration in ten years. I know people who
> have gone through four phone numbers in three different area codes in
> the last fifteen years.
>
> Geez, this is _one_ thing that we germans did right. No splits, no
> overlays. Only newly assigned numbers get longer. This is based on the
> convenient fact that our number length was never fixed in the first
> place, and we started making them longer long before the existing
> space was depleted so that we had ample _new_ number space to put into
> use which saved us from doing the splits.
Agreed, this approah IS much better :) This is basically wqhat I was
getting at.
On a side note (
While I like how the Germans did it, there is an
obvious benefit to using area codes, especially in a country the
size of the US. When you see a phone number with an area code,
you can easily deduce or determine where it may actually be located.
Germany is a much smaller country, so their method works well for
them. I don't think this method would of worked all that well in a
much larger country. however.
It's the old adage that one solution that works in one situation,
may not be the best solution in another.
In the case of the networking, I would favor a German-phone style
approach :)
)
>> When I first saw an IPv6, it immediately looked like over kill. Like
>> I said, I will be trying it on my own local network to get a real
>> feel
>> for it. On this note, are there any good documents out ther that
>> describe
>> what the general conventations are for IPv6 IPs? FOr instance, in
>> IPv4, 192.168/16, 172.16/12, 10/8, are considered LAN-only IP
>> blocks, 127/8 being loopback block.
>
> http://en.wikipedia.org/wiki/Ipv6 seems pretty good to me.
Thank you.
Marc Haber
> Marc Haber wrote:
> >> so if it's generating a bad HELO, then thats the fault of the
> >> foreign mail server, which is likely not configured correctly to
> >> begin with.
> >>
> >> My personal mail server which sits behind my home NAT, has never
> >
> > It's the connecting server who says HELO, not the server connected to.
>
>
> foreign mail server "
I am talking about connecting via SMTP to the outside. How is a server
behind NAT supposed to know which HELO to use when connecting to the
outside?
> > and 2001:1b18:f:4::4/128 is not _that_ bad. Yes, that's an actually
> > workin address.
>
> How does that equate to a full 16 octet IPv6 address? I'm not all the
> keen on all forms of IPv6 ips, but I've never seen it written like you
> have. If you can connect to an IP using a short hand like this (withotu
> breaking anything) that would be great. It's a new concept to get used
> to, but (if it pans out), a welcome one.
Quoting from Wikipedia:
IPv6 addresses are normally written as eight groups of four
hexadecimal digits. For example,
2001:0db8:85a3:08d3:1319:8a2e:0370:7334 is a valid IPv6 address.
If a four-digit group is 0000, the zeros may be omitted. For example,
2001:0db8:85a3:0000:1319:8a2e:0370:1337 can be shortened as
2001:0db8:85a3::1319:8a2e:0370:1337. Following this rule, any group of
consecutive 0000 groups may be reduced to two colons, as long as there
is only one double colon used in an address. Leading zeros in a group
can also be omitted. Thus, the addresses below are all valid and
equivalent:
2001:0db8:0000:0000:0000:0000:1428:57ab
2001:0db8:0000:0000:0000::1428:57ab
2001:0db8:0:0:0:0:1428:57ab
2001:0db8:0:0::1428:57ab
2001:0db8::1428:57ab
2001:db8::1428:57ab
Having more than one double-colon abbreviation in an address is
invalid, as it would make the notation ambiguous.
A sequence of 4 bytes at the end of an IPv6 address can also be
written in decimal, using dots as separators. This notation is often
used with compatibility addresses (see below). Thus, ::ffff:1.2.3.4 is
the same address as ::ffff:102:304.
Additional information can be found in RFC 4291 - IP Version 6
Addressing Architecture.
> If you could suggest a good page to look at that desribes these sorts of
> things, I would appreciate it.
The Wikipedia page on ipv6 is not that bad.
> >> Can you really tell me you can easily remember an address that long?
> >> I can remebmer a 4 section IP with out any trouble. Remembering an
> >> IPv6 address might be possible, no doubt, but you'd likely have to
> >> known it rather well, and have a rather good memory.
> >
> > If DNS is properly used, you don't need to remember IPv6 addresses.
> > And, usually, you only need to remember the prefix anyway.
>
> Well you still need to enter them at _some_ point or another into DNS
yes, once. And one is well advised to use cut&paste for ipv4 as well.
> While I like how the Germans did it, there is an
> obvious benefit to using area codes, especially in a country the
> size of the US. When you see a phone number with an area code,
> you can easily deduce or determine where it may actually be located.
Actually, we have area codes. They are longer for rural areas, and
shorter for the big cities, to allow the actual subscriber number to
vary in length according to the size of the local network.
Greetings
Marc
Sten Carlsen
enough) the lower 64bits are meant for the MAC-address, the rest is
useful as addresses.
This reduces the number of addresses from the very astronomical numbers
normally discussed to a 64 bit address space. This will probably be ok,
but claims of 128bit addressing are a little bit oversold.
What is the reason for this use of the lower 64 bits? Can you get rid of
ARP? Is this so much better than the self-assigned IPv4 addresses in use
today? On top of this, there are now attempts of hiding the MAC-address
to help privacy, which would otherwise be gone.
I still doubt if IPv6 is really as good as promised, it may be good
enough though.
Marc Haber wrote:
> On Sat, Jan 06, 2007 at 11:15:32AM -0800, Clenna Lumina wrote:
>
>> Marc Haber wrote:
>>
>>>> so if it's generating a bad HELO, then thats the fault of the
>>>> foreign mail server, which is likely not configured correctly to
>>>> begin with.
>>>>
>>>> My personal mail server which sits behind my home NAT, has never
>>>> failed to get a proper HELO from proper foreign hosts.
>>>>
>>> It's the connecting server who says HELO, not the server connected to.
>>>
>> That *is* what I said - s/foreign/connecting/
>>
>> " so if it's generating a bad HELO, then thats the fault of the
>> foreign mail server "
>> ^^^^^^^
>>
>
> I am talking about connecting via SMTP to the outside. How is a server
> behind NAT supposed to know which HELO to use when connecting to the
> outside?
>
>
>>> and 2001:1b18:f:4::4/128 is not _that_ bad. Yes, that's an actually
>>> workin address.
>>>
>>>> Can you really tell me you can easily remember an address that long?
>>>> I can remebmer a 4 section IP with out any trouble. Remembering an
>>>> IPv6 address might be possible, no doubt, but you'd likely have to
>>>> known it rather well, and have a rather good memory.
>>>>
>>> If DNS is properly used, you don't need to remember IPv6 addresses.
>>> And, usually, you only need to remember the prefix anyway.
>>>
>> Well you still need to enter them at _some_ point or another into DNS
>>
>
> yes, once. And one is well advised to use cut&paste for ipv4 as well.
>
>
>> While I like how the Germans did it, there is an
>> obvious benefit to using area codes, especially in a country the
>> size of the US. When you see a phone number with an area code,
>> you can easily deduce or determine where it may actually be located.
>>
>
> Actually, we have area codes. They are longer for rural areas, and
> shorter for the big cities, to allow the actual subscriber number to
> vary in length according to the size of the local network.
>
> Greetings
> Marc
>
>
--
Marc Haber
> As for 128bit adressing; as far as I can see (which may not be far
> enough) the lower 64bits are meant for the MAC-address, the rest is
> useful as addresses.
It is common to use the MAC address, but one can use arbitrary numbers
as well. Which comes in handy for an actual service which should not
have its IP change when it moves to different hardware.
> What is the reason for this use of the lower 64 bits? Can you get rid of
> ARP? Is this so much better than the self-assigned IPv4 addresses in use
> today? On top of this, there are now attempts of hiding the MAC-address
> to help privacy, which would otherwise be gone.
It allows autoconfiguration. And why does one want to hide the MAC
address? Knowing it does only help an attacker on the local network,
and who is on the local network knows it anyway.
Greetings
Marc
Sten Carlsen
Marc Haber wrote:
> On Sat, Jan 06, 2007 at 09:55:25PM +0100, Sten Carlsen wrote:
>
>> As for 128bit adressing; as far as I can see (which may not be far
>> enough) the lower 64bits are meant for the MAC-address, the rest is
>> useful as addresses.
>>
>
> It is common to use the MAC address, but one can use arbitrary numbers
> as well. Which comes in handy for an actual service which should not
> have its IP change when it moves to different hardware.
>
That was one of my points, I don't see the idea of changing all DNS
entries just because oone NIC burnt out and was replaced. Good that we
can avoid that.
>
>> What is the reason for this use of the lower 64 bits? Can you get rid of
>> ARP? Is this so much better than the self-assigned IPv4 addresses in use
>> today? On top of this, there are now attempts of hiding the MAC-address
>> to help privacy, which would otherwise be gone.
>>
>
> It allows autoconfiguration. And why does one want to hide the MAC
> address? Knowing it does only help an attacker on the local network,
> and who is on the local network knows it anyway.
>
I for one don't need any manufacturer knowing what I use my purchase for
and where. For almost all traditional applications I have no big issue.
For some of those to come, I am not so sure; I can imagine a host of
"services" I will not want, all based on the manufacturer tracking his
own devices.
For autoconfigurations, yes, it is nice to be able to do that with no
effort other than copying the MAC to the IP. Is that worth 64bits to be
transmitted everywhere? I don't see any other value in those bits; at
least if the world is autoconfigured. If that is not the case we still
have two classes of addresses: public and private; the low 64 bits still
do little for addressing as I see it. Maybe I still need more details?
Mark Andrews
> > What is the reason for this use of the lower 64 bits? Can you get rid of
> > ARP?
IPv6 doesn't use ARP.
> Is this so much better than the self-assigned IPv4 addresses in use
> > today? On top of this, there are now attempts of hiding the MAC-address
> > to help privacy, which would otherwise be gone.
>
> It allows autoconfiguration. And why does one want to hide the MAC
> address? Knowing it does only help an attacker on the local network,
> and who is on the local network knows it anyway.
>
> Greetings
> Marc
Privacy addresses are there primarially for machines that
move between networks. They prevent tracking of the machine
by looking at the bottom 64 bits. They also help somewhat
when a machine stays on the same network. You don't know
if it is the same person making connections or different
people.
> --
> -----------------------------------------------------------------------------
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
> Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
>
>
Karl Auer
> have two classes of addresses: public and private; the low 64 bits still
> do little for addressing as I see it. Maybe I still need more details?
Hm. So having several million trillion addresses PER SUBNET (2^64) still
isn't enough for you?
Sten Carlsen
Karl Auer wrote:
> On Sat, 2007-01-06 at 23:08 +0100, Sten Carlsen wrote:
>
>> have two classes of addresses: public and private; the low 64 bits still
>> do little for addressing as I see it. Maybe I still need more details?
>>
>
> Hm. So having several million trillion addresses PER SUBNET (2^64) still
> isn't enough for you?
>
YES, if they were available. Since they are used for the MAC address
reall life will provide only ONE out of those 2^64.
MAC addresses are supposed to be unique so only one out of the possible
addresses will be used; except if privacy addresses are being taken into
account.
Or is there still something I have missed?
> Regards, K.
Sten Carlsen
Mark Andrews wrote:
>>> What is the reason for this use of the lower 64 bits? Can you get rid of
>>> ARP?
>>>
>
> IPv6 doesn't use ARP.
>
How does it work in case of privacy addresses? In that case the MAC
address is not part of the IP-address.
>
>> Is this so much better than the self-assigned IPv4 addresses in use
>>
>>> today? On top of this, there are now attempts of hiding the MAC-address
>>> to help privacy, which would otherwise be gone.
>>>
>> It allows autoconfiguration. And why does one want to hide the MAC
>> address? Knowing it does only help an attacker on the local network,
>> and who is on the local network knows it anyway.
>>
>> Greetings
>> Marc
>>
>
> Privacy addresses are there primarially for machines that
> move between networks. They prevent tracking of the machine
> by looking at the bottom 64 bits. They also help somewhat
> when a machine stays on the same network. You don't know
> if it is the same person making connections or different
> people.
>
>
>> --
>> -----------------------------------------------------------------------------
>> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
>> Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
>> Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
>>
>>
>>
--
Mark Andrews
> Mark Andrews wrote:
> >>> What is the reason for this use of the lower 64 bits? Can you get rid of
> >>> ARP?
> >>>
> >
> > IPv6 doesn't use ARP.
> >
> How does it work in case of privacy addresses? In that case the MAC
> address is not part of the IP-address.
This is getting way to complicated for this list. I suggest that
you actually do some research. It really is not hard.
http://www.ietf.org/html.charters/ipv6-charter.html
Will give you the full set of RFC's which describe how IPv6 works.
That's over 10 years of work.
The replacement for ARP is Neigbour Discovery. Also see "Duplicate
Address Detection". MAC's are used because they are supposed to be
globally unique.
You don't have to use MAC's. You don't have use /64 as your netmask.
IPv6 allows you to use any length you want provided it is in range.
/64 was just convenient for as is supports both 64 and 48 bit MAC's
which is what autoconf uses to set the local part of the addresses.
Mark
Karl Auer
> > Hm. So having several million trillion addresses PER SUBNET (2^64) still
> > isn't enough for you?
> >
> YES, if they were available. Since they are used for the MAC address
> reall life will provide only ONE out of those 2^64.
?!? You can put as many addresses as you want on one interface - the MAC
address stuff is only for stateless autoconfiguration. Much more
importantly, you can have 2^64 different hosts (or 2^64 different
interfaces) in a single subnet - more if you extend your host part beyon
64 bits. That is more addresses than there are MAC addresses - more IP
addresses than there are *possible* MAC addresses...
Perhaps I misunderstand your point. What exactly is the problem as you
see it?
> MAC addresses are supposed to be unique so only one out of the possible
> addresses will be used; except if privacy addresses are being taken into
> account.
There is no problem at all with you and me sharing a MAC address as long
as we have a router between us...
Sten Carlsen
Karl Auer wrote:
> On Sun, 2007-01-07 at 00:15 +0100, Sten Carlsen wrote:
>
>>> Hm. So having several million trillion addresses PER SUBNET (2^64) still
>>> isn't enough for you?
>>>
>>>
>> YES, if they were available. Since they are used for the MAC address
>> reall life will provide only ONE out of those 2^64.
>>
>
> ?!? You can put as many addresses as you want on one interface - the MAC
> address stuff is only for stateless autoconfiguration. Much more
> importantly, you can have 2^64 different hosts (or 2^64 different
> interfaces) in a single subnet - more if you extend your host part beyon
> 64 bits. That is more addresses than there are MAC addresses - more IP
> addresses than there are *possible* MAC addresses...
>
> Perhaps I misunderstand your point. What exactly is the problem as you
> see it?
>
I agree, I was too quick.
>
>> MAC addresses are supposed to be unique so only one out of the possible
>> addresses will be used; except if privacy addresses are being taken into
>> account.
>>
>
> There is no problem at all with you and me sharing a MAC address as long
> as we have a router between us...
>
As long as MAC-addresses are unique we will not share them. Even if I
have 1000 devices I "waste" 50+ bits; I guess that this is just my
natural tendency to not overdo field lengths and not transmit too many
bits, but also not too few. Network bandwidth is becoming cheaper so it
matters less.
My main concern will still be privacy. Let that rest for now, it will
not be any different whatever I say, I will have to learn to work with
it. :-)
> Regards, K.
Sten Carlsen
> Sten Carlsen wrote:
>
>> Mark Andrews wrote:
>>
>>> This is a classic example of applying a IPv4 solution to a
>>> IPv6 network.
>>>
>>>
>> This is very likely, it probably takes some time and effort with the
>> thing in real life too get a feel for what is possible and what is
>> "natural" for any new system. This underlines that transition from IPv4
>> to IPv6 is not just more bits, but rather completely new ways to think.
>>
>>> address translation.
>>>
>> IPv4 network. Isolation and hiding. If other mechanisms, not known in
>> IPv4 networks, can provide that, it is fine with me.
>>
>
> surprised if it also breaks DNSSEC.
>
I don't see NAT as the wondercure of all times. It breaks a number of
things, but it also by default breaks access to internal PCs that should
not be accessible from outside. I.e. the default is that automatic
probes will miss the unprotected systems; one less infection risk. It
does not provide real protection against real attacks, a correctly
configured firewall would to a much higher degree.
NAT has good and bad sides. For most private users I will say that the
good sides outweigh the bad sides, YMMV.
>
>> For some things I want that they can initiate a connection to the net,
>> but are hidden so NO connection can be made from the outside to those
>> devices. How can that be achieved without NAT in an IPv6 system?
>>
>>> A statefull firewall is just as good
>>> at providing protection and doesn't have the down sides
>>> introduced as a side effect of the port / address translation.
>>>
>>>
>> I will take your word for that, I still feel there might be more risk.
>> That could be missing time and effort on my side. On the other side that
>> suggests a lot of misconfigured firewalls in the future until people
>> learn how to do it. "A hackers paradise"?
>>
>
> Nothing is going to fix misconfigured firewalls except the people
> responsible for maintaining them. If the firewall is misconfigured don't
> expect the NAT to be set up properly either. This very much sounds like
> security by ignorance. How are you safer?
>
I am not thinking about sites with a dedicated and knowledgeable system
administrator, here I can expect understanding and proper setup. I am
thinking about all the ADSL connections where people hardly will be
aware of what things they have that can acess the net in the future.
Many of the botnets today are created by using automatic probes that
infect unprotected PCs without users knowing about it.
Any small router you buy for about $50 will by default make access by
automatic probes impossible, you have to manually misconfigure it to
have that risk.
The knowledge and effort it takes to setup a firewall is much greater
than what I expect the normal ADSL user to have. I expect many of the
future appliances to try to open a hole in the firewall for themselves
so they can communicate with their maker for updates and market
research, also opening for hackers, I will not expect the things to
allow me to set their network configuration manually the risk of me
breaking what the manufacturer wants to do is far too big; will future
botnets be composed from refrigerators?
>
>>> If you don't want there to be any path to the equipment
>>> don't let it use a global prefix. Use a link local or a
>>> locally assigned local addresses if you have more than one
>>> internal network.
>>>
>>>
>> Does that mean that a local DHCP server is needed? Or is a fixed address
>> the best way?
>> This is an example of what could be the misunderstandings that create
>> this kind of debate, it also underlines that the transition is NOT
>> simple as has been said.
>>
>
> It really is that simple. Programmers have so substitute some slightly
> different functions and structures for the old IPv4 only structures but
> the new ones handle both transparently.
>
I was thinking of normal peoples understanding, not programmers or
admins. I worry that in too many cases functionality comes before
security; everything works by default and you have to close holes by
yourself, not the other way round. Windows is a good example for all to
follow it would seem; functions break holes in firewalls if they want
them without asking users already now.
>
>>> Remember a IPv6 node will often have 3 or more addresses
>>> on each NIC.
>>>
>>>
>> That worries me a bit, I guess that will resolve itself as IPv6 becomes
>> more common in discussions.
>>
>
> Why? The different addresses just make routing easier.
>
That is both good and bad, see above.
> Danny
Mark Andrews
> Danny Mayer wrote:
> > Sten Carlsen wrote:
> >
> >> Mark Andrews wrote:
> >>
> >>> This is a classic example of applying a IPv4 solution to a
> >>> IPv6 network.
> >>>
> >>>
> >> This is very likely, it probably takes some time and effort with the
> >> thing in real life too get a feel for what is possible and what is
> >> "natural" for any new system. This underlines that transition from IPv4
> >> to IPv6 is not just more bits, but rather completely new ways to think.
> >>
> >>> I really don't see why people insist that they need port /
> >>> address translation.
> >>>
> >> I don't necessarily want that, I want the effects that it gives in an
> >> IPv4 network. Isolation and hiding. If other mechanisms, not known in
> >> IPv4 networks, can provide that, it is fine with me.
> >>
> >
> > NAT breaks NTP authentication, among other things. I wouldn't be
> > surprised if it also breaks DNSSEC.
> >
> I don't see NAT as the wondercure of all times. It breaks a number of
> things, but it also by default breaks access to internal PCs that should
> not be accessible from outside. I.e. the default is that automatic
> probes will miss the unprotected systems; one less infection risk. It
> does not provide real protection against real attacks, a correctly
> configured firewall would to a much higher degree.
>
> NAT has good and bad sides. For most private users I will say that the
> good sides outweigh the bad sides, YMMV.
An a stateful firewall will do exactly the same thing.
A nat is a stateful firewall + port/address modification.
Unless you are doing one-to-one NAT, a nat box has to keep
state to enable it to send packets back to the originating
host. That is a super-set of the state a stateful firewall
would have to provide exactly the same protection.
> >> For some things I want that they can initiate a connection to the net,
> >> but are hidden so NO connection can be made from the outside to those
> >> devices. How can that be achieved without NAT in an IPv6 system?
> >>
> >>> A statefull firewall is just as good
> >>> at providing protection and doesn't have the down sides
> >>> introduced as a side effect of the port / address translation.
> >>>
> >>>
> >> I will take your word for that, I still feel there might be more risk.
> >> That could be missing time and effort on my side. On the other side that
> >> suggests a lot of misconfigured firewalls in the future until people
> >> learn how to do it. "A hackers paradise"?
> >>
> >
> > Nothing is going to fix misconfigured firewalls except the people
> > responsible for maintaining them. If the firewall is misconfigured don't
> > expect the NAT to be set up properly either. This very much sounds like
> > security by ignorance. How are you safer?
> >
> I am not thinking about sites with a dedicated and knowledgeable system
> administrator, here I can expect understanding and proper setup. I am
> thinking about all the ADSL connections where people hardly will be
> aware of what things they have that can acess the net in the future.
Many of the botnets today are created by using automatic probes that
> infect unprotected PCs without users knowing about it.
>
> Any small router you buy for about $50 will by default make access by
> automatic probes impossible, you have to manually misconfigure it to
> have that risk.
No. A router does not do that. A router w/ firewall does than.
A route w/ NAT does that. A router add zero protection.
This is a classic case of the consumer no knowing what is
being sold to them.
> The knowledge and effort it takes to setup a firewall is much greater
> than what I expect the normal ADSL user to have. I expect many of the
> future appliances to try to open a hole in the firewall for themselves
> so they can communicate with their maker for updates and market
> research, also opening for hackers, I will not expect the things to
> allow me to set their network configuration manually the risk of me
> breaking what the manufacturer wants to do is far too big; will future
> botnets be composed from refrigerators?
What a load of hogwash. SOHO NAT vendors could easily make a
equivalent SOHO firewall with almost the same gui as the NAT
box (default out any keep-state, in none).
> >>> If you don't want there to be any path to the equipment
> >>> don't let it use a global prefix. Use a link local or a
> >>> locally assigned local addresses if you have more than one
> >>> internal network.
> >>>
> >>>
> >> Does that mean that a local DHCP server is needed? Or is a fixed address
> >> the best way?
DHCP can provide fixed or dynamic addresses. It's all a matter
of configuration. For IPv6 you have the choice of fixed, DHCP
(fixed or dynamic) or autoconf (unknown fixed). Autoconf also
handles adding or removal of prefixes.
> >> This is an example of what could be the misunderstandings that create
> >> this kind of debate, it also underlines that the transition is NOT
> >> simple as has been said.
> >>
> >
> > It really is that simple. Programmers have so substitute some slightly
> > different functions and structures for the old IPv4 only structures but
> > the new ones handle both transparently.
> >
> I was thinking of normal peoples understanding, not programmers or
> admins. I worry that in too many cases functionality comes before
> security; everything works by default and you have to close holes by
> yourself, not the other way round. Windows is a good example for all to
> follow it would seem; functions break holes in firewalls if they want
> them without asking users already now.
> >
> >>> Remember a IPv6 node will often have 3 or more addresses
> >>> on each NIC.
> >>>
> >>>
> >> That worries me a bit, I guess that will resolve itself as IPv6 becomes
> >> more common in discussions.
> >>
> >
> > Why? The different addresses just make routing easier.
> >
> That is both good and bad, see above.
> > Danny
> >
>
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>
> "MALE BOVINE MANURE!!!"
>
>
Sten Carlsen
>> I really don't see why people insist that they need port / address
>> translation.
>>>>>
>>>>>
>>>> I don't necessarily want that, I want the effects that it gives in an
>>>> IPv4 network. Isolation and hiding. If other mechanisms, not known in
>>>> IPv4 networks, can provide that, it is fine with me.
>>>>
>>>>
>>> NAT breaks NTP authentication, among other things. I wouldn't be
>>> surprised if it also breaks DNSSEC.
>>>
>>>
>> I don't see NAT as the wondercure of all times. It breaks a number of
>> things, but it also by default breaks access to internal PCs that should
>> not be accessible from outside. I.e. the default is that automatic
>> probes will miss the unprotected systems; one less infection risk. It
>> does not provide real protection against real attacks, a correctly
>> configured firewall would to a much higher degree.
>>
>> NAT has good and bad sides. For most private users I will say that the
>> good sides outweigh the bad sides, YMMV.
>>
>
> An a stateful firewall will do exactly the same thing.
> A nat is a stateful firewall + port/address modification.
> Unless you are doing one-to-one NAT, a nat box has to keep
> state to enable it to send packets back to the originating
> host. That is a super-set of the state a stateful firewall
> would have to provide exactly the same protection.
>
>
>> administrator, here I can expect understanding and proper setup. I am
>> thinking about all the ADSL connections where people hardly will be
>> aware of what things they have that can acess the net in the future.
>>
> Many of the botnets today are created by using automatic probes that infect unprotected PCs without users knowing about it.
>
> Any small router you buy for about $50 will by default make access by
> automatic probes impossible, you have to manually misconfigure it to
> have that risk.
>
>
> No. A router does not do that. A router w/ firewall does than.
> A route w/ NAT does that. A router add zero protection.
>
> This is a classic case of the consumer no knowing what is
> being sold to them.
>
routers sold today at about $50 do include NAT. They are all designed to
allow more than one computer to connect via an ADSL-connection, so NAT
is needed for that. Meaning that all small routers include NAT with what
is now a standard setup.
>
>
>> The knowledge and effort it takes to setup a firewall is much greater
>> than what I expect the normal ADSL user to have. I expect many of the
>> future appliances to try to open a hole in the firewall for themselves
>> so they can communicate with their maker for updates and market
>> research, also opening for hackers, I will not expect the things to
>> allow me to set their network configuration manually the risk of me
>> breaking what the manufacturer wants to do is far too big; will future
>> botnets be composed from refrigerators?
>>
>
> What a load of hogwash. SOHO NAT vendors could easily make a
> equivalent SOHO firewall with almost the same gui as the NAT
> box (default out any keep-state, in none).
>
them to grasp the NAT and do that correctly (well mostly). My point is
that during the transition we will see a lot of "interesting" solutions.
>
>
>>>>> If you don't want there to be any path to the equipment
>>>>> don't let it use a global prefix. Use a link local or a
>>>>> locally assigned local addresses if you have more than one
>>>>> internal network.
>>>>>
>>>>>
>>>>>
>>>> Does that mean that a local DHCP server is needed? Or is a fixed address
>>>> the best way?
>>>>
>
> DHCP can provide fixed or dynamic addresses. It's all a matter
> of configuration. For IPv6 you have the choice of fixed, DHCP
> (fixed or dynamic) or autoconf (unknown fixed). Autoconf also
> handles adding or removal of prefixes.
>
>
>>>> This is an example of what could be the misunderstandings that create
>>>> this kind of debate, it also underlines that the transition is NOT
>>>> simple as has been said.
>>>>
>>>>
>>> It really is that simple. Programmers have so substitute some slightly
>>> different functions and structures for the old IPv4 only structures but
>>> the new ones handle both transparently.
>>>
>>>
>> I was thinking of normal peoples understanding, not programmers or
>> admins. I worry that in too many cases functionality comes before
>> security; everything works by default and you have to close holes by
>> yourself, not the other way round. Windows is a good example for all to
>> follow it would seem; functions break holes in firewalls if they want
>> them without asking users already now.
>>
always be the ones actually used. Those who implement network units will
listen more to he, who pays the bill than to those who wrote the standards.
Let us close this discussion at least on this list, what ever we say,
things are not changing because of that. I believe we have all gained a
little knowledge about other sides of things, let's try to use that to
make things actually work.
Edward Lewis
>Edward Lewis wrote:
>> 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.
>
>I'm just curious, what sort of problems does DNS have behind NAT in your
>experience? I'm running Bind 9 behind a NAT that both manages a couple
>domains I own and acts as the main DNS server for my tiny network, thus
>queries going either way - seeking athorative answeres for the domains I
>own, and the other way seeking google.com, etc - without any problems.
I haven't seen any...I mentioned DNS as an example of a protocol that
relies on lower layer identifiers (particularly in query processing).
>What I think could be a solution would be to have IPv6 became the main
>protocol, with IPv4 transparrently "existing" within it, so to speak,
>for backwards compatibility, I'd imagine no programs that rely on IPv4
>would have to be rewritten.
I can't think of any technological transition (computer network or
otherwise) that used the new method to convey the old during
transition, it has always been the other way around. One of the
failings of failed technologies is their failure to have a transition
plan that relied on bootstrapping from old to new. I first thought
this in the early 90's when looking at ATM, which assumed everything
would be cell-based and that there was no need for it to sit
side-by-side with packet technology, instead, there would be an
adaptation layer.
Successful transitions do feature carrying old in new, but that is
after the new technology is well established and the old is in its
sunset.
>Say every ISP in the world just switches over to IPv6.
There's an expression that captures my reaction to that assertion -
"First boil the ocean." I.e., ISP's can "just switch" over to IPv6.
ISPs are cash poor for two reasons - going into debt in the boom era
has them reeling and data tranist is a commodity service. There is
no wood to light a big enough fire to boil an ocean-sized pot of
water.
>In fact, I'm actually suprised the designers of IPv6 didn't do this.
>(Well, if they actually did, then I apologize, though I can find no info
>on that.)
THey didn't, they did draw up IPv6 in IPv4 because that could work.
IPv6 would be hobbled but IPv4 could carry it around. Putting IPv4
into IPv6 would be like putting cars into boats and trying to cross a
mountain.
Edward Lewis
> 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.
The "fault" lies in violating layering. But this isn't "fault" as in
"you are guilty of a crime against humanity" but a "fault" like
failing to anticipate the future correctly.
I once marvelled at a very simplistic Mac application that was
written in 1985 or 1986 called "RoadAtlas". If calculated routes and
distances along US interstate highways and other major roads between
US cities. It ran on every Mac platform up through Mac 9, and then
on pre-Intel Macs using version 9 emulation in MacOS X. On the other
hand, there were many "professionally" written applications that
would run on Mac 5.4 but not a newer version.
Sometimes something is so perfectly written, or solves a problem so
tightly constrained, it can last into the future.
> No. It mean that if you have legacy code it needs a minor
> re-write. Something that most programers could do in a
> afternoon.
Assuming that you are a programmer. Not many are.
> 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.
Both have issues, but the problems in IPv4 are already known and
being dealt with. IPv6 issues are new and there is fear about them.
I'm referring to the sentiment of last April when the North American
RIR supported allotting "provider independent" address space over the
objections of both ISPs and IETF protocol designers.
They issues are not roughly the same. IPv4 has already burned the
bridge and because of the smaller size of the address space, ISPs are
not afraid. IPv6 hasn't ventured far into the swamp. If you want to
see what makes ISP afraid and why I think they have reason to fear
this, there are some presentations given by a Jason Schiller of MCI
at ARIN and NANOG meetings.
> 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.
I don't think that applying IPv4 techniques to IPv6 is a "problem"
but a design constraint. People who get used to one way of doing
business don't what to have to relearn new tricks for an upgrade.
Not every one using the Internet is a network engineer.
> NAT is a IPv4 solution to a IPv4 problem. IPv6 eliminates
> the need to do NAT.
Probably so, but there has been resistance to DHCPv6, saying that it
is a vestige of IPv4 not needed in an autoconfiguring world. (That
is something network managers beg to differ on, they like the DHCP
style control they have now.)
Clenna Lumina
>> Marc Haber wrote:
>> >> so if it's generating a bad HELO, then thats the fault of the
>> >> foreign mail server, which is likely not configured correctly to
>> >> begin with.
>> >>
>> >> My personal mail server which sits behind my home NAT, has never
>> >> failed to get a proper HELO from proper foreign hosts.
>> >
>> > It's the connecting server who says HELO, not the server connected
>> > to.
>>
>> That *is* what I said - s/foreign/connecting/
>>
>> " so if it's generating a bad HELO, then thats the fault of the
>> foreign mail server "
>> ^^^^^^^
>
> I am talking about connecting via SMTP to the outside. How is a server
> behind NAT supposed to know which HELO to use when connecting to the
> outside?
If it's connecting to the outside, it would already know which one (the
domain of the mail it's sending to the destination server, of course...
it's not exactly magic.) As I've already told you, I've run mail servers
*behind* (and still do, even my private one on my home network) and
NEVER had any issues.
You're once again confusing NAT itself with bad implimentations. Your
way of thinking is just like people who think all modern SUVs are poor
off road vehicles with bad gas milage, when there are a few that do
perform exceptionally well off road and have much better fual economy.
Thank you, this helps a lot :)
> Having more than one double-colon abbreviation in an address is
> invalid, as it would make the notation ambiguous.
How so? If such a notation means zero, wouldn't
2001:db8:::1428:57ab
just essentially translate to
2001:db8:0000:0000::1428:57ab
I mean, it would seem pointless of course, although I don't think it
would be ambiguous if they amount to zero (in other words I would of
thought extra pairs would be essentially discarded in a manner, as they
wouldn't really make a difference.
> A sequence of 4 bytes at the end of an IPv6 address can also be
> written in decimal, using dots as separators. This notation is often
> used with compatibility addresses (see below). Thus, ::ffff:1.2.3.4 is
> the same address as ::ffff:102:304.
Nice. That is exactly what I was hoping for, some way of using old
adddresses (and with compatibility, may I assume you mean mapping to
IPv4 equivlents of the DEC portion (for a IPv4 IP within an IPv6 space
?)
> Additional information can be found in RFC 4291 - IP Version 6
> Addressing Architecture.
Thank you.
>> If you could suggest a good page to look at that desribes these sorts
>> of
>> things, I would appreciate it.
>
> The Wikipedia page on ipv6 is not that bad.
True.
>> >> Can you really tell me you can easily remember an address that
>> >> long?
>> >> I can remebmer a 4 section IP with out any trouble. Remembering an
>> >> IPv6 address might be possible, no doubt, but you'd likely have to
>> >> known it rather well, and have a rather good memory.
>> >
>> > If DNS is properly used, you don't need to remember IPv6 addresses.
>> > And, usually, you only need to remember the prefix anyway.
>>
>> Well you still need to enter them at _some_ point or another into DNS
>
> yes, once. And one is well advised to use cut&paste for ipv4 as well.
No arguement there.
>> While I like how the Germans did it, there is an
>> obvious benefit to using area codes, especially in a country the
>> size of the US. When you see a phone number with an area code,
>> you can easily deduce or determine where it may actually be
>> located.
>
> Actually, we have area codes. They are longer for rural areas, and
> shorter for the big cities, to allow the actual subscriber number to
> vary in length according to the size of the local network.
I see. Not a bad system. I would not say either the German or US system
is right or wrong, as they oth seem to serve a purpose, though I find
the German system appears to scale better.
Marc Haber
> >> Marc Haber wrote:
> >> >> so if it's generating a bad HELO, then thats the fault of the
> >> >> foreign mail server, which is likely not configured correctly to
> >> >> begin with.
> >> >>
> >> >> My personal mail server which sits behind my home NAT, has never
> >> >> failed to get a proper HELO from proper foreign hosts.
> >> >
> >> > It's the connecting server who says HELO, not the server connected
> >> > to.
> >>
> >> That *is* what I said - s/foreign/connecting/
> >>
> >> " so if it's generating a bad HELO, then thats the fault of the
> >> foreign mail server "
> >> ^^^^^^^
> >
> > I am talking about connecting via SMTP to the outside. How is a server
> > behind NAT supposed to know which HELO to use when connecting to the
> > outside?
>
> If it's connecting to the outside, it would already know which one (the
> domain of the mail it's sending to the destination server, of course...
> it's not exactly magic.)
A server connecting to the outside gives its own host name as
parameter to the HELO command. See here a transcript of sending a
message from nechayev.zugschlus.de to torres.zugschlus.de:
$ swaks --to mh+bin...@zugschlus.de --from mh+bin...@zugschlus.de --server torres.zugschlus.de
=== Trying torres.zugschlus.de:25...
=== Connected to torres.zugschlus.de.
<- 220 torres.zugschlus.de ESMTP Exim 4.64 Sat, 13 Jan 2007 13:43:37 +0100
-> EHLO nechayev.zugschlus.de
<- 250-torres.zugschlus.de Hello nechayev.zugschlus.de [85.214.68.41]
<- 250-SIZE 20971520
<- 250-PIPELINING
<- 250-STARTTLS
<- 250 HELP
-> MAIL FROM:<mh+bin...@zugschlus.de>
<- 250 OK
-> RCPT TO:<mh+bin...@zugschlus.de>
<- 250 Accepted
-> DATA
<- 354 Enter message, ending with "." on a line by itself
-> Date: Sat, 13 Jan 2007 13:43:37 +0100
-> To: mh+bin...@zugschlus.de
-> From: mh+bin...@zugschlus.de
-> Subject: test Sat, 13 Jan 2007 13:43:37 +0100
-> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
->
-> This is a test mailing
->
-> .
<- 250 OK id=1H5iEv-0006t0-7O
-> QUIT
<- 221 torres.zugschlus.de closing connection
=== Connection closed with remote host.
$
Some receiving servers check whether the HELO/EHLO name presented to
them matches the reverse DNS entry of the IP that is used to connect
from and use this as input to spam scoring techniques, thus it is
important that the connecting server knows which IP the remote side
will see to issue the correct HELO/EHLO parameter. This is trivial
(look it up in the DNS) as long as no NAT is in the game - if NAT is
in the game, the connecting server behind NAT needs to be aware of
which IP address this particular connectio will be NATted to. Which at
least involves some extra configuration and is even harder if the
NATted-to IP address is a dynamic one.
> As I've already told you, I've run mail servers *behind* (and still
> do, even my private one on my home network) and NEVER had any issues.
>
> You're once again confusing NAT itself with bad implimentations.
NAT is evil because rarely anybody gets it completely right because it
is awfully hard to get right. How do you configure your outgoig mail
server to issue the correct HELO/EHLO name?
> > Having more than one double-colon abbreviation in an address is
> > invalid, as it would make the notation ambiguous.
>
> How so? If such a notation means zero, wouldn't
> 2001:db8:::1428:57ab
> just essentially translate to
> 2001:db8:0000:0000::1428:57ab
>
> I mean, it would seem pointless of course, although I don't think it
> would be ambiguous if they amount to zero (in other words I would of
> thought extra pairs would be essentially discarded in a manner, as they
> wouldn't really make a difference.
I reckon that 2001:db8:::1428:57ab would be equivalent to
2001:db8::1428:57ab, and fully expand to
2001:0db8:0000:0000:0000:0000:1428:57ab.
> > A sequence of 4 bytes at the end of an IPv6 address can also be
> > written in decimal, using dots as separators. This notation is often
> > used with compatibility addresses (see below). Thus, ::ffff:1.2.3.4 is
> > the same address as ::ffff:102:304.
>
> Nice. That is exactly what I was hoping for, some way of using old
> adddresses (and with compatibility, may I assume you mean mapping to
> IPv4 equivlents of the DEC portion (for a IPv4 IP within an IPv6 space
> ?)
An IPv6 aware service will see an IPv4 connection from a.b.c.d as
::ffff:a.b.c.d. This has caused a little grief in the past when a
supposedly minor software upgrade to a remote box suddenly made it
IPv6 aware, the IPv4 addresses in /etc/hosts.allow didn't match any
more and the box started to reject the management ssh connections.
> >> While I like how the Germans did it, there is an
> >> obvious benefit to using area codes, especially in a country the
> >> size of the US. When you see a phone number with an area code,
> >> you can easily deduce or determine where it may actually be
> >> located.
> >
> > Actually, we have area codes. They are longer for rural areas, and
> > shorter for the big cities, to allow the actual subscriber number to
> > vary in length according to the size of the local network.
>
> I see. Not a bad system. I would not say either the German or US system
> is right or wrong, as they oth seem to serve a purpose, though I find
> the German system appears to scale better.
It causes some grief for international operators, as I have been
recently informed in private mail.
Greetings
Marc
Paul Colquhoun
> > On Sat, Jan 06, 2007 at 11:15:32AM -0800, Clenna Lumina wrote:
> >> Marc Haber wrote:
> > Quoting from Wikipedia:
> >
> > IPv6 addresses are normally written as eight groups of four
> > hexadecimal digits. For example,
> > 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 is a valid IPv6 address.
> >
> > If a four-digit group is 0000, the zeros may be omitted. For
> > example,
> > 2001:0db8:85a3:0000:1319:8a2e:0370:1337 can be shortened as
> > 2001:0db8:85a3::1319:8a2e:0370:1337. Following this rule, any group
> > of consecutive 0000 groups may be reduced to two colons, as long as
> > there is only one double colon used in an address. Leading zeros in
> > a group can also be omitted. Thus, the addresses below are all valid
> > and equivalent:
> >
> > 2001:0db8:0000:0000:0000:0000:1428:57ab
> > 2001:0db8:0000:0000:0000::1428:57ab
> > 2001:0db8:0:0:0:0:1428:57ab
> > 2001:0db8:0:0::1428:57ab
> > 2001:0db8::1428:57ab
> > 2001:db8::1428:57ab
>
> Thank you, this helps a lot :)
>
> > Having more than one double-colon abbreviation in an address is
> > invalid, as it would make the notation ambiguous.
>
> How so? If such a notation means zero, wouldn't
> 2001:db8:::1428:57ab
> just essentially translate to
> 2001:db8:0000:0000::1428:57ab
The problem with more than one '::' in an IPv6 address happens when they
are separated.
What is the full version of the following address?
2001:db8::1428::57ab ?
is it 2001:0db8:0000:0000:1248:0000:5718
or is it 2001:0db8:0000:1248:0000:0000:5718 ?
--
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/~paulcol
Asking for technical help in newsgroups? Read this first:
http://catb.org/~esr/faqs/smart-questions.html#intro
Marc Haber
> The problem with more than one '::' in an IPv6 address happens when they
> are separated.
>
> What is the full version of the following address?
>
> 2001:db8::1428::57ab ?
undefined, I would say. Software seems to agree:
$ sudo ip addr add dev eth0 2001:db8::1428::57ab/128
Error: an inet prefix is expected rather than "2001:db8::1428::57ab/128".
$ sudo ip addr add dev eth0 2001:db8:1428::57ab/128
$ sudo ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:17:08:2e:59:87 brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:1428::57ab/128 scope global tentative
valid_lft forever preferred_lft forever
$