- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Dynamic DNS
by BEGIN, Thomas 24 Apr '03

24 Apr '03

Hello, I'm working on the relationship between IPv6 and DynamicDNS on several OS. I've succeeded in making my testbed with an automatic registration into the DNS at the startup of computers. Then IPv4 and v6 addresses are well recorded inside the DNS. But the fact is that I still have the IPv4 network. Next I tried to put off the IPv4 protocol from the network and get an only IPv6 network. * For the linux machines -> no problems * For the windows 2003 machines -> they are no more recorded inside the DNS table Thus I have few questions about this thema : - Is there anything special to setup in the OS to allow dynamic updates over IPv6 ? may be in the netsh tool ? I've searched myself and haven't found ... - Is IPv4 necessary to carry the register messages that serves for the dynamic DNS updates ? It would mean that IPv6 is not autonomous on the new windows OS ? strange ... - Is there an equivalent of the command ipconfig /registerdns ... that exists when IPv4 is shut down ? Regards - Thomas

1 0

[ipv6-wg@ripe.net] v6wpd release announcement
by DB Role Account 24 Apr '03

24 Apr '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the IPv6 Whois Proxy Daemon source code release. The release contains the software for proxying a RIPE Whois server on an IPv6 network. It contains the facility of mapping individual IPv6 addresses to RFC1918 IPv4 addresses, in order to ensure proper access list controls. The software is available at ftp://ftp.ripe.net/ripe/dbase/software/v6wpd-1.0.0.tar.gz Please contact dbtools(a)ripe.net for any comments. Best regards, -- Can Bican DB Group RIPE NCC

1 0

RE: [ipv6-wg@ripe.net] ipv6 address format
by Michel Py 10 Apr '03

10 Apr '03

Pim / Sam, > Pim van Pelt wrote: > I'll stick to calling the /32's and their 6bone /28 and /24 > siblings "TLA" until there is another common term for it. > I don't see the need to change it though, as opposed to SLA > and NLA which I no longer use. I don't see the need either but there was momentum to specifically suppress the wording, no need to swim against the tide. > Sam Wilson wrote: > On my reading of the I-D the "global routing prefix" described > above is not the prefix that appears in the default-free zone There is no such thing as an IPv6 DFZ, please have a look at: http://arneill-py.sacramento.ca.us/ipv6mh/ietf55ilj.pdf http://arneill-py.sacramento.ca.us/ipv6mh/playbook.pdf > That suggests the "global routing prefix" shown above is the > prefix a site and its immediate upstream know about but it > could, at least in theory, be further aggregated between there > and the default-free zone. > Is that right or have I missed something obvious? You are right but only if the address is PA. The fact that there are no PI addresses as of today does not mean there will not be a replacement for them that uses the same address semantics as a regular IPv6 unicast address. Michel.

1 0

RE: [ipv6-wg@ripe.net] ipv6 address format
by Michel Py 10 Apr '03

10 Apr '03

Jeroen / Gert, >>> Jeroen Massar wrote: >>> Or is there another more appropriate name for >>> the prefixes that are allowed in the DFZ? >> Michel Py wrote: >> The replacement is LIR. > Gert Doering wrote: > Which is quite ambiguous - a LIR usually doesn't > mean "a /32 from 2001" but some legal entity with > a given contractual status with a RIR... True and there are other issues as pointed by Jeroen below; I have made this very point myself before. Since the address structure on the left of site topology is now handled by the RIRs (technically, everything that is right of the IID is RIR business, however RIRs have followed recommendations along the lines of RFC3177 for site topology) it is no up to the RIRs to come up with terminology to replace TLA (and NLA maybe). > Jeroen Massar wrote: > And not every LIR has a (or multiple) prefixes yet > from the RIRs. True. > So should we actually be calling TLA's a GRP (Global > Routing Prefix) ? I am currently using 'TLA' everywhere > and I think it's quite appropriate as the prefixes are > really the Top Level Aggregators. Mind you that Randy > Bush also pointed it out to me at the last RIPE meeting > and he is right, it is deprecated No yet, actually. Addrarch still is in the pipe so on paper you are still fine but not for long. > even though I use it for my GRH project quite a lot > simply because I don't have a better wording for it... > So what is the correct wording for it? GRP? Looks good to me and it does go nicely with the GRT (Global Routing Table) terminology that I have been using as a replacement for DFZ (there is no such thing as an IPv6 DFZ). Michel.

1 0

RE: [ipv6-wg@ripe.net] ipv6 address format
by Michel Py 10 Apr '03

10 Apr '03

Jeroen, > Jeroen Massar wrote: > Stupid question There are no stupid questions. > but are we still 'allowed' to call the Top Level Aggregators > a TLA. Eg... 2001:db8::/32 is a TLA No. The wording "TLA" has been deprecated entirely. The very notion does not exist anymore. See: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.t xt The only remnant is a 6bone "pTLA" but given the sunset date for the 6bone in 9 months as far as allocation goes time will take care of that one. > Or is there another more appropriate name for > the prefixes that are allowed in the DFZ? The replacement is LIR. Michel.

6 5

RE: [ipv6-wg@ripe.net] ipv6 address format
by Michel Py 10 Apr '03

10 Apr '03

None of these are correct anyway, read: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.tx t Which is to replace RFC2373 any day now. Michel. _ ____ __ __ ____ _ _ _ _ | | | _ \ \ \ / / / ___| | \ / | | | | | Michel Py | | | |_| | \ \ / / | |__ | \/ | | |__| | Sr. Network Engineer | | | __/ \ \/ / | _ \ | \ / | | __ | CCIE #6673 | | | | \ / | |_| | | |\/| | | | | | mpy(a)ieee.org |_| |_| \/ \___/ |_| |_| |_| |_| IPv6 Multihoming Solutions http://arneill-py.sacramento.ca.us/ipv6mh http://arneill-py.sacramento.ca.us/public/ipv6mh/ I'm in the process of reviving ipv6 on our network. I'm new to IPv6 so this questions is perhaps obvious. I found an old company document which lists the following format for an IPv6 address. | 16 | 19 | 13 | 16 | 64 bits | +-+---------+------+-----------+--------+-----------------+ | 0x2001 | sTLA | NLA | SLA ID | Interface ID | +-+---------+------+-----------+--------+-----------------+ I'm confused here, reading RFC2373 I found the folowing format |3| 13 | 8 | 24 | 16 | 64 bits | +-+---------+-----+------------+--------+-----------------+ | | TLA ID | RES | NLA ID | SLA ID | Interface ID | +-+---------+-----+------------+--------+-----------------+ Hmmm, what's wrong. -Jeroen- -- Jeroen Valcke sst(a)belnet.be jeroen.valcke(a)belnet.be

2 1

[ipv6-wg@ripe.net] Reverse lookup
by BEGIN, Thomas 09 Apr '03

09 Apr '03

Hello everyone, I'm testing DNS over IPv6 on a testbed and I'm confronted to an issue. Here is my configuration: I'm working on a Red Hat Distribution (8.0) with Bind 9.2.1.9 I've set up configuration files and the forward lookup works over IPv4 and IPv6 but the reverse lookup is only working with IPv4. (fec0:0:0:1::2 is one of the site-local addresses of my machine (DNS server)) e.g. host fec0:0:0:1::2 gives me: Host \[xFEC00000000000010000000000000002].ip6.arpa not found: 2(serverfail) First I realized that even if I tried to use ip6.int suffix in the configuration files, the message error keeps the same - Host \[xFEC00000000000010000000000000002].ip6.arpa not found: 2(serverfail) !!! Secondly, by sniffing with ethereal the packets, I've seen that the query is well sent to the computer (loop back) but no response is given and then computer tries to ask root DNS... I'm not out of idea, may be one of you can help me ... I post my config files. ------------------------------------------------------------------------------------------------------ ------ Named.conf ------ // generated by named-bootconf.pl options { directory "/var/named"; listen-on-v6 { any; }; }; // // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "." IN { type hint; file "named.ca"; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; }; zone "olympe.gr" IN { type master; file "olympe.gr.zone"; allow-update { none; }; }; zone "236.10.in-addr.arpa" IN { type master; file "10.236.zone"; allow-update { none; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { type master; file "named.local"; allow-update { none; }; }; // zone "2.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.int" { // type master; // file "fec0.0.0.2.zone"; // allow-update { none; }; // }; zone "2.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa" { type master; file "fec0.0.0.2.zone"; allow-update { none; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa" { type master; file "fec0.0.0.1.zone"; allow-update { none; }; }; // zone "1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.int" { // type master; // file "fec0.0.0.1.zone"; // allow-update { none; }; // }; include "/etc/rndc.key"; -------------------------------------------------------------------------------------------------------- ----- fec0.0.0.1.zone ----- @ IN SOA cassandre.olympe.gr. admin.olympe.gr. ( 2003040603 3H 15M 1W 1D ) IN NS cassandre.olympe.gr. ; $ORIGIN 1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. $ORIGIN 1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.int. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR cassandre.olympe.gr. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR hermes.olympe.gr. 9.6.6.2.f.7.e.f.f.f.7.c.8.0.2.0 IN PTR arion.olympe.gr. - Regards - Thomas

3 2

[ipv6-wg@ripe.net] Re: Reverse lookup
by BEGIN, Thomas 09 Apr '03

09 Apr '03

EH I found the mistake ( mainly thanks to your mails) and then now the DNS is working fine ... :-)) I thank everybody for the help they gave to me so quickly... Bye

1 0

[ipv6-wg@ripe.net] ipv6 address format
by Jeroen Valcke 09 Apr '03

09 Apr '03

Hello, I'm in the process of reviving ipv6 on our network. I'm new to IPv6 so this questions is perhaps obvious. I found an old company document which lists the following format for an IPv6 address. | 16 | 19 | 13 | 16 | 64 bits | +-+---------+------+-----------+--------+-----------------+ | 0x2001 | sTLA | NLA | SLA ID | Interface ID | +-+---------+------+-----------+--------+-----------------+ I'm confused here, reading RFC2373 I found the folowing format |3| 13 | 8 | 24 | 16 | 64 bits | +-+---------+-----+------------+--------+-----------------+ | | TLA ID | RES | NLA ID | SLA ID | Interface ID | +-+---------+-----+------------+--------+-----------------+ Hmmm, what's wrong. -Jeroen- -- Jeroen Valcke sst(a)belnet.be jeroen.valcke(a)belnet.be

3 2

[ipv6-wg@ripe.net] Reverse delegation for 6bone address space in ip6.arpa
by Andrei Robachevsky 04 Apr '03

04 Apr '03

Dear Colleagues, In accordance with RFC 3152, the administration of the name space within ip6.arpa has been delegated to the RIRs. The 3FFE::/16 address space has not yet been allocated to the RIRs by the IANA. It is the intention that the RIRs administer this space. The community has expressed a need for 3FFE reverse space to be in the ip6.arpa domain. The RIR CEOs sent a message to the IAB requesting a waiver regarding the RFC 3152 requirement and received a positive response. The RIRs are prepared to administer e.f.f.3.ip6.arpa domain in the manner as described below. We plan to implement it in the next few weeks and deliver the solution soon after the RIPE 44 Meeting in January. Regards, Andrei Robachevsky CTO, RIPE NCC Support for reverse delegation for 6bone address space in ip6.arpa DNS tree --------------------------------------------------------------------------- Phase I. Before a final decision is made on future management of the 3FFE address space The delegation for e.f.f.3.ip6.arpa is made by IANA to one of the RIRs. Zone information for this space is produced by copying the existing delegations in the e.f.f.3.ip6.int zone. Additional check is done to ensure that the servers corresponding to the NS RR are also authoritative in .arpa space. Zone information is updated whenever changes are detected in the e.f.f.3.ip6.int zone. This approach has a couple of advantages. It keeps the RIRs out of the 6bone registration process until a final decision is made on future management of the 3FFE address space. It also implies no procedural changes from a user's perspective since changes are made in only one place, while at the same time it moves responsibility for maintaining the e.f.f.3.ip6.arpa zone to the RIRs. This then prepares for a smoother transition to Phase II. The main constraint of this approach is that it forces registrants to use the same name servers for .arpa as for .int. Phase II. Registration of 3FFE space is transferred to the RIRs A shared zone management process will be implemented similar to that currently implemented by the RIRs for the legacy v4 space (ERX project, http://www.ripe.net/db/erx/) That is, holders of 6bone address space will be served for reverse delegation by the respective RIR in their region, and the generation of the e.f.f.3.ip6.arpa zone can be entirely automated using zone merging.

2 2