Draft Minutes (v1) IPv6 wg RIPE42
Please see below for the first version of the draft minutes of the IPv6 wg at the last RIPE meeting. I would like to thank the scribe for writing down the minutes. The minutes will be declared final by June 7th if there are no objections raised and/or major changes required. Thanks, David K. --- Draft Minutes of the IPv6 Working Group session of the RIPE 42 Meeting, 29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands. The session was held on May 2, 14:00 - 17:30 ----------------------------------- Chair: David Kessens Scribe: Rainer R|cker Attendees: 113 ----------------------------------- Agenda: 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. IPv6 roadmaps of network equipment vendors a. Juniper (Jean-Marc Uze, Elise Gerich) b. Cisco (Simon Pollard) C. Global IPv6 routing table status (Gert Dvring) D. Tunnelbrokers & ipv6 in practice (Pim van Pelt) related discussion topic: do we prefer to use 6to4 instead of tunnelbrokers ?!? 2nd slot E. IPv6 Promotion Council Activities Overview (Kosuke Ito) F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (Joao Luis Silva Damas, RIPE NCC) G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? (Joao Luis Silva Damas, RIPE NCC) related topic: 6to4 reverse delegations H. lbnamed Bug Discussion I. IPv6 allocation survey (Mirjam K|hne, RIPE NCC) J. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio) K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - French NIC initiative regarding DNSv6 deployment (Mohsen Souissi) L. LIR-WG session on IPv6 policy Z. AOB ======================== A: Scribe, Agenda bashing ======================== Two scribes from the RIPE NCC. One additional presentation from the tipster project was accepted for point K on the agenda. The Agenda was accepted. ======================== B. IPv6 roadmaps of network equipment vendors a. Juniper ======================== Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. The slides are available at Pim van Pelt (PVP): What about Filtering and OSPF6 ? JMU: OSPF6 for Junos will come in the second half of 2002 Filtering will come soon. ?: Are you working on 6-to-4 transition? JMU: Are there already applications that need it? ?: 6-to-4 relays will need it, these will be important for the users ?: What about 6PE? (MPLS over IPv6) JMU: Should be avoided on core routers, since it degrades performance. ?: Will you implement NAT/PAT for v6? JMU: Not on the short term. ======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. The slides are available at Gert Dvring (GD): The IOS upgrade is not really free available - you need to buy the IP+ option package before you can make the upgrade. SP: This is true for the low-end platforms - but most people have IP+ anyway PVP: What about filtering and OSPF6. SP: Available - a beta of OSPFv3 will be out in October 2002. ?: What about Layer3 Switches? SP: They will come in Q3/2002 ?: Will there be a Ciso-PIX for IPv6? SP: This is planned for Q1/2003 ?: Is there 6PE and NAT/PAT for v6? SP: Yes, we have this for the PE-routers GD: IOS has become very large - you can't fit it into the small routers without upgrading Flash and Memory. Customers are not willing to spend money in order to upgrade. Make IOS smaller. An Image-size of 4MB would be good. SP: Customers will pay for the router-upgrade if they see the business drive of IPv6. However, Cisco is working on re-packaged IOS for the lower platforms. The memory-footprint will probably be 8 MB. GD: 4MB should be the target. ======================== C. Global IPv6 routing table status ======================== Gert Dvrings presentation is available at http://www.space.net/~gert/RIPE/R42-v6-table/ Conclusions: - Downstream filtering recommended - You should watch the announcements of your peers. PVP: 6bone has changed it's policy to give out /32 now, four of these prefixes should be visible. 15 are in the table. ?: Is there a canonical filter-list for IPv6 ? GD: Not yet. ?: Would you be up to maintain such a list? GD: I will discuss this with David Kessens and we should move the discussion on this topic to the mailing-list. === ;7777777;7777777;7777777 COFFEE BREAK ;7777777;7777777;7777777 10:35 - 10:50 ;7777777;7777777;7777777 === ?: Is it easy to filter unassigned ASNs ? GD: Technically this is possible but it's preferable to talk to the people that are making the mistakes. ======================== D. Tunnelbrokers & ipv6 in practice ======================== Pim van Pelts presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... PVP: Sixxs, a IPv6 tunnel-broker for LIRs in the RIPE-region is looking for participants that are willing to be a POP for this service. ?: What about the 6-to-4 tunnels? PVP: At the time we started, static tunneling was the only thing available. Today, if you run a 6-to-4 relay, it's easy for everyone to join, so it's also easy for everyone to abuse the service. If you host the relay, you also have to filter the incoming IPv4 traffic which is not easy. Attacks by script-kiddies on the next-hop of the relay (which is IPv4) are common today. DK: There have also been native V6-DoS-attacks, it's really scary. ======================== E. IPv6 Promotion Council Activities Overview ======================== Kosuke Ito's presentation can be found at ??? See also http://www.v6pc.jp/index_e.html - The audience had no questions or comments. ======================== F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? ======================== DK: IPv6 capable RR DNS Servers should be discussed in the LIR-WG. - the audience agreed ======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ======================== Joao Luis Silva Damas presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed? ?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy DK: Can't we just do automatic delegation in both domains? Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. GD: But older machines all use ip6.int. Joao: OK, for the time being both delegations are possible. But should it be done automatically or do we only delegate in ip6.int if someone really wants it? GD: RIPE NCC should investigate if it's possible to do away with ip6.int and make a solution with CNAMEs. Make some experiments and report at RIPE 43 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation. Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the best solution, but if someone requests different delegations in ip6.arpa and ip6.int, RIPE NCC should not prevent this. Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DK: RIPE NCC, could you investigate the possibilities? Joao: OK, we will do the automatic delegation in both trees by default and we will allow different configuration if the user wants it. ?: But would this approach not lead to inconsistent data in the two domains? DK: It's only reverse delegation, that should have no big impact. DK: OK, 6-to-4 reverse delegation will also happen in ip6.arpa. What about this? Joao: The draft on 6 to 4 DNS (draft-ietf-ngtrans-6to4-dns-00.txt) is not very specific. RIRs will do the delegation based on the IPv4 /8s that they are authoritative for, but anything else is not clear yet. DK: What about the 6bone addresses and ip6.arpa Joao: I am not familiar with that. DK: Could you investigate this and give a more specific presentation at RIPE 43? Joao: Sure. ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 ======================== H. lbnamed Bug Discussion ======================== Francis Dupont explained that an updated version of lbnamed is available and urged everyone using lbnamed to update to the latest version. ======================== I. IPv6 allocation survey ======================== Mirjam K|hne announced that the survey will be published on the web. The presentation was not given in this session due to shortage of time. The survey is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... ======================== J. Euro6IX and layer 3 IX addressing ======================== Raffaele D'Albenzio's presentation is available at http://www.euro6ix.net/mantenimientos/e-doc_subidos/D1.1_Project_Presentatio... (needs to be verified!) - The audience had no questions or comments. == DK reminded that there is not much time left. The time for each of the following presentations was restricted to less than 5 minutes. == ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond The Hungarian Tipster6 project ======================== Geza Turchanyi gave a short overview on the tipster6-project and provided some statistics on the v6-capability of several unix-distributions. (Sun, BSD, Linux) ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ======================== Mohsen Suissis presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... Mohsen Suissis pointed out that currently not many TLD-Nameservers are native v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS. AFNIC also applied to become secondary for ip6.arpa. The request was submitted to IANA but nothing happened so far. ======================== L. LIR-WG session on IPv6 policy ======================== The iproposal for a global interim IPv6 Allocation Policy was accepted by the LIR-WG. ======================== Z. AOB ======================== Nothing reported ======================== Summary of actions arising from this meeting ======================== 42.1 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation in the ip6.int tree. 42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43
Hi David, The correct link for the Euro6IX presentation is http://www.euro6ix.org/ingles/Presentations/020430-TILAB-DalbenzioGuardini-R... Regards, Jordi ----- Original Message ----- From: "David Kessens" <david@IPRG.nokia.com> To: <ipv6-wg@ripe.net> Cc: <meeting@ripe.net> Sent: Tuesday, May 28, 2002 11:39 PM Subject: Draft Minutes (v1) IPv6 wg RIPE42
Please see below for the first version of the draft minutes of the IPv6 wg at the last RIPE meeting.
I would like to thank the scribe for writing down the minutes.
The minutes will be declared final by June 7th if there are no objections raised and/or major changes required.
Thanks,
David K. ---
Draft Minutes of the IPv6 Working Group session of the RIPE 42 Meeting, 29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands.
The session was held on May 2, 14:00 - 17:30
----------------------------------- Chair: David Kessens Scribe: Rainer R|cker Attendees: 113 -----------------------------------
Agenda: 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens)
B. IPv6 roadmaps of network equipment vendors a. Juniper (Jean-Marc Uze, Elise Gerich) b. Cisco (Simon Pollard)
C. Global IPv6 routing table status (Gert Dvring)
D. Tunnelbrokers & ipv6 in practice (Pim van Pelt) related discussion topic: do we prefer to use 6to4 instead of tunnelbrokers ?!?
2nd slot
E. IPv6 Promotion Council Activities Overview (Kosuke Ito)
F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (Joao Luis Silva Damas, RIPE NCC)
G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? (Joao Luis Silva Damas, RIPE NCC) related topic: 6to4 reverse delegations
H. lbnamed Bug Discussion
I. IPv6 allocation survey (Mirjam K|hne, RIPE NCC)
J. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio)
K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience)
- French NIC initiative regarding DNSv6 deployment (Mohsen Souissi)
L. LIR-WG session on IPv6 policy
Z. AOB
======================== A: Scribe, Agenda bashing ======================== Two scribes from the RIPE NCC.
One additional presentation from the tipster project was accepted for point K on the agenda.
The Agenda was accepted.
======================== B. IPv6 roadmaps of network equipment vendors a. Juniper ======================== Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. The slides are available at
Pim van Pelt (PVP): What about Filtering and OSPF6 ? JMU: OSPF6 for Junos will come in the second half of 2002 Filtering will come soon. ?: Are you working on 6-to-4 transition? JMU: Are there already applications that need it? ?: 6-to-4 relays will need it, these will be important for the users ?: What about 6PE? (MPLS over IPv6) JMU: Should be avoided on core routers, since it degrades performance. ?: Will you implement NAT/PAT for v6? JMU: Not on the short term.
======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. The slides are available at
Gert Dvring (GD): The IOS upgrade is not really free available - you need to buy the IP+ option package before you can make the upgrade. SP: This is true for the low-end platforms - but most people have IP+ anyway PVP: What about filtering and OSPF6. SP: Available - a beta of OSPFv3 will be out in October 2002. ?: What about Layer3 Switches? SP: They will come in Q3/2002 ?: Will there be a Ciso-PIX for IPv6? SP: This is planned for Q1/2003 ?: Is there 6PE and NAT/PAT for v6? SP: Yes, we have this for the PE-routers GD: IOS has become very large - you can't fit it into the small routers without upgrading Flash and Memory. Customers are not willing to spend money in order to upgrade. Make IOS smaller. An Image-size of 4MB would be good. SP: Customers will pay for the router-upgrade if they see the business drive of IPv6. However, Cisco is working on re-packaged IOS for the lower platforms. The memory-footprint will probably be 8 MB. GD: 4MB should be the target.
======================== C. Global IPv6 routing table status ========================
Gert Dvrings presentation is available at
http://www.space.net/~gert/RIPE/R42-v6-table/
Conclusions: - Downstream filtering recommended - You should watch the announcements of your peers.
PVP: 6bone has changed it's policy to give out /32 now, four of these prefixes should be visible. 15 are in the table.
?: Is there a canonical filter-list for IPv6 ? GD: Not yet. ?: Would you be up to maintain such a list? GD: I will discuss this with David Kessens and we should move the discussion on this topic to the mailing-list.
=== ;7777777;7777777;7777777 COFFEE BREAK ;7777777;7777777;7777777 10:35 - 10:50 ;7777777;7777777;7777777 ===
?: Is it easy to filter unassigned ASNs ? GD: Technically this is possible but it's preferable to talk to the people that are making the mistakes.
======================== D. Tunnelbrokers & ipv6 in practice ========================
Pim van Pelts presentation is available at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-...
PVP: Sixxs, a IPv6 tunnel-broker for LIRs in the RIPE-region is looking for participants that are willing to be a POP for this service.
?: What about the 6-to-4 tunnels? PVP: At the time we started, static tunneling was the only thing available. Today, if you run a 6-to-4 relay, it's easy for everyone to join, so it's also easy for everyone to abuse the service. If you host the relay, you also have to filter the incoming IPv4 traffic which is not easy. Attacks by script-kiddies on the next-hop of the relay (which is IPv4) are common today. DK: There have also been native V6-DoS-attacks, it's really scary.
======================== E. IPv6 Promotion Council Activities Overview ========================
Kosuke Ito's presentation can be found at ??? See also http://www.v6pc.jp/index_e.html
- The audience had no questions or comments.
======================== F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? ========================
DK: IPv6 capable RR DNS Servers should be discussed in the LIR-WG. - the audience agreed
======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ========================
Joao Luis Silva Damas presentation is available at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-...
The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed?
?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy DK: Can't we just do automatic delegation in both domains? Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. GD: But older machines all use ip6.int. Joao: OK, for the time being both delegations are possible. But should it be done automatically or do we only delegate in ip6.int if someone really wants it? GD: RIPE NCC should investigate if it's possible to do away with ip6.int and make a solution with CNAMEs. Make some experiments and report at RIPE 43
ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation.
Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the best solution, but if someone requests different delegations in ip6.arpa and ip6.int, RIPE NCC should not prevent this. Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DK: RIPE NCC, could you investigate the possibilities? Joao: OK, we will do the automatic delegation in both trees by default and we will allow different configuration if the user wants it.
?: But would this approach not lead to inconsistent data in the two domains? DK: It's only reverse delegation, that should have no big impact.
DK: OK, 6-to-4 reverse delegation will also happen in ip6.arpa. What about this? Joao: The draft on 6 to 4 DNS (draft-ietf-ngtrans-6to4-dns-00.txt) is not very specific. RIRs will do the delegation based on the IPv4 /8s that they are authoritative for, but anything else is not clear yet. DK: What about the 6bone addresses and ip6.arpa Joao: I am not familiar with that. DK: Could you investigate this and give a more specific presentation at RIPE 43? Joao: Sure.
ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43
======================== H. lbnamed Bug Discussion ========================
Francis Dupont explained that an updated version of lbnamed is available and urged everyone using lbnamed to update to the latest version.
======================== I. IPv6 allocation survey ========================
Mirjam K|hne announced that the survey will be published on the web. The presentation was not given in this session due to shortage of time.
The survey is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-...
======================== J. Euro6IX and layer 3 IX addressing ========================
Raffaele D'Albenzio's presentation is available at
http://www.euro6ix.net/mantenimientos/e-doc_subidos/D1.1_Project_Presentatio... (needs to be verified!)
- The audience had no questions or comments.
==
DK reminded that there is not much time left. The time for each of the following presentations was restricted to less than 5 minutes.
==
======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond The Hungarian Tipster6 project ========================
Geza Turchanyi gave a short overview on the tipster6-project and provided some statistics on the v6-capability of several unix-distributions. (Sun, BSD, Linux)
======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ========================
Mohsen Suissis presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-...
Mohsen Suissis pointed out that currently not many TLD-Nameservers are native v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS.
AFNIC also applied to become secondary for ip6.arpa. The request was submitted to IANA but nothing happened so far.
======================== L. LIR-WG session on IPv6 policy ========================
The iproposal for a global interim IPv6 Allocation Policy was accepted by the LIR-WG.
======================== Z. AOB ========================
Nothing reported
======================== Summary of actions arising from this meeting ========================
42.1 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation in the ip6.int tree.
42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43
*********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com
======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ========================
Joao Luis Silva Damas presentation is available at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-...
The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed?
?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy
I don't think that you can do this with CNAME. A CNAME is only honoured when it's found where the RR of the original query (typically a PTR for a complete inverse IPv6 address in this case) is expected. I suppose you simply get a NXDOMAIN if there's a CNAME higher up in that branch. DNAME would work :-) -- Alex
Hi, On Wed, May 29, 2002 at 11:12:55AM +0200, Alexander Gall wrote:
?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy
I don't think that you can do this with CNAME. A CNAME is only honoured when it's found where the RR of the original query (typically a PTR for a complete inverse IPv6 address in this case) is expected. I suppose you simply get a NXDOMAIN if there's a CNAME higher up in that branch.
I heave heard a number of "I think, I don't think, I suppose" statements on this, but no hard facts from the RFCs or code from common resolver libraries. This is why there is an action item on the NCC to find out whether this would work. (Of course one could aways set up a proxy that answers every request with a terminal CNAME, but that's equally ugly) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, 29 May 2002 15:05:39 +0200, Gert Doering <gert@space.net> said:
Hi, On Wed, May 29, 2002 at 11:12:55AM +0200, Alexander Gall wrote:
?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy
I don't think that you can do this with CNAME. A CNAME is only honoured when it's found where the RR of the original query (typically a PTR for a complete inverse IPv6 address in this case) is expected. I suppose you simply get a NXDOMAIN if there's a CNAME higher up in that branch.
I heave heard a number of "I think, I don't think, I suppose" statements on this, but no hard facts from the RFCs or code from common resolver libraries.
Ok, I forgot about wildcards <shudder>. With a wildcard, you can actually have a server return such a CNAME. However, whatever you specify as the target of the CNAME is static. To "redirect" an entire branch of the DNS tree, you need to modify the original query before you restart it. That's why DNAME had to change the algorithms of RFC1034, sections 4.3.2 and 5.3.3. Am I missing something? -- Alex
This is why there is an action item on the NCC to find out whether this would work.
(Of course one could aways set up a proxy that answers every request with a terminal CNAME, but that's equally ugly)
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-- ___________ SWITCH - The Swiss Academic and Research Network ___________ Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland gall@switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568
Hi, On Wed, May 29, 2002 at 04:31:48PM +0200, Alexander Gall wrote:
I heave heard a number of "I think, I don't think, I suppose" statements on this, but no hard facts from the RFCs or code from common resolver libraries.
Ok, I forgot about wildcards <shudder>. With a wildcard, you can actually have a server return such a CNAME. However, whatever you specify as the target of the CNAME is static. To "redirect" an entire branch of the DNS tree, you need to modify the original query before you restart it. That's why DNAME had to change the algorithms of RFC1034, sections 4.3.2 and 5.3.3.
Am I missing something?
You could use one of the non-BIND servers that can actually generate arbitrary records on-the-fly. This could be used for the "proxy" solution. I'd still like to hear about hard facts / experiences why a CNAME in the middle of the path won't work (having seen that it does work for forward resolving - looks ugly, but people use it) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hello Gert On Wed, 29 May 2002 16:38:37 +0200, Gert Doering <gert@space.net> said: F
Hi, On Wed, May 29, 2002 at 04:31:48PM +0200, Alexander Gall wrote:
I heave heard a number of "I think, I don't think, I suppose" statements on this, but no hard facts from the RFCs or code from common resolver libraries.
Ok, I forgot about wildcards <shudder>. With a wildcard, you can actually have a server return such a CNAME. However, whatever you specify as the target of the CNAME is static. To "redirect" an entire branch of the DNS tree, you need to modify the original query before you restart it. That's why DNAME had to change the algorithms of RFC1034, sections 4.3.2 and 5.3.3.
Am I missing something?
You could use one of the non-BIND servers that can actually generate arbitrary records on-the-fly. This could be used for the "proxy" solution.
Of course.
I'd still like to hear about hard facts / experiences why a CNAME in the middle of the path won't work (having seen that it does work for forward resolving - looks ugly, but people use it)
What are you referring to? Also, "forward" and "inverse" zones are not inherently different. -- Alex
Hi, On Wed, May 29, 2002 at 05:18:06PM +0200, Alexander Gall wrote:
I'd still like to hear about hard facts / experiences why a CNAME in the middle of the path won't work (having seen that it does work for forward resolving - looks ugly, but people use it)
What are you referring to? Also, "forward" and "inverse" zones are not inherently different.
Exactly my point - I've seen weird things done in forward resolving that worked to my big surprise, so my idea might actually work (as there is no difference from the DNS point of view - in the resolver libraries, there might be one). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hello Gert On Wed, 29 May 2002 17:48:11 +0200, Gert Doering <gert@space.net> said:
On Wed, May 29, 2002 at 05:18:06PM +0200, Alexander Gall wrote:
I'd still like to hear about hard facts / experiences why a CNAME in the middle of the path won't work (having seen that it does work for forward resolving - looks ugly, but people use it)
What are you referring to? Also, "forward" and "inverse" zones are not inherently different.
Exactly my point - I've seen weird things done in forward resolving that worked to my big surprise, so my idea might actually work (as there
Can you give an example of such a weird thing? -- Alex
is no difference from the DNS point of view - in the resolver libraries, there might be one).
Please excuse the interruption.
On Wed, May 29, 2002 at 05:18:06PM +0200, Alexander Gall wrote:
I'd still like to hear about hard facts / experiences why a CNAME in the middle of the path won't work (having seen that it does work for forward resolving - looks ugly, but people use it)
What are you referring to? Also, "forward" and "inverse" zones are not inherently different.
Exactly my point - I've seen weird things done in forward resolving that worked to my big surprise, so my idea might actually work (as there is no difference from the DNS point of view - in the resolver libraries, there might be one).
I may have misunderstood what you're proposing, but in general a CNAME in the middle of a chain of NS references will not have the effect you want - that's why DNAME was invented. If you alias a domain to another domain then looking up the NS or SOA records for the aliased domain will work but the resolution will not follow the NS records to find things further down the tree. Look for www.ucs.ed.ac.uk and www.ucs-cname.ed.ac.uk if you want examples. Been there, done that, got blasted by the DNS grandees when I complained it didn't work... Sam Wilson one of hostmaster@ed.ac.uk Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK
Hi David & all, Please find my comments below in sections G and K : On 28 May, David Kessens wrote: | I would like to thank the scribe for writing down the minutes. | | The minutes will be declared final by June 7th if there are no | objections raised and/or major changes required. | | Thanks, | | David K. | --- [...] | | ======================== | G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? | ======================== | | Joao Luis Silva Damas presentation is available at | | http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... | | The recommendation is to populate ip6.arpa and phase out ip6.int - but what is | wanted and how shall we proceed? | | ?: Software currently relies on ip6.int - you can't just switch it off. | ?: Can't we just duplicate the delegation-records? | GD: A good solution would be a CNAME very high in the hierarchy | DK: Can't we just do automatic delegation in both domains? | Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. | GD: But older machines all use ip6.int. | Joao: OK, for the time being both delegations are possible. But should it be | done automatically or do we only delegate in ip6.int if someone really | wants it? | GD: RIPE NCC should investigate if it's possible to do away with ip6.int and | make a solution with CNAMEs. Make some experiments and report at RIPE 43 | | ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation. | | Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the | best solution, but if someone requests different delegations | in ip6.arpa and ip6.int, RIPE NCC should not prevent this. | Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 ==> ^ (no "s" at the end ;-)) | both delegations were made. ===> If my memory serves me well, what was meant by "automatic delegation" was the fact that reverse zone delegation had to be set automatically while delegating the /35 (or /32 in the future) under ip6.arpa. I said that DNS reverse delegation MUST NOT BE DONE AT THE PARENT ZONE BEFORE MAKING SURE THE CHILDREN (master & slaves) ARE READY. Then I remember that Joao told me that RIPE NCC have never done that (automatic reverse zone delegation under ip6.arpa) so far. Then I gave the example of the reverse zone of 2002:0660::/35 which was delegated under .ip6.arpa without knowing whether the supposed authoritative serves were ready or not. I hope this is clear now ;-) | ======================== | K. Developments/initiatives regarding IPv6 in the RIPE region and beyond | French NIC initiative regarding DNSv6 deployment | ======================== | | Mohsen Suissis presentation is available at ==> ^ | http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6-... | | Mohsen Suissis pointed out that currently not many TLD-Nameservers are native ^ | v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS. | | AFNIC also applied to become secondary for ip6.arpa. The request was submitted | to IANA but nothing happened so far. Regards, Mohsen.
David, I sent our presentation to Vesna. Please update the Minutes accordingly. Best, Geza
participants (7)
-
Alexander Gall -
David Kessens -
Gert Doering -
JORDI PALET MARTINEZ -
Mohsen Souissi -
Sam.Wilson＠ed.ac.uk -
Turchanyi Geza