Hi,
My reply comes as a user of IPv6 and I have really no 'enterprise' deployment
experience of it yet. From what I have read and stumbled on has given me an
idea of how to go about doing things when the time comes, and so everything
here really can be poo-poo'ed straight off the bat and ignored :)
Bob Franklin <[log in to unmask]> [20070620 14:44:37 +0100]:
>
> No-one seems to have a solution to the EUI-64 and RFC3041 DNS problem; I
> think the policy that servers should be on static addresses (which are not
> EUI-64 based, but start at some nominal figure and work up, for example,
> and can be registered in the DNS to enable them to be found via that) and
> end-user devices that don't need to be referred to by name get some
> 'random' address (be it EUI-64 or RFC3041).
>
My personal feeling is that EUI-64 is really there to get a bunch of headless
boxes (or clueless users at home) very quickly onto the Internet and should
be kept as so.
When you want to start getting serious thats when 'fun' things like DHCPv6[1]
should start to be used, even if it is just to get a EUI-64-esque address
assigned.
> Traditionally, I would say that is 'bad form' to use unregistered
> addresses on the internet; as minimum, something like
> 'host-aa-bb-cc-dd-ee-ff-gg-hh.inst.cam.ac.uk' would be nice, but the
> problem doesn't scale from IPv4 to IPv6 without some cleverness in the DNS
> which isn't there yet. Are we saying there is really no choice in the
> IPv6 world but to leave these unregistered in the DNS? Is that considered
> 'acceptable'?
>
BIND has a 'userspace' backend that you could use to generate matching
forward and reverse records on the fly. The problem comes when things like
zone transfers get in on the mix if you borrow an external nameserver to act
as a secondary that you have no control over. For instances such as this it
would be worth hosting on your own kit '<whatever>.ip6.arpa.' entries.
We are lucky and moving soon to putting all of our DNS/DHCP data into LDAP so
for IPv4 I will be watching the leases file for changes and amending the
zones approiately[2]. For DHCPv6...I would guess we could do a similar
thing.
If that was not an option I would write a daemon to sit on an IPv6 subnet and
snoop on the IPv6 EUI-64 address that are being used and add/remove/modify
the entries according to what I discover there.
Sure this could be considered 'kludgy' however even as and when a 'final
solution' comes about I would be unsure if there was a better approach that
could be devised; unless we want to start going down "hey lets trust those
clients...". :-/
> JANET Roaming / Eduroam is a good crossover because we have no chance of
> registering the machines there. What are sites with IPv6 enabled for that
> doing?
>
Two zone files with 2^64 additional entries? :)
> Maybe we just need to pick a solution which is acceptable in the short to
> medium term. I find it hard to believe these issues haven't been
> addressed (or at least commented on) in the wider global community
> (especially as we've been trying at IPv6 for over 10 years now - you'd
> like it to be perfect by the time you actually have to use it!); maybe
> there are working groups addressing extensions to DNS to blanket register
> things in a more scalable way than $GENERATE, for example.
>
When push comes to shove I like to fallback on the ops recommendations for
insight:
http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/
Does not seem to provide too much...but it might help.
Cheers
Alex
[1] http://dhcpv6.sourceforge.net/
[2] the advantage being that we get MAC -> DNS registration rather than IP