- ipv6-wg - mailman.ripe.net

[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

[ipv6-wg@ripe.net] Experimental IPv6 address allocations policy
by Pekka Savola 04 Apr '03

04 Apr '03

Hi, I just recently noted that experimental IPv6 address allocations have been "sneaked in" the policy, as seen in: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments I must heavily object to this for a few reasons: 1) the intent is to keep the policy uniform, and this has not been discussed in the global-v6 policy mailing list. 2) RIPE43 minutes (posted on Oct 19 2002) list that this should be turned into a draft proposal [note: the URL for the presentation does not work]; There was a draft proposal on 28 Nov 2002 on "DRAFT: Experimental Internet Resource Allocations & Assignments". This is no longer available so I cannot verify the contents. 3) On 22 Jan 2003, new RIPE documents, 263 and 267 are available; these incorporate an experimental addressing policy. To my knowledge and according to my mail archives, neither of these has *ever* been as much as mentioned in the mailing lists (either ipv6 or lir wg) - not a single message. Is this sufficient in determining this is really what community wants? To clarify, are only those organizations which meet the criteria in section 5.1.1 applicable for experimental address allocations in: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments ? If the others can get experimental blocks, I'd be very much against it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

3 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

[ipv6-wg@ripe.net] IXP networks routing
by Nicolas DEFFAYET 14 Mar '03

14 Mar '03

Hello, We hesitate to allow IXP's /48 in our routing table. http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html => "Networks assigned under this policy may not be globally routable." What's the best practice ? Thanks Best Regards, -- Nicolas DEFFAYET, NDSoftware NDSoftware NOC: http://noc.ndsoftwarenet.com/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/

11 15

[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 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

[ipv6-wg@ripe.net] [announce] GRH Distributed Looking Glass
by Jeroen Massar 07 Mar '03

07 Mar '03

As the Ghost Route Hunter tool (*1) is already collecting BGP data we've added a Looking Glass (*2) allowing a direct view into all the participating AS's at one glance. This has the advantages of easy comparison and thus troubleshouting. The output of the different project participants is all the same even though they are currently using Juniper's, Cisco's and Zebra routers. New participants can signup (*3) for the GRH project, ofcourse the ultimate goal is a stable internet and having many views helps a lot. I hereby also want to thank the people and companies giving tips and the ones participating in the project. On another note we've also setup an IPv6 News site (*4) where one can submit IPv6 'news' stories. It's backed up by a forum so that a discussion about the topic is possible. Submissions to the site can be made using an email to info(a)sixxs.net or by posting in the relevant forum. If the topic is 'newsy' enough it will be marked as interresting and it will automatically pop up on the main pages. Ofcourse don't hesitate to mail when in doubt. Greets, Jeroen *1: http://www.sixxs.net/tools/grh/ *2: http://www.sixxs.net/tools/grh/lg/ *3: http://www.sixxs.net/tools/grh/signup/ *4: http://ipv6gate.sixxs.net/

1 0

RE: [ipv6-wg@ripe.net] Cross posting
by Michel Py 06 Mar '03

06 Mar '03

> David Kessens wrote: > This is request to keep the current discussions regarding > ipv6 on the appropriate list and not to cross post to both > the ipv6 and lir working group lists: > - ipv6-wg > Technical discussions regarding the deployment of ipv6 in > the RIPE region > - lir-wg > policy discussion list including ipv6 allocation policies Agree. Anyway, half of this was a discussion about multihoming that I have heard 10 times already and that has always ended up in the same place: nowhere. If one wants to discuss the topic, one should type "ipv6 multihoming" in the search window of any reputable search engine and go where it's actually happening. Michel.

2 1