March 2003 - ipv6-wg - mailman.ripe.net

[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

[ipv6-wg@ripe.net] Second IPv6 deployment survey
by leo vegoda 27 Mar '03

27 Mar '03

Dear Colleagues, On 20 February I posted to this list and confirmed that the RIPE NCC is willing to run a second IPv6 deployment survey. <http://www.ripe.net/ripe/mail-archives/ipv6-wg/2003/msg00108.html> I asked for input into the questions the survey should ask. There has been one message posted to this list and one sent directly to me. Based on the very limited input received, it appears that this activity is not a high priority for the RIPE community. Consequently, we will not conduct the survey at this time. Kind regards, -- leo vegoda RIPE NCC Registration Services

1 0

[ipv6-wg@ripe.net] Creating route objects for RFC3068 IP space
by Emma Apted 25 Mar '03

25 Mar '03

Hi, This is my first post to this list, so please forgive me if this is not the correct list for this topic. I've been looking at the route objects for the RFC3068 address space so that I could help AS8379 add their route object since they route this /24. route: 192.88.99.0/24 remarks: See RFC 3068 remarks: "An Anycast Prefix for 6to4 Relay Routers" remarks: Christian Huitema remarks: June 2001 We had much difficulty creating the newest object due to the previous recursive autnum authentication. With the help of Simon Leinen @Switch, Pekka Savola @FUnet and Robert Blechinger @Cybernet, we've changed the authorisation protecting the existing objects, to enable new members of the RFC3068 project to easily be able to enter their route objects for this /24 into the RIPE database. Each route object for 192.88.99.0/24 now includes the line :- mnt-routes: RFC3068-MNT This is a new maintainer that we've created, which currently has two authentication methods: an MD5-encrypted password and PGP. Once PGP is more widely used, we'll remove the MD5 password. When a new object needs to be created for this same /24 prefix, the originating AS need only pass the auth for this RFC3068-MNT and their own maintainer, rather than that of all the existing originating ASes. I've found this URL helpful to understand this process : http://www.ripe.net/ripencc/faq/database/route-creation-checks.html We wanted to let the IPv6 RIPE community know about this, so that when a new company joins the RFC3068 project, they know who to ask to get the MD5 password. The mntner object lists all our contact details. Please let us know if you have any questions! Best regards, Emma Emma Apted Peering Co-ordinator, Engineering & Standards --------------------------------------------------- PSINet Europe Intelligent e-business infrastructure Tel: +44 1223 577132 - Fax: +44 1223 577138 http://www.psineteurope.co.uk

1 0

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Kurt Erik Lindqvist 14 Mar '03

14 Mar '03

>> here are a number of people >> who will tell you that this won't scale and break a number of >> applications. > > Since I proposed it in April 2000, no one told me that this won't > scale. That surprises me. Then again I wasn't aware of you draft until you mailed it here. What WG do see this under? I will comment to multi6 anyway... >>> There already is running code of of 8+8, transport over it, such >>> as TCP, and applications over it, such as TCP multihomed telephony >>> with no address reselection latency, that there is not much work >>> remaning. >> >>> Never mention poor GSE. It is a poor idea useless for any purpose. >>> >> Uh, what is the difference between 8+8 and GSE? > > Current IPv6, in a sense, is 8+8 and was 10+6. ???? you mean the IID being 8 and the rest the other 8? I don't agree... > GSE is a poor variation of 8+8. GSE is poor because it is an attempt > to make ISP operation more complex (that is, less scalable), which > has been the tradition of telephone companies to maximize their > revenue. > I fail to see what GSE, 8+8 or anything have to do with telephone companies. - kurtis -

2 3

[ipv6-wg@ripe.net] Security over IPv6 networks
by BEGIN, Thomas 12 Mar '03

12 Mar '03

Hello, Security... that's a core problem for a lot of engineers ! With IPv4, a lot of enterprises networks were set up with private addresses (eg 10.x.x.x ). That implies that computers inside the network are unreachable from outside (eg Internet). Since IPv6 offers a large scale of addresses, I've heard that companies could address their machines with global unicast addresses (public addresses) and also benefit fully from IPsec and peer to peer applications. That's nice and it is said that it should improve security (IPsec totally used from sender to receiver). But in the other hand, isn't it dangerous to address machines with global unicast address and thus make them reachable directly from anywhere and by anybody... Besides NAT is often acknowledged as a good shield to secure networks. Then is it really possible to protect IPv6 networks (with global unicast addresses) as safe as Ipv4 networks using NAT ? I realize this is a big topic and may be there is no easy response but getting a high performance security is a fundamental factor for the deployement of IPv6. But if you have any idea (know enterprises that use public addresses for their network) please let me know ... -Thomas PS: using site local addresses inside IPv6 networks doesn't solve the problem ... ;-))

1 0

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Randy Bush 09 Mar '03

09 Mar '03

> Multihoming is simple to just let hosts have multiple addresses, > which is already done with IPv6, and let the hosts choose > the destination address. how to choose? randy

4 5

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Kurt Erik Lindqvist 09 Mar '03

09 Mar '03

> Multihoming is simple to just let hosts have multiple addresses, > which is already done with IPv6, and let the hosts choose > the destination address. As I said, there is no shortage of ideas. There are a number of people who will tell you that this won't scale and break a number of applications. > There already is running code of of 8+8, transport over it, such > as TCP, and applications over it, such as TCP multihomed telephony > with no address reselection latency, that there is not much work > remaning. > Never mention poor GSE. It is a poor idea useless for any purpose. > Uh, what is the difference between 8+8 and GSE? - kurtis -

2 1

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Gert Doering 09 Mar '03

09 Mar '03

Hi, On Tue, Mar 04, 2003 at 04:07:58PM +0100, Poul-Henning Kamp wrote: > >It means re-thinking some established ways to do things - things that > >have caused large problems in the past, and might not have been an overly > >good idea to start with. > > Well, but those "established ways of doing things" may also happen > to be exactly why we could deploy IPv4 in the first place, and their > absense have provably hampered IPv6 deployment. Yes, of course we can stay on IPv4 with NAT and double-NAT and dynamic IPs for customers and whatever kludges are necessary... Changing over to IPv6 *is* painful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

9 23

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Peter Galbavy 07 Mar '03

07 Mar '03

> PRIVATE INTERCONNECTS. Real world example follows, which is why my primary > employer has a PI assignment; we interconnect using IPsec VPNs and some > leased lines with a number of other enterprises. We use RFC1918 *internally* > and so do many others. What addressing scheme would you suggest we use to > talk, especially as we DO NOT want this traffic to accidentally leak onto > the public internet ? I notice that my reply has been conveniently ignored. Well, how will you address this issue in the *real* world ? Peter

3 8

Re: [ipv6-wg@ripe.net] IPv6 PPPoE
by Gert Doering 07 Mar '03

07 Mar '03

Hi, On Thu, Mar 06, 2003 at 01:13:48PM +0100, Christian Strauf wrote: > > > Side question: do a PPPoE exist for IPv6 ? > > Client side: yes, of course. Linux and BSD pppoe can do it, and "most > > recent" Cisco IOSes can do that as well. > > We have a couple of PPPoE DSL customers that use IPv6. > This sounds very interesting. We got a 6WIND-router day before yesterday and we > would like to test PPPoE with IPv6 with that machine. Do you use IPv4 at all or > is the whole connecting done without any IPv4 involved at all? IPv4 is still used, of course, as all customers still need IPv4 connectivity. v6-only might work (if the client refuses IPCP), but we never tried that yet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

3 5