July 2011 - ipv6-wg - mailman.ripe.net

dynamic or static IPv6 prefixes to residential customers
by JORDI PALET MARTINEZ 23 Aug '11

23 Aug '11

Hi all, I will like to know, from those deploying IPv6 services to residential customers, if you are planning to provide static or dynamic IPv6 prefixes. Just to be clear, I'm for static prefix delegation to residential customers, however I heard that some ISPs are doing dynamic delegations, the same way as is common today with IPv4. I don't thin it make sense, as the main reason for doing so in IPv4 was address exhaustion and legacy oversubscription models such as PPP/dial-up. Regards, Jordi PS: I've sent this question to NANOG, got very few answers, so trying here ... ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

9 14

Re: AW: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers
by JORDI PALET MARTINEZ 27 Jul '11

27 Jul '11

However I think this is an educational problem of those agencies you can't offer dynamic and stable services to access the home, and privacy goes beyond a stable address. So miss-protecting privacy actually is against user services. Regarding the routing table, my guess is that you should aggregate all the customer prefixes, in a small number of prefixes for each BRAS, PoP, etc., so no difference here with IPv4. Regards, Jordi -----Mensaje original----- De: <Olaf.Bonness(a)telekom.de> Responder a: <Olaf.Bonness(a)telekom.de> Fecha: Wed, 27 Jul 2011 15:49:27 +0200 Para: <ip(a)ioshints.info>, Jordi Palet Martinez <jordi.palet(a)consulintel.es> Asunto: AW: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers >Regarding Jordis question I've to add that regulatory agencies in some >countries are not voting for static/permanent prefix delegation to >customers, because of privacy reasons. > >Kind regards >Olaf > >> -----Ursprüngliche Nachricht----- >> Von: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] >> Im Auftrag von Ivan Pepelnjak >> Gesendet: Mittwoch, 27. Juli 2011 09:45 >> An: jordi.palet(a)consulintel.es; ipv6-wg(a)ripe.net >> Betreff: RE: [ipv6-wg] dynamic or static IPv6 prefixes to >> residential customers >> >> Unfortunately you have to do static prefix delegation because >> it's impossible to renumber the customer's inside LAN within >> a reasonable time interval with today's state of IPv6 SLAAC. >> >> However, static delegations might cause IPv6 routing table >> explosion unless you're very careful (with dynamic IPv4 >> address allocation you could define address pool on BRAS and >> advertise just the pool prefix into the rest of the network). >> >> Ivan >> >> > -----Original Message----- >> > From: ipv6-wg-admin(a)ripe.net >> [mailto:ipv6-wg-admin@ripe.net] On Behalf Of >> > JORDI PALET MARTINEZ >> > Sent: Wednesday, July 27, 2011 3:02 PM >> > To: ipv6-wg(a)ripe.net >> > Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential >> > customers >> > >> > Hi all, >> > >> > I will like to know, from those deploying IPv6 services to >> residential >> > customers, if you are planning to provide static or dynamic >> IPv6 prefixes. >> > >> > Just to be clear, I'm for static prefix delegation to residential >> > customers, however I heard that some ISPs are doing dynamic >> delegations, >> > the same way as is common today with IPv4. >> > >> > I don't thin it make sense, as the main reason for doing so >> in IPv4 was >> > address exhaustion and legacy oversubscription models such >> as PPP/dial-up. >> > >> > Regards, >> > Jordi >> > >> > PS: I've sent this question to NANOG, got very few answers, >> so trying here >> > ... >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.consulintel.es >> > The IPv6 Company >> > >> > This electronic message contains information which may be >> privileged or >> > confidential. The information is intended to be for the use of the >> > individual(s) named above. If you are not the intended >> recipient be aware >> > that any disclosure, copying, distribution or use of the >> contents of this >> > information, including attached files, is prohibited. >> > >> >> >> ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Re: is ok
by Aurelio Diaz Pereira 27 Jul '11

27 Jul '11

confirm 764810

1 0

RIPE-501 and IPSEC on CPEs
by Ahmed Abu-Abed 26 Jul '11

26 Jul '11

Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed

8 19

not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD
by Christian Seitz 26 Jul '11

26 Jul '11

Hello, we had an IPv6 path MTU discovery issue last week and I would like to discuss possible solutions here. The problem is a combination of not announcing IXP IPv6 peering prefixes in the global BGP table and activating loose uRPF at the border of a network. I made the following traceroutes and pings after deactivating loose uRPF at the border. Before this I did not see any packet from the LINX peering lan address 2001:7f8:4::d1c:1, because it is not announced to the global BGP table and therefore not routable. The traceroute ended after 2001:450:2001:800e::2 before. chris@router> traceroute 2a01:e0c:1:1599::1 source 2001:x:x:x::2 traceroute6 to 2a01:e0c:1:1599::1 (2a01:e0c:1:1599::1) from 2001:x:x:x::2, 64 hops max, 12 byte packets [...] 2 2001:450:2001:800e::2 (2001:450:2001:800e::2) 0.793 ms 0.611 ms 0.604 ms 3 2001:7f8:4::d1c:1 (2001:7f8:4::d1c:1) 25.692 ms 227.307 ms 18.160 ms 4 2001:1900:5:2::12e (2001:1900:5:2::12e) 26.565 ms 26.310 ms 26.248 ms 5 2a01:e00:2:9::1 (2a01:e00:2:9::1) 26.746 ms 28.774 ms 40.343 ms [...] An ICMP echo request packet with more than 1410 bytes (1450 byte incl. header) shows that there is a smaller MTU between two routers in the backbone of Level3: PING www.free.fr(www.free.fr) 1403 data bytes >From 2001:7f8:4::d1c:1 icmp_seq=86 Packet too big: mtu=1450 1411 bytes from www.free.fr: icmp_seq=87 ttl=53 time=41.5 ms [...] 2001:7f8:4::d1c:1 seems to be a router of Level3 at LINX. The next router 2001:1900:5:2::12e also has an IP address from the Level3 IPv6 allocation. There seems to be an MTU of 1450 bytes between those two routers. The router at LINX sends out an ICMP "Packet too big" with the source address of the interface where he sees the route to the source address. This is the LINX peering lan, which is currently not announced in BGP. We use loose uRPF at the border to drop all packets from source addresses that are not globally routed. The ICMP "Packet too big" gets lost and path MTU discovery is broken. Communication with big packets is not possible. Some IXPs decided not to announce their peering lan prefixes for some reasons, but in combination with loose uRPF this leads to problems like this one. I would like to discuss the best current practise and possible solutions here. Possible solutions from my point of view: 1) Do not activate loose uRPF at the border of any network. 2) Any network where loose uRPF is configured at the border has to configure static routes for the IXP ranges of every RIR and redistribute them in the IGP so there is a valid route for loose uRPF checks. 3) IXPs announce their peering lan prefixes in the global BGP table and make loose uRPF work for the rest of the world. Members of the IXPs should possibly filter BGP announcements of the IXP peering lan prefixes from external peers when they do not use "next-hop-self" in iBGP within their network. 4) Remove tunnels, use native IPv6. There will always be links with an MTU lower than 1500 byte (access), so this is possibly not the best solution. 5) ? Regards from Berlin, Chris

7 11

Reminder: Global IPv6 Deployment Monitoring Survey 2011
by Paul Rendek 25 Jul '11

25 Jul '11

[Apologies for duplicate mails] Dear Colleagues, There's just one week left to complete the Global IPv6 Deployment Monitoring Survey 2011. Take part online now at: http://www.surveymonkey.com/s/GlobalIPv6survey2011 This survey has been designed by GNKS Consult in collaboration with TNO and the RIPE NCC to further understand where the community stands on IPv6 and what needs be done to ensure that the Internet community is ready for the widespread adoption of IPv6. Anyone can participate in this survey and we hope that the results will establish a comprehensive view of current IPv6 penetration and future plans for IPv6 deployment. The survey comprises 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments or who have not yet deployed IPv6, there will be fewer questions. The survey will close on 31 July 2011. We thank you for your time and interest in completing this survey. If you have any questions concerning the survey, please email <info(a)gnksconsult.com>. For more information about the survey and links to previous year's survey results, please see: https://www.ripe.net/internet-coordination/news/industry-developments/globa… Regards, Paul Rendek RIPE NCC Head of External Relations and Communication

1 0

next version of RIPE-501, v.2
by Jan Zorz ＠ go6.si 25 Jul '11

25 Jul '11

Hi, Please find attached document with many ideas and suggestions included, LB spec is also there. As usual, all comments warmly welcome. Cheers, Jan

5 15

RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
by Ivan Pepelnjak 22 Jul '11

22 Jul '11

Let me try to understand: (A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. Was someone reading too much Kafka or The Good Soldier Švejk lately? Ivan > -----Original Message----- > From: Jan Zorz @ Go6.si [mailto:jan@go6.si] > Sent: Monday, July 18, 2011 5:13 PM > To: Ivan Pepelnjak; 'Sander Steffann'; 'Yannis Nikolopoulos' > Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Going to production it was said :) > > I did a long discussion with Alex Le Heux (RIPE IPRA) about the same > issue, his advice was that. > > Jan > > Ivan Pepelnjak <ipepelnjak(a)gmail.com> wrote: > > >Extremely helpful advice from the ops perspective. > > > >> Trade in your /32 and get something bigger under initial alloc > >> conditions... :) > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.

21 55

Re: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
by Sander Steffann 19 Jul '11

19 Jul '11

Hi, >> Some years ago... in other mail like this... "You want to change how IPv4 >> routing works? And RIP? >> >> http://tools.ietf.org/html/rfc4632 ;-) > > That's fine but thats not a function of RIPE but rather 'other places' The RIPE IPv6 WG (ipv6-wg(a)ripe.net) has volunteered for continuing this discussion :-) Sander

1 0

additional IPv6 allocation (ripe-512 issues)
by Yannis Nikolopoulos 18 Jul '11

18 Jul '11

hello all, Lately we've been trying to lay out a future-proof IPv6 addressing plan (actually, to revise our initial IPv6 plan from a few years back) and we came to the conclusion that if we were to plan ahead for a few years, we would need an extra IPv6 allocation from RIPE, one more /32 (we already have one). Well, according to ripe-512 we're not eligible for a subsequent allocation yet, since we haven't met the subsequent allocation criteria (HD ratio). We'll be offering our commercial dual stack services (broadband, leased-lines VPNs) next year. This means that we'll have 1,2M potential subscribers (/56) just for the retail service. And then there's all the /48s for the VPNs and bigger customers. I'm not saying that all of our customers will migrate to IPv6 at once but we have to plan, don't we? And then there's the growth factor to be considered also... For us, this extra /32 will make the difference between an efficient and future-proof addressing plan that will last for many years and one that will have to be revised after 2-3 years (with all the readdressing etc). I thought that one of the key advantages with IPv6 was the fact that we would get rid of readdressing. What I'm trying to say is that ripe-512 is not flexible enough. In the end, should we planning ahead for many years (as per RFC6177) or not? any thoughts? cheers, Yannis

3 2