On 13/07/11 02:30, Laurence Hurst wrote:
> On Tue, Jul 12, 2011 at 04:09:27PM +0100, Scott Ferguson wrote:
>> Why not just use a single host file on your firewall/router?
>> <snipped>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I addition I need forward and reverse host-name lookups to function
> correctly across a variety of platforms which is easily achieved by
> running my own internal DNS with little more effort than a static
> hosts file which I then have to copy around a dozen machines (and
> spend time wondering why stuff broke when I forget one!).
>>
Just brush up on your reading skills and that problem will vanish. ;-p
I can think of a number of large networks that don't run internal DNS
servers - dynamic addresses are a pain to manage on a large scale, and
static addresses make DNS servers redundant on most private networks.
But them my motivation is not to increase the workload for the network
monkeys (I mean - valued, value-adding staff) :-D
>>>>
>>>> I am curious, if I wanted to translate my IPv4 configuration
>>>> into an IPv6 world; � * I know there's a lot of talk about
>>>> IPv6's wonderful auto-configuration eliminating the need for
>>>> DHCP but how does this work with a static DNS setup?
Read the internode links - the tunnel makes that redundant.
>>
>> Pretty much the same as the example above - just substitute an
>> IPv6 address. Debian is just waiting for you to feed it IPv6, ditto
>> for Windows 7, not so much for OSX, dunno about your embedded
>> devices.
>>
>> From what I've read the auto-configured address is NOT guaranteed
>> to be identical each time a machine is connected to the network
>> (e.g. turned on after being powered off for a period of time), just
>> unique to the network at the time it is configured. While in
>> practice IF the mac address of the NIC is used to generate the IPv6
>> address it may be the same,
A static address assigned by MAC is the same process whether by IPv4,5,
or 6.
Dynamic addressing is randomising.
>> the RFC[0] simply states it will be generated from an "interface
>> identifier" and makes specific reference to instances where the
>> identifier is not a "hardware address" which means that although
>> current convention seems to be to use the MAC address this is not
>> guaranteed. If the addresses are not guaranteed to be static
>> between connections to the network then surely a local static DNS
>> (or, indeed, hosts file) cannot guarantee to be reliable?
> [0] http://tools.ietf.org/html/rfc4862
I believe you've misinterpreted the context their. None of your concerns
were validated by the trials I looked at during IPv6 day where very
large WANs ran native IPv6 - but then those networks don't allow dynamic
addresses (or bluetooth, or wireless). Again - I'd encourage you to read
the internode guides I linked rather than just one of over a dozen RFCs,
which only cover the basics.
>
> <snip />
>>>> � * In the DHCP-less world, how would clients "discover" the
>>>> local DNS suffix (e.g. (fictitous) "internal.home.my.tld")?
hostname?
/hosts file?
\hosts file?
\lmhosts file?
And - what DHCP-less world?
>>
>> It will depend on what methods your ISP provides
>>
> I'm talking about DNS which exists entirely within my private network
> and has nothing to do with my isp. Currently my DHCP server hands out
> my DNS server's details and the search domain (for the sake of
> argument 'internal.home.my.tld). The configured clients then use my
> DNS for all their DNS lookups - my server is configured to be
> authoritative for hosts on my network, within my subdomain
> ('internal.home.my.tld') and for reverse lookups on 192.168.0.0/24
> addresses (and on it's other subnets, but let's not over-complicate
> here) and forwards any other request upstream to my ISPs DNS servers.
> It's the DNS bit contained in my network that I'm unclear on.
It's your network - you can make it as complicated as you want. But if
you have a compelling reason to use DHCP to hand out dynamic addresses
I've missed it. A central hosts file and static addresses make the
question redundant.
>> But it's really too early to determine what can be done with what
>> the ISPs will provide, until the ISPs provide it.
>>
>> For some current real world implementations try:-
>> http://ipv6.internode.on.net/configuration/
>> http://ipv6.internode.on.net/access/tunnel-broker/
>>
>> NOTE: your region and ISPs may offer different implementations, I
>> don't know how relevant the examples of Internode are as I've only
>> compared them to iiNet's offerings. As discussed in another thread
>> the big ISPs in my country have no plans for IPv6 in the
>> forseeable future. As in $43 billion for a National Broadband
>> network that doesn't support IPv6 :-(
>>
> <snip />
<snipped>
> Indeed, I think a lot of this is still to be figured out (there maybe
> a spec but how the large corporations choose to "interpret" it may
> have knock on impact for the rest of us).
Hence the links to "real-world" implementations for users like yourself
> I am more interested from an experimental point of view. I am only
> aware of using DHCP with DNS to achieve what I currently do wrt
> reliable, cross-device, forward and reverse host lookups but was
> wondering if there was a way to take advantage of IPv6's stateless
> configuration to get the same end. Looking at the research I've done
> so far it's not looking good since the stateless addresses are not
> guaranteed
I'm not aware of that. I'll allow that it's possible...
> - I found one document referring to Windows specifically randomising
> IPv6 addresses rather than using the MAC (no idea if this is default
> or configurable).
Microsoft embraced IPv6 privacy extensions, and that's there "extension"
of the privacy extensions! ;-p
If your ISP sells you a static address it's a static address - IPv6 or not.
>>
>> Cheers
>>
> Thanks Laurence
>
>
Cheers
--
"Eternal suffering awaits anyone who questions god's infinite love."
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1d7cf9.90...@gmail.com
