[lugm.org] IPV6 ( Apache / DNS )

[Anoopsing Seburuth]

Thanks Ajay and Nishal

its up and running ipv6 :)



Anoop Seburuth


Fingerprint :  C886 6BFF 6057 E357 5088  D02B BD5F 9291 EA18 5A51




On Fri, Jan 21, 2011 at 9:11 AM, Nishal Goburdhan <ndg at ieee.org> wrote:
>
> On Jan 20, 2011, at 11:11 PM, Anoopsing Seburuth wrote:
>
>> Hi Guys / Girls,
>>
>> Lugm theme look nice .. Yes  about Ipv6 ( Apache / DNS ) does anyone
>> of you have some nice tutorials or links would
>> appriciate if you could share.
>
>
> there really isn't much to apache or bind/nsd + ipv6;  these have both been v6 aware for quite a while, and are used in production today.
> so if your host is already v6 capable, chances are that by tweaking your 'listen-on' directive for each application, you'll have them listening on, and responding to queries on v6.
>
> apache is easy.  just do it.  really  :-)
> dns is a little more interesting;  there are two separate elements:
> * providing answers to:  what is the ipv6 address for foo.bar
> * listening on, and providing services over v6
> the first is transparent to end-users;  a nameserver that is still only on ipv4 can still provide you with an answer to:  what is the ipv6 address for foo.bar.  so, the underlying transport can be v4.
> this is very important to remember;  because one of the first things that folks do when they testing v6 is to start adding in AAAA records to "see if dns will work"
> so now when you lookup foo.bar, you'll get a v4 and a v6 answer;  and if your host has v6 enabled, it will generally try to make a v6 connection to this host before v4.
> but if your v6 client connection has incomplete connectivity to foo.bar, you'll have to wait for the v6 connection to timeout, and then the v4 connection to retry.
> and this isn't always predictable;  different operating systems, on different patch levels with different software, will give you different answers.
> but it's not difficult either;  the key is simply in ensuring that you have v6 working to the host, and that's not as difficult nowadays.
> can you ping6/traceroute6 to it?  yes?  good.
> once your end-to-end connectivity is in, go ahead and add whatever you want into dns.
> (of course, while you're testing, you can always add in something like v6.foo.bar instead)
>
> very briefly, your workflow is something like:
> * get your ipv6 address space.
> crucial step 1.  without ip addresses, you can't really do anything, unless you were planning on using some v4<->v6 translation methods, and really, you shouldn't.  there's a lot of space.  just get it.
>
> * enable v6 across your network.
> get someone to give you v6 transit.  there are free tunnelbroker services, even for home users, so you don't have to complain about your first-hop upstream not being native-v6*.  transit is an important step 2, since, if you just go ahead and enable v6 on your network stack you'll run into the problem above.
> once your transit is in, start with your lab environment and the network that the techies are on first.  find, fix, rinse, repeat.
>
> * enable v6 on your server host.
> * test, test, test.
> * put the hostname into dns.
> * profit.
>
> the exhaustion counter at http://ipv6.he.net/statistics/ puts this at 11days;  can you get your hosts v6 capable before then?  :-)
>
> --n.
> __________________________________________________________
> Linux User Group of Mauritius (LUGM) Discuss mailing list
> Website: http://lugm.org
> Mailing list archive: http://lugm.org/pipermail/discuss_lugm.org/
> Forum: http://lugm.org/forum/
> IRC: #linux.mu on Freenode
>