From alh-ietf at tndh.net Mon May 2 15:31:08 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 2 May 2011 06:31:08 -0700 Subject: [ipv6-wg] IPv6 theme day on RIPE 62 In-Reply-To: <91B22341-3C27-4058-9663-CF015AC26745@marcoh.net> References: <91B22341-3C27-4058-9663-CF015AC26745@marcoh.net> Message-ID: <020501cc08cd$338d06e0$9aa714a0$@net> While it is good to hear that Rob is finally 'taking IPv6 seriously', the actions of the remote webcast team state otherwise. There is a AAAA for webcast.ripe.net, but all attempts to connect to it for rtsp over IPv6 fail. Http over ipv6 to port 1935 does get a response from the macromedia service, but vlc always gives up on ipv6 and reverts to ipv4. Tony > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Marco Hogewoning > Sent: Friday, April 29, 2011 1:43 AM > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] IPv6 theme day on RIPE 62 > > Dear colleagues, > > For those of you who missed out on the original announcement and who > are wondering why we haven't published an agenda yet. The upcoming RIPE > Meeting does not have a formal seating of the IPv6 Working Group. Given > the amount of content and the current state of affairs, the collective > chairs decided to dedicate a full day to the topic. > > So Tuesday's plenary session will be all about IPv6, covering a broad > range of topics. We have talks about the state of the world, overviews > of the available transitioning techniques and various presentations > from people who already deployed IPv6 in their network. We are still > busy with the final details of the agenda and the time schedule, but > this is what we already have scheduled: > > Dynamic IPv4 Address Release - Olaf Bonness > > Transition Technologies Overview - Marco Hogewoning > > IPv6 Mobility in Emergency Teams - Jan ?or? > > RIPE 501 bis - Jan ?or? et al > > IPv6 Routing Table Update - Gert D?ring > > IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) > > IPv6 Issues on AMS-IX Peering LAN - Arien Vijn > > Deploying IPv6 Without Huge Costs - Case Study > > IPv6 Geolocation - TBD > > IPv6 Pending Badge Initiative - INEX > > IPv6 CPE survey: Initial results - Mirjam Kuehne > > As stated we are still busy with the final details and some speakers, > for the latest updates please refer to the meeting plan at > http://ripe62.ripe.net/programme/meeting-plan/plenary > > For those who can't make it to Amsterdam, all the sessions will be > broadcasted on the Internet and available for remote participation. > Details for the webcast will be posted on http://ripe62.ripe.net, > session will start at 09:00 CEST. > > For those coming to the meeting, save travels and see you next week, > > > The IPv6 Working Group co-chairs. > > Marco, Shane and David > > Grtx, > > MarcoH From marcoh at marcoh.net Mon May 2 16:45:53 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 2 May 2011 16:45:53 +0200 Subject: [ipv6-wg] IPv6 theme day on RIPE 62 In-Reply-To: <020501cc08cd$338d06e0$9aa714a0$@net> References: <91B22341-3C27-4058-9663-CF015AC26745@marcoh.net> <020501cc08cd$338d06e0$9aa714a0$@net> Message-ID: Hey Tony, Thanks for noticing. I talked to ops, they are looking into the matter. Grtx, MarcoH On May 2, 2011, at 3:31 PM, Tony Hain wrote: > While it is good to hear that Rob is finally 'taking IPv6 seriously', the > actions of the remote webcast team state otherwise. There is a AAAA for > webcast.ripe.net, but all attempts to connect to it for rtsp over IPv6 fail. > Http over ipv6 to port 1935 does get a response from the macromedia service, > but vlc always gives up on ipv6 and reverts to ipv4. > > Tony > > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf >> Of Marco Hogewoning >> Sent: Friday, April 29, 2011 1:43 AM >> To: ipv6-wg at ripe.net >> Subject: [ipv6-wg] IPv6 theme day on RIPE 62 >> >> Dear colleagues, >> >> For those of you who missed out on the original announcement and who >> are wondering why we haven't published an agenda yet. The upcoming RIPE >> Meeting does not have a formal seating of the IPv6 Working Group. Given >> the amount of content and the current state of affairs, the collective >> chairs decided to dedicate a full day to the topic. >> >> So Tuesday's plenary session will be all about IPv6, covering a broad >> range of topics. We have talks about the state of the world, overviews >> of the available transitioning techniques and various presentations >> from people who already deployed IPv6 in their network. We are still >> busy with the final details of the agenda and the time schedule, but >> this is what we already have scheduled: >> >> Dynamic IPv4 Address Release - Olaf Bonness >> >> Transition Technologies Overview - Marco Hogewoning >> >> IPv6 Mobility in Emergency Teams - Jan ?or? >> >> RIPE 501 bis - Jan ?or? et al >> >> IPv6 Routing Table Update - Gert D?ring >> >> IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) >> >> IPv6 Issues on AMS-IX Peering LAN - Arien Vijn >> >> Deploying IPv6 Without Huge Costs - Case Study >> >> IPv6 Geolocation - TBD >> >> IPv6 Pending Badge Initiative - INEX >> >> IPv6 CPE survey: Initial results - Mirjam Kuehne >> >> As stated we are still busy with the final details and some speakers, >> for the latest updates please refer to the meeting plan at >> http://ripe62.ripe.net/programme/meeting-plan/plenary >> >> For those who can't make it to Amsterdam, all the sessions will be >> broadcasted on the Internet and available for remote participation. >> Details for the webcast will be posted on http://ripe62.ripe.net, >> session will start at 09:00 CEST. >> >> For those coming to the meeting, save travels and see you next week, >> >> >> The IPv6 Working Group co-chairs. >> >> Marco, Shane and David >> >> Grtx, >> >> MarcoH > From bohara at ripe.net Mon May 2 17:05:32 2011 From: bohara at ripe.net (Ben O'Hara) Date: Mon, 2 May 2011 17:05:32 +0200 Subject: [ipv6-wg] IPv6 theme day on RIPE 62 In-Reply-To: References: <91B22341-3C27-4058-9663-CF015AC26745@marcoh.net> <020501cc08cd$338d06e0$9aa714a0$@net> Message-ID: Hi Tony, We;re looking into this, its strange as network connectivity to webcast.ripe.net:1935 works fine and we see over 50% of viewers watching over ipv6. Testing with VLC i do see the same thing, but I can see curl connects to the stream OK. bohara at titan:~> curl -6 rtsp://webcast.ripe.net:1935/ripe/live -vvvv * About to connect() to webcast.ripe.net port 1935 (#0) * Trying 2001:67c:2e8:3::c100:a2... connected * Connected to webcast.ripe.net (2001:67c:2e8:3::c100:a2) port 1935 (#0) > OPTIONS * RTSP/1.0 > CSeq: 1 > User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.20 libssh2/1.2.6 > < RTSP/1.0 200 OK < Supported: play.basic, con.persistent < Cseq: 1 < Server: Wowza Media Server 2.1.2 build24878 < Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER < * Connection #0 to host webcast.ripe.net left intact * Closing connection #0 I'll continue to look into this but rest assured we arnt missing v6 support on purpose! Ben On 2 May 2011, at 16:45, Marco Hogewoning wrote: > Hey Tony, > > Thanks for noticing. I talked to ops, they are looking into the matter. > > Grtx, > > MarcoH > > On May 2, 2011, at 3:31 PM, Tony Hain wrote: > >> While it is good to hear that Rob is finally 'taking IPv6 seriously', the >> actions of the remote webcast team state otherwise. There is a AAAA for >> webcast.ripe.net, but all attempts to connect to it for rtsp over IPv6 fail. >> Http over ipv6 to port 1935 does get a response from the macromedia service, >> but vlc always gives up on ipv6 and reverts to ipv4. >> >> Tony >> >> >>> -----Original Message----- >>> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf >>> Of Marco Hogewoning >>> Sent: Friday, April 29, 2011 1:43 AM >>> To: ipv6-wg at ripe.net >>> Subject: [ipv6-wg] IPv6 theme day on RIPE 62 >>> >>> Dear colleagues, >>> >>> For those of you who missed out on the original announcement and who >>> are wondering why we haven't published an agenda yet. The upcoming RIPE >>> Meeting does not have a formal seating of the IPv6 Working Group. Given >>> the amount of content and the current state of affairs, the collective >>> chairs decided to dedicate a full day to the topic. >>> >>> So Tuesday's plenary session will be all about IPv6, covering a broad >>> range of topics. We have talks about the state of the world, overviews >>> of the available transitioning techniques and various presentations >>> from people who already deployed IPv6 in their network. We are still >>> busy with the final details of the agenda and the time schedule, but >>> this is what we already have scheduled: >>> >>> Dynamic IPv4 Address Release - Olaf Bonness >>> >>> Transition Technologies Overview - Marco Hogewoning >>> >>> IPv6 Mobility in Emergency Teams - Jan ?or? >>> >>> RIPE 501 bis - Jan ?or? et al >>> >>> IPv6 Routing Table Update - Gert D?ring >>> >>> IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) >>> >>> IPv6 Issues on AMS-IX Peering LAN - Arien Vijn >>> >>> Deploying IPv6 Without Huge Costs - Case Study >>> >>> IPv6 Geolocation - TBD >>> >>> IPv6 Pending Badge Initiative - INEX >>> >>> IPv6 CPE survey: Initial results - Mirjam Kuehne >>> >>> As stated we are still busy with the final details and some speakers, >>> for the latest updates please refer to the meeting plan at >>> http://ripe62.ripe.net/programme/meeting-plan/plenary >>> >>> For those who can't make it to Amsterdam, all the sessions will be >>> broadcasted on the Internet and available for remote participation. >>> Details for the webcast will be posted on http://ripe62.ripe.net, >>> session will start at 09:00 CEST. >>> >>> For those coming to the meeting, save travels and see you next week, >>> >>> >>> The IPv6 Working Group co-chairs. >>> >>> Marco, Shane and David >>> >>> Grtx, >>> >>> MarcoH >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1731 bytes Desc: not available URL: From alh-ietf at tndh.net Tue May 3 15:51:39 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 3 May 2011 06:51:39 -0700 Subject: [ipv6-wg] IPv6 theme day on RIPE 62 In-Reply-To: References: <91B22341-3C27-4058-9663-CF015AC26745@marcoh.net> <020501cc08cd$338d06e0$9aa714a0$@net> Message-ID: <05b101cc0999$3ba531f0$b2ef95d0$@net> I could not replicate the curl test because rtsp is not enabled in libcurl on my OS X install (something to work on later). For some reason vlc is not even working for IPv4 today for either OS X or W7. As some additional information, chrome on OS X will only play the flash feed in IPv4, but in the W7 VM on the same box IE plays the flash stream in IPv6. OS X> netstat -an|grep 1935 tcp4 0 0 192.168.123.131.50340 193.0.0.162.1935 ESTABLISHED W7> netstat -ano|find "1935" TCP [2001:470:e930:d0d0:2d36:c4c7:4baf:e4f1]:27023 [2001:67c:2e8:3::c100:a2]:1935 ESTABLISHED 29228 Tony > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Ben O'Hara > Sent: Monday, May 02, 2011 8:06 AM > To: Marco Hogewoning > Cc: Tony Hain; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] IPv6 theme day on RIPE 62 > > Hi Tony, > > We;re looking into this, its strange as network connectivity to > webcast.ripe.net:1935 works fine and we see over 50% of viewers > watching over ipv6. > > Testing with VLC i do see the same thing, but I can see curl connects > to the stream OK. > > bohara at titan:~> curl -6 rtsp://webcast.ripe.net:1935/ripe/live -vvvv > * About to connect() to webcast.ripe.net port 1935 (#0) > * Trying 2001:67c:2e8:3::c100:a2... connected > * Connected to webcast.ripe.net (2001:67c:2e8:3::c100:a2) port 1935 > (#0) > > OPTIONS * RTSP/1.0 > > CSeq: 1 > > User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 > OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.20 libssh2/1.2.6 > > > < RTSP/1.0 200 OK > < Supported: play.basic, con.persistent > < Cseq: 1 > < Server: Wowza Media Server 2.1.2 build24878 > < Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, > RECORD, GET_PARAMETER > < > * Connection #0 to host webcast.ripe.net left intact > * Closing connection #0 > > I'll continue to look into this but rest assured we arnt missing v6 > support on purpose! > > Ben > > On 2 May 2011, at 16:45, Marco Hogewoning wrote: > > > Hey Tony, > > > > Thanks for noticing. I talked to ops, they are looking into the > matter. > > > > Grtx, > > > > MarcoH > > > > On May 2, 2011, at 3:31 PM, Tony Hain wrote: > > > >> While it is good to hear that Rob is finally 'taking IPv6 > seriously', the > >> actions of the remote webcast team state otherwise. There is a AAAA > for > >> webcast.ripe.net, but all attempts to connect to it for rtsp over > IPv6 fail. > >> Http over ipv6 to port 1935 does get a response from the macromedia > service, > >> but vlc always gives up on ipv6 and reverts to ipv4. > >> > >> Tony > >> > >> > >>> -----Original Message----- > >>> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On > Behalf > >>> Of Marco Hogewoning > >>> Sent: Friday, April 29, 2011 1:43 AM > >>> To: ipv6-wg at ripe.net > >>> Subject: [ipv6-wg] IPv6 theme day on RIPE 62 > >>> > >>> Dear colleagues, > >>> > >>> For those of you who missed out on the original announcement and > who > >>> are wondering why we haven't published an agenda yet. The upcoming > RIPE > >>> Meeting does not have a formal seating of the IPv6 Working Group. > Given > >>> the amount of content and the current state of affairs, the > collective > >>> chairs decided to dedicate a full day to the topic. > >>> > >>> So Tuesday's plenary session will be all about IPv6, covering a > broad > >>> range of topics. We have talks about the state of the world, > overviews > >>> of the available transitioning techniques and various presentations > >>> from people who already deployed IPv6 in their network. We are > still > >>> busy with the final details of the agenda and the time schedule, > but > >>> this is what we already have scheduled: > >>> > >>> Dynamic IPv4 Address Release - Olaf Bonness > >>> > >>> Transition Technologies Overview - Marco Hogewoning > >>> > >>> IPv6 Mobility in Emergency Teams - Jan ?or? > >>> > >>> RIPE 501 bis - Jan ?or? et al > >>> > >>> IPv6 Routing Table Update - Gert D?ring > >>> > >>> IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) > >>> > >>> IPv6 Issues on AMS-IX Peering LAN - Arien Vijn > >>> > >>> Deploying IPv6 Without Huge Costs - Case Study > >>> > >>> IPv6 Geolocation - TBD > >>> > >>> IPv6 Pending Badge Initiative - INEX > >>> > >>> IPv6 CPE survey: Initial results - Mirjam Kuehne > >>> > >>> As stated we are still busy with the final details and some > speakers, > >>> for the latest updates please refer to the meeting plan at > >>> http://ripe62.ripe.net/programme/meeting-plan/plenary > >>> > >>> For those who can't make it to Amsterdam, all the sessions will be > >>> broadcasted on the Internet and available for remote participation. > >>> Details for the webcast will be posted on http://ripe62.ripe.net, > >>> session will start at 09:00 CEST. > >>> > >>> For those coming to the meeting, save travels and see you next > week, > >>> > >>> > >>> The IPv6 Working Group co-chairs. > >>> > >>> Marco, Shane and David > >>> > >>> Grtx, > >>> > >>> MarcoH > >> > > > > From mir at ripe.net Wed May 4 16:13:23 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 04 May 2011 16:13:23 +0200 Subject: [ipv6-wg] IPv6 RIPEness - One Year later Message-ID: <4DC15F03.7080300@ripe.net> [apologies for duplicates] Dear colleagues, A year ago we introduced IPv6 RIPEness - a system that rates IPv6 deployment of Local Internet Registries based on certain criteria. Now, one year later, we were curious to see how the numbers have changed. Please read the update on RIPE Labs: http://labs.ripe.net/Members/becha/ipv6-ripeness-one-year-later Kind Regards, Mirjam Kuehne RIPE NCC From mir at ripe.net Wed May 11 11:24:39 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 11 May 2011 11:24:39 +0200 Subject: [ipv6-wg] RIPE NCC Measurements for World IPv6 Day Message-ID: <4DCA55D7.8030707@ripe.net> [apologies for duplicates] Dear colleagues, Please find on RIPE Labs a description of the measurements the RIPE NCC is doing prior to and on World IPv6 Day: http://labs.ripe.net/Members/emileaben/ripe-ncc-measurements-for-world-ipv6-day This is an extended version of the presentation Emile Aben gave in the MAT-WG at RIPE62. Feedback received at the meeting, has been incorporated. Please also note the call for participation for each of the measurements described in the article. If you have any other feedback or questions, please do not hesitate to contact us at labs at ripe.net. Kind Regards, Mirjam Kuehne RIPE NCC From millnert at gmail.com Tue May 17 11:49:13 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 17 May 2011 05:49:13 -0400 Subject: [ipv6-wg] Thought for World IPv6 Day Message-ID: Hi, I'm thinking that in order for maximizing productive yield of World IPv6 Day as IPv6-believers would like, laying out the relevant steps to take for ISPs, content providers and individual users in a pedagogical manner could be cool (i.e highly useful). I'm imagining something similar to what Google did with http://www.google.com/googlebooks/chrome/index.html for Chrome. I have no idea who would be in charge to bring that about, or if it is at all possible to achieve in the few days left. I hope others are better suited to answer this. Cheers, Martin From gribozavr at gmail.com Tue May 17 18:11:03 2011 From: gribozavr at gmail.com (Dmitri Gribenko) Date: Tue, 17 May 2011 19:11:03 +0300 Subject: [ipv6-wg] Thought for World IPv6 Day In-Reply-To: References: Message-ID: On Tue, May 17, 2011 at 12:49 PM, Martin Millnert wrote: > I'm thinking that in order for maximizing productive yield of World > IPv6 Day as IPv6-believers would like, laying out the relevant steps > to take for ISPs, content providers and individual users in a > pedagogical manner could be cool (i.e highly useful). I think that most users don't really care about how IPv4/v6 works, they just want "the Internet" to work. This is opposed to browsers, where users should actually understand the concept of e.g., tabs, in order to use them. Advanced users can easily find technical articles about IPv6 at any time, for example (shameless self-promotion): http://www.debian-administration.org/article/655/Running_IPv6_in_practice IIRC, there was a wiki with a list of typical IPv6 brokenness in different environments (OSes, presence of a NAT etc.), but I can't find a link. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ From sander at steffann.nl Tue May 17 22:42:05 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 17 May 2011 22:42:05 +0200 Subject: [ipv6-wg] Thought for World IPv6 Day In-Reply-To: References: Message-ID: <64797DC4-3DD6-48AC-B7CC-432BBB1D2C88@steffann.nl> Hi, > IIRC, there was a wiki with a list of typical IPv6 brokenness in > different environments (OSes, presence of a NAT etc.), but I can't > find a link. This one? http://www.getipv6.info/index.php/Customer_problems_that_could_occur - Sander From millnert at gmail.com Tue May 17 23:10:41 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 17 May 2011 17:10:41 -0400 Subject: [ipv6-wg] Thought for World IPv6 Day In-Reply-To: References: Message-ID: Dmitri, On Tue, May 17, 2011 at 12:11 PM, Dmitri Gribenko wrote: > On Tue, May 17, 2011 at 12:49 PM, Martin Millnert wrote: >> I'm thinking that in order for maximizing productive yield of World >> IPv6 Day as IPv6-believers would like, laying out the relevant steps >> to take for ISPs, content providers and individual users in a >> pedagogical manner could be cool (i.e highly useful). > > I think that most users don't really care about how IPv4/v6 works, > they just want "the Internet" to work. ?This is opposed to browsers, > where users should actually understand the concept of e.g., tabs, in > order to use them. ?Advanced users can easily find technical articles > about IPv6 at any time, for example (shameless self-promotion): > http://www.debian-administration.org/article/655/Running_IPv6_in_practice Note that I did not say the only audience of the comic would be end-users. I think it's fair to say that the depth the Chrome comic goes to is beyond what 99.999% of users care about, as well. "Normal" users would probably be pretty satisfied with a summary regarding Chrome that explained "New tabs method: independent, faster, safer and crash less.". What the comic does however is to document the product in a quite unique and IMO very effective way. Judging by how as few as 0.2% of Google's users have IPv6, I'd say it's pretty fair to say that most ISPs world-wide don't *really* care about IPv6 either, and a lot of them likely don't have a good idea how to go about bringing it up, despite a complete myriad of available (fragmented) information online. I really do think a similar effort on "IPv6" could be valuable, even if it was not completed by the first World IPv6 Day. In fact, it may be more valuable if done well, than rushed for World IPv6 day. Thanks! Cheers, Martin From millnert at gmail.com Tue May 17 23:41:39 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 17 May 2011 17:41:39 -0400 Subject: [ipv6-wg] Thought for World IPv6 Day In-Reply-To: References: Message-ID: Hi again Dmitri, and IPv6-wg sorry for double-post (though different content), I want to elaborate on a point Dmitri brought up. On Tue, May 17, 2011 at 12:11 PM, Dmitri Gribenko wrote: > I think that most users don't really care about how IPv4/v6 works, > they just want "the Internet" to work. I think this premise is a bit false. I can chose several ways to exemplify what I think. I will try the following: Judging by how automatic IPv6-transition methods have in the IETF now by pretty near consensus been judged in-adequate for IPv6 access, I think it's quite fair to say that the IPv4 and the IPv6 internet are two completely separate networks. At the very least the IPv4 internetwork as a whole does *not* connect to the IPv6 network. Individual hosts may via manually configured connections do so, such as you explain in your debian-administrator's article, but the network as a whole does not. They are for all intents and purposes disconnected networks. IPv6 advocates presumably advocate for IPv6 deployment in order to preserve the 'pure' end-to-end principle of the Internet. Many of us think users don't care about being behind a NAT, but another many do realize the limits this sets on applications to interact freely and how necessary and useful the principle is for the continued success of a, IMO desirable, 'prosumer' Internet of the future. My point is, if (more) end-users actually knew the benefits of IPv6 (because there are benefits (right?)), and the risks of not getting IPv6 in the future, they may well be more inclined to wish for it, which may unlock another business decision problem at service providers (no user demand). I'm not expecting 'my grandmother' to care, but I do think a good measure of success of someone explaining the difference between IPv4 exhaustion/CGN and IPv6, is that my grandmother understood the difference, *at some level*. :) (**Not** saying this is the way to do it: I do have an analogy with vehicle registration plates which works in Sweden at least, because there they are of a fixed size, [A-Z]{3}-[0-9]{3). They've been issued serially, in increasing lexicographic order, and are about to run out. All cars are required to have a unique serial number to drive on the roads. (Some old cars have been scrapped which does free up their number, but the demand is still going to surpass the supply.) Since going by bus limits your freedom where you can go on the roads, the vehicle registration agency has to figure out a way to make the plates wider. I have used this analogy on 'laymen' several times and it seems to do a good enough job. The question of perceived immediate benefits for a typical user is harder to address, because the applications that really take advantage of IPv6 are few today, but this is about the future and your freedom to not travel by bus.) So I do think, much in same way the Chrome article goes about explaining things most users did not knew about a web browser, the benefits of a IPv6 Internet over a IPv4 CGN Internet *could* be explained. Just my 0.00042 grams of gold. Cheers, Martin From tjc at ecs.soton.ac.uk Wed May 18 11:16:56 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 18 May 2011 10:16:56 +0100 Subject: [ipv6-wg] Thought for World IPv6 Day In-Reply-To: <64797DC4-3DD6-48AC-B7CC-432BBB1D2C88@steffann.nl> References: <64797DC4-3DD6-48AC-B7CC-432BBB1D2C88@steffann.nl> Message-ID: On 17 May 2011, at 21:42, Sander Steffann wrote: > Hi, > >> IIRC, there was a wiki with a list of typical IPv6 brokenness in >> different environments (OSes, presence of a NAT etc.), but I can't >> find a link. > > This one? > http://www.getipv6.info/index.php/Customer_problems_that_could_occur And since the Americas have their 'Day' start late afternoon on 7th June, any unexpected issues will be documented by the time we wake up on 8th.... thanks guys :) Tim From ebais at a2b-internet.com Wed May 18 12:51:18 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 18 May 2011 12:51:18 +0200 Subject: [ipv6-wg] IPv6 filtering in an ISP environment Message-ID: <003501cc1549$84b19c10$8e14d430$@com> Hi, I'm looking for examples on what people have implemented as ingress filtering for IPv6 prefixes in an BGP environment. I'm would like to get some sort of filter that will not require daily maintenance based on assigned prefixes by the RIR. I'm leaning towards having some sort of filtering based on: Drop anything from bogon list allow RIR PA space - between /12 - /35 Allow RIR PI space between /32 - /48. (For instance for the RIPE 2001:67c::/32 & 2001:7f8::/32 parts ) So basically, a bit more strict filter than allow 2003::/3 and not having to update it daily with each assignment made J Also some insight in why you have selected to filter on a specific prefix length is very helpful. Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Wed May 18 13:42:12 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 18 May 2011 13:42:12 +0200 Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <20110518113733.GA90700@Space.Net> References: <003501cc1549$84b19c10$8e14d430$@com> <20110518113733.GA90700@Space.Net> Message-ID: <005a01cc1550$a0be1300$e23a3900$@com> > Packet filtering, or BGP filtering? BGP prefix filtering. Regards, Erik From gert at space.net Wed May 18 13:37:33 2011 From: gert at space.net (Gert Doering) Date: Wed, 18 May 2011 13:37:33 +0200 Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <003501cc1549$84b19c10$8e14d430$@com> References: <003501cc1549$84b19c10$8e14d430$@com> Message-ID: <20110518113733.GA90700@Space.Net> Hi, On Wed, May 18, 2011 at 12:51:18PM +0200, Erik Bais wrote: > I'm looking for examples on what people have implemented as ingress > filtering for IPv6 prefixes in an BGP environment. Packet filtering, or BGP filtering? Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Wed May 18 13:51:09 2011 From: gert at space.net (Gert Doering) Date: Wed, 18 May 2011 13:51:09 +0200 Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <005a01cc1550$a0be1300$e23a3900$@com> References: <003501cc1549$84b19c10$8e14d430$@com> <20110518113733.GA90700@Space.Net> <005a01cc1550$a0be1300$e23a3900$@com> Message-ID: <20110518115109.GB90700@Space.Net> Hi, On Wed, May 18, 2011 at 01:42:12PM +0200, Erik Bais wrote: > > Packet filtering, or BGP filtering? > BGP prefix filtering. I have started to write down some recommendations, plus some discussion that goes with it... http://www.space.net/~gert/RIPE/ipv6-filters.html ... it doesn't reflect the outcome of the "how much deaggregation does the operator community permit?" discussion in the routing WG yet (mainly because I don't think there *is* any consensus yet), but it's at least something to get your thoughts started. Do not use these as-is without adaption to your local policies (PS: if I have missed any new netblocks that have different allocation rules, plesae let me know) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From Jasper.Jans at espritxb.nl Wed May 18 13:37:49 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Wed, 18 May 2011 13:37:49 +0200 Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <003501cc1549$84b19c10$8e14d430$@com> References: <003501cc1549$84b19c10$8e14d430$@com> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B071504@EXCH01.campus.local> Erik, I'm also looking for some - lets call them best practices. At the moment we run a filter that allows PA+PI space upto a /48 - so a single combined filter. Met vriendelijke groet, Jasper Jans From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Erik Bais Sent: Wednesday, May 18, 2011 12:51 PM To: ipv6-wg at ripe.net Subject: [ipv6-wg] IPv6 filtering in an ISP environment Hi, I'm looking for examples on what people have implemented as ingress filtering for IPv6 prefixes in an BGP environment. I'm would like to get some sort of filter that will not require daily maintenance based on assigned prefixes by the RIR. I'm leaning towards having some sort of filtering based on: Drop anything from bogon list allow RIR PA space - between /12 - /35 Allow RIR PI space between /32 - /48. (For instance for the RIPE 2001:67c::/32 & 2001:7f8::/32 parts ) So basically, a bit more strict filter than allow 2003::/3 and not having to update it daily with each assignment made :) Also some insight in why you have selected to filter on a specific prefix length is very helpful. Erik Bais ________________________________ Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekkas at netcore.fi Wed May 18 16:23:33 2011 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 18 May 2011 17:23:33 +0300 (EEST) Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <20110518115109.GB90700@Space.Net> References: <003501cc1549$84b19c10$8e14d430$@com> <20110518113733.GA90700@Space.Net> <005a01cc1550$a0be1300$e23a3900$@com> <20110518115109.GB90700@Space.Net> Message-ID: On Wed, 18 May 2011, Gert Doering wrote: > http://www.space.net/~gert/RIPE/ipv6-filters.html ... > Do not use these as-is without adaption to your local policies > > (PS: if I have missed any new netblocks that have different allocation > rules, plesae let me know) JunOS strict filter does not work. Longest prefix matching semantics of filters differs from Cisco. The 5 more specific ranges of 2001::/32 are rejected. Those need to be put in a separate term as a workaround. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From heather.skanks at gmail.com Wed May 18 18:14:53 2011 From: heather.skanks at gmail.com (Heather Schiller) Date: Wed, 18 May 2011 12:14:53 -0400 Subject: [ipv6-wg] IPv6 filtering in an ISP environment In-Reply-To: <003501cc1549$84b19c10$8e14d430$@com> References: <003501cc1549$84b19c10$8e14d430$@com> Message-ID: Team Cymru does a nice job of keeping an updated bogon list.. it's on you to keep pulling it though to keep your local policy accurate. You can get it in a variety of formats as well: http://www.team-cymru.org/Services/Bogons/ They also maintain base filter templates: http://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/ --Heather On Wed, May 18, 2011 at 6:51 AM, Erik Bais wrote: > Hi, > > > > I?m looking for examples on what people have implemented as ingress > filtering for IPv6 prefixes in an BGP environment. > > > > I?m would like to get some sort of filter that will not require daily > maintenance based on assigned prefixes by the RIR. > > > > I?m leaning towards having some sort of filtering based on: > > > > Drop anything from bogon list > > > > allow RIR PA space ? between /12 - /35 > > Allow RIR PI space between /32 - /48. ?(For instance for the RIPE > 2001:67c::/32 & 2001:7f8::/32 parts ) > > > > So basically, a bit more strict filter than allow 2003::/3 and not having to > update it daily with each assignment made J > > > > Also some insight in why you have selected to filter on a specific prefix > length is very helpful. > > > > Erik Bais > > From mir at ripe.net Mon May 23 13:36:32 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 23 May 2011 13:36:32 +0200 Subject: [ipv6-wg] IPv6 CPE Survey - Initial Results on RIPE Labs Message-ID: <4DDA46C0.30303@ripe.net> [apologies for duplicates] Dear colleagues, Since we published the IPv6 customer premise equipment (CPE) survey during the RIPE 63 meeting, we received more than 100 responses. This new article on RIPE Labs shows some interesting initial results: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-results-may-2011 The survey is still open. If you are using an IPv6 capable CPE and have not yet filled in the survey, we would like to encourage you to do so. The survey can be found here: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate Kind Regards, Marco Hogewoning & Mirjam Kuehne RIPE NCC From training at ripe.net Mon May 23 14:26:40 2011 From: training at ripe.net (Training Mailbox) Date: Mon, 23 May 2011 14:26:40 +0200 Subject: [ipv6-wg] Announcement: RIPE NCC Training Courses Message-ID: <4DDA5280.50801@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/lir-services/training/courses/lir/outline/ - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/lir-services/training/courses/rr/ - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From Jasper.Jans at espritxb.nl Thu May 26 10:07:39 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 26 May 2011 10:07:39 +0200 Subject: [ipv6-wg] IPv6 on P2P links Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even to 'do not assign anything at all just use link-local' and access your devices over the loopback which your IGP will distribute. The last option seems interesting to me from a IP assignment point of few. It safes me having to allocate a block for this part of the infrastructure. I'm just wondering if in the long run it will not make life harder. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From EladH at bezeqint.co.il Thu May 26 10:18:59 2011 From: EladH at bezeqint.co.il (Elad Hefetz) Date: Thu, 26 May 2011 11:18:59 +0300 Subject: [ipv6-wg] IPv6 on P2P links Message-ID: <18D07E87680CDD48B628CC1483CA3B1B1DC71D13@london.bezeqint.co.il> The major problem I can assume happen when using only link local is the issue of replacing hardware. When you replace the cards on the routers it will require you to change the internal routing protocol (IS-IS \ OSPF). Another issue is debugging - when using trace route - all you will see is link-local addresses which make it very difficult to debug issues. We are configuring all our P2P links with /64 prefix on each link. This is not idle and very wasteful way, but it's the only solution to not interfere with RFCs and standards. Also - this is the only way to be multi vendors prepared, be ready for future to come with new IPv6 applications and products. MHO, Elad -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jasper Jans Sent: Thursday, May 26, 2011 11:08 AM To: ipv6-wg at ripe.net Subject: [ipv6-wg] IPv6 on P2P links Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even to 'do not assign anything at all just use link-local' and access your devices over the loopback which your IGP will distribute. The last option seems interesting to me from a IP assignment point of few. It safes me having to allocate a block for this part of the infrastructure. I'm just wondering if in the long run it will not make life harder. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imp_bezeqint_Toft0.jpg Type: image/jpeg Size: 21176 bytes Desc: not available URL: From us at sweet-sorrow.com Thu May 26 10:22:48 2011 From: us at sweet-sorrow.com (Us) Date: Thu, 26 May 2011 10:22:48 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Message-ID: <4DDE0DD8.9010206@sweet-sorrow.com> On 05/26/2011 10:07 AM, Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? > > I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even > to 'do not assign anything at all just use link-local' and access your devices over the loopback > which your IGP will distribute. > > The last option seems interesting to me from a IP assignment point of few. It safes me having > to allocate a block for this part of the infrastructure. I'm just wondering if in the long run > it will not make life harder. > > Jasper > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer > > > Our ISP is trying to stick with /64 P2P address space. But I've also seen by one of our upstream providers, that they use /112. I don't want to mention them, because their service sucks and the P2P global IPs cannot be pinged, while LL addresses work Us From gvandeve at cisco.com Thu May 26 10:30:40 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Thu, 26 May 2011 10:30:40 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <18D07E87680CDD48B628CC1483CA3B1B1DC71D13@london.bezeqint.co.il> References: <18D07E87680CDD48B628CC1483CA3B1B1DC71D13@london.bezeqint.co.il> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB7169@XMB-AMS-101.cisco.com> Inline: GV> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Elad Hefetz Sent: 26 May 2011 10:19 To: Jasper Jans; ipv6-wg at ripe.net Subject: RE: [ipv6-wg] IPv6 on P2P links The major problem I can assume happen when using only link local is the issue of replacing hardware. When you replace the cards on the routers it will require you to change the internal routing protocol (IS-IS \ OSPF). GV> this is incorrect, not? ISIS runs over CLNS and OSPFv3 just detects its neighbor by sending hello's. If you replace HW, then there is no impact on these protocols at all. Another issue is debugging - when using trace route - all you will see is link-local addresses which make it very difficult to debug issues. GV> depending on the vendor used it may actually give you a loopback address... because, how can a LL be the source of a ICMP unreachable reply? (the return packet would not be able to pass the link actually) We are configuring all our P2P links with /64 prefix on each link. This is not idle and very wasteful way, but it's the only solution to not interfere with RFCs and standards. GV> /127 is now ok also, and doesn't suffer from the well known ping-pong problem. Also - this is the only way to be multi vendors prepared, be ready for future to come with new IPv6 applications and products. MHO, Elad G/ -----Original Message----- From: ipv6-wg-admin at ripe.net mailto:[ipv6-wg-admin at ripe.net] On Behalf Of Jasper Jans Sent: Thursday, May 26, 2011 11:08 AM To: ipv6-wg at ripe.net Subject: [ipv6-wg] IPv6 on P2P links Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even to 'do not assign anything at all just use link-local' and access your devices over the loopback which your IGP will distribute. The last option seems interesting to me from a IP assignment point of few. It safes me having to allocate a block for this part of the infrastructure. I'm just wondering if in the long run it will not make life harder. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer ________________________________ This message was enriched by Impactia Technologies Ltd. www.impactia.com Please do not enrich emails sent to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 21176 bytes Desc: image001.jpg URL: From pymaunier at neotelecoms.com Thu May 26 10:31:18 2011 From: pymaunier at neotelecoms.com (Pierre-Yves Maunier) Date: Thu, 26 May 2011 10:31:18 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Message-ID: <20110526083118.GA3749@cilaos> On Thu, May 26, 2011 at 10:07:39AM +0200, Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? > > I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even > to 'do not assign anything at all just use link-local' and access your devices over the loopback > which your IGP will distribute. > > The last option seems interesting to me from a IP assignment point of few. It safes me having > to allocate a block for this part of the infrastructure. I'm just wondering if in the long run > it will not make life harder. > > Jasper > Hello, on our side we use /126 for P2P links. I've heard some others using /64 or /127. Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses. Here is my point of view on how we can subnet an IPv6 subnet : http://www.as8218.eu/frnog-ipv6-subnetting.pdf It's not intended to be a best practice but this is how I've done on AS8218 network (the example1 in the pdf from page 11 to 22). Have a look at page 17-18. Regards, -- Pierre-Yves Maunier AS8218 IP/Project Engineer tel +33 1 49 97 07 45 mob +33 6 30 92 18 36 fax +33 1 49 97 07 30 pymaunier at neotelecoms.com Neotelecoms 21 rue La Bo?tie, 75008 Paris, France From marcoh at marcoh.net Thu May 26 10:34:57 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 May 2011 10:34:57 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Message-ID: I would say it depends on which type of point-to-point links you are looking at. I used to be involved in a larger PPP-based DSL network, which only ran on Link-Local for the PPP links. Routing wise there wasn't much to go wrong there with the client having a default route pointing to the PPP link, which acts as a tunnel. From the central hub's perspective the only thing you need is a single static route (might be inserted via AAA) to the client side of the PPP. The only real caveats in this case are the fact the receiving end must be a bit of a weak host and at least capable of sourcing ICMP messages from another interface to make sure they are routed to the destination and not dropped because of scope rules. The great benefit is that is saves you the headache of keeping track of 2 IPv6 pools and the additional logging/reporting you may need to satisfy your local LEAs. In the core of the network it does make sense to run Global Unicast addresses on every interface. It makes troubleshooting much easier if you actually see ICMP coming from the correct interface instead of a central loopback address. The same might be the case for routing, having it point to a traceable address will probably make your life just that little bit more enjoyable. The one thing you have to keep in mind when you assign GUAs to your point-to-point. Is that while it make sense to assign /127 (or /126 as some people seem to insist on doing), it might be wise to always reserve the full /64 for that link. While most major vendors these days support /127 or are under a lot of pressure to do so, some still believe in rfc 3627 and follow it to the letter. I also came across people who stopped reading half way just after the part where the rfc says everything must be 64 bits. So while your current choice of vendor allows you to run smaller subnets, be prepared that somebody else isn't. You might be forced to switch back to /64 at some point in time after switching to another brand or some remote peer might not be able to be compliant. Having the /64 ready there might save you time and it also allows to put your links in easy to remember addresses. Grtx, MarcoH On May 26, 2011, at 10:07 AM, Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? > > I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even > to 'do not assign anything at all just use link-local' and access your devices over the loopback > which your IGP will distribute. > > The last option seems interesting to me from a IP assignment point of few. It safes me having > to allocate a block for this part of the infrastructure. I'm just wondering if in the long run > it will not make life harder. > > Jasper > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer > > From marcoh at marcoh.net Thu May 26 10:36:27 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 May 2011 10:36:27 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <20110526083118.GA3749@cilaos> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> Message-ID: <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> > on our side we use /126 for P2P links. I've heard some others using /64 or /127. > Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses. Curious, why did you pick /126 ? What do you do with ::0 and ::3 ? Marco From gvandeve at cisco.com Thu May 26 10:44:19 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Thu, 26 May 2011 10:44:19 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> When I was doing the config for Interop two weeks ago in Las vegas (I was the lead of the design and implementation there), then we used /127 actually... a weird thing from an engineering perspective is that addressing looks weird actually if one is used for /30's in a v4 world... For example: 2001:db8:C15c:0::/127 has as two addresses on the link: 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) and 2001:db8:C15c:0::1/127 While if it would have been a /126 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126 Which matches much more the /30 stuff in v4: 192.168.1.1/30 and 192.168.1.2/30 I can tell you many people were very confused about this little change and as result many made mistakes configuring p2p's during the Interop event G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Marco Hogewoning Sent: 26 May 2011 10:36 To: Pierre-Yves Maunier Cc: Jasper Jans; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links > on our side we use /126 for P2P links. I've heard some others using /64 or /127. > Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses. Curious, why did you pick /126 ? What do you do with ::0 and ::3 ? Marco From pymaunier at neotelecoms.com Thu May 26 10:46:50 2011 From: pymaunier at neotelecoms.com (Pierre-Yves Maunier) Date: Thu, 26 May 2011 10:46:50 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> Message-ID: <20110526084650.GB3749@cilaos> On Thu, May 26, 2011 at 10:36:27AM +0200, Marco Hogewoning wrote: > > on our side we use /126 for P2P links. I've heard some others using /64 or /127. > > Some allocate a /64 but configure a /126 to always have :1 and :2 in order to avoid mistakes by calculating the good hosts ip addresses. > > Curious, why did you pick /126 ? What do you do with ::0 and ::3 ? > > Marco I understand that you asked (and in fact we use /31 for IPv4 P2P links). The fact is that when I decided the addressing plan, I was looking for implementation stories from others and based on what I've read, we decided to go on /126. No real reasons. We're always open to look deeper and make changes if necessary. We had to make a decision at this time and we went to /126 over /127 mainly because of RFC3627. Our main goal was to deploy IPv6 and tried to quickly find a good way to subnet our block. Regards, -- Pierre-Yves Maunier AS8218 IP/Project Engineer tel +33 1 49 97 07 45 mob +33 6 30 92 18 36 fax +33 1 49 97 07 30 pymaunier at neotelecoms.com Neotelecoms 21 rue La Bo?tie, 75008 Paris, France From lerik at nolink.net Thu May 26 10:50:14 2011 From: lerik at nolink.net (Lars Erik Utsi Gullerud) Date: Thu, 26 May 2011 10:50:14 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4DDE1312.7010607@nolink.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <4DDE1312.7010607@nolink.net> Message-ID: <4DDE1446.6030701@nolink.net> On 26.05.2011 10:45, Lars Erik Utsi Gullerud wrote: > The reasoning behind /124 (rather than e.g. /127) for us, is simply to > make addressing more "human-readable" as well as simpler to manage in > terms of reverse DNS. Using /124 you always end up on a > "human-friendly" boundary so your networks are xx::10/124, xx::20/124, > xx::30/124 and so on, and you can then assign hosts that are always > like xx::10:1/124 + xx::10:2/124 (rather than having your tech staff > trying to sort out hexadecimal stuff in their heads). This also fits > very nicely with nibble addressing in ip6.arpa as every network is its > own "nibble". I believe someone wrote an I-D about using /124s a while > back, but my memory isn't what it used to be... Correcting myself here (not enough coffee yet) - the host addresses should of course be xx::11/124 and xx::12/124 and so on in the text above. :) Regards, Lars Erik From lerik at nolink.net Thu May 26 10:45:06 2011 From: lerik at nolink.net (Lars Erik Utsi Gullerud) Date: Thu, 26 May 2011 10:45:06 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Message-ID: <4DDE1312.7010607@nolink.net> On 26.05.2011 10:07, Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? > > I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even > to 'do not assign anything at all just use link-local' and access your devices over the loopback > which your IGP will distribute. At my current emplyer, we are using /124 on all P2P links in our network (which is a multi-vendor network) with no problems. We also used /124 at my previous employer for this purpose. From my perspective, /124 seems to be pretty common for internal P2P links. We use /64 for "external" P2P links, i.e. facing customers or on peering links etc. The reasoning behind /124 (rather than e.g. /127) for us, is simply to make addressing more "human-readable" as well as simpler to manage in terms of reverse DNS. Using /124 you always end up on a "human-friendly" boundary so your networks are xx::10/124, xx::20/124, xx::30/124 and so on, and you can then assign hosts that are always like xx::10:1/124 + xx::10:2/124 (rather than having your tech staff trying to sort out hexadecimal stuff in their heads). This also fits very nicely with nibble addressing in ip6.arpa as every network is its own "nibble". I believe someone wrote an I-D about using /124s a while back, but my memory isn't what it used to be... Regards, Lars Erik From marcoh at marcoh.net Thu May 26 11:13:04 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 May 2011 11:13:04 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> Message-ID: <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> > 2001:db8:C15c:0::/127 has as two addresses on the link: > 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) > and 2001:db8:C15c:0::1/127 > > While if it would have been a /126 > 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126 > > Which matches much more the /30 stuff in v4: > 192.168.1.1/30 and 192.168.1.2/30 > > I can tell you many people were very confused about this little change > and as result many made mistakes configuring p2p's during the Interop > event Yes it looks confusing, but that is the case anyway and unfortunately the IETF didn't make things easier in this case :( We have rfc 4291stating that interface identifiers for all unicast addresses unless those starting with binary 000 must be 64 bits, that one is standards track. At the same time we have rfc 3627, informational, which states that /127 is considered harmful and finally rfc 6164 which is on standards track again contradicting that by describing the use of /127 for router point-to-point links. So far in the field it seems even more confusing, I've seen various lengths over the years. Mostly you see /126, /127 and also I come across /112 a lot and recently a /124 popped up on this list as well. I have a feeling we are heading for another disaster with this. No I'm not predicting the end of the world, the internet turns out to be resilient enough to survive these kind of things, but there is a serious risk of running into compatibility issues. Where do vendors stand on this ? I know some are really sticking to /64 pointing to rfc 3627. Now with rfc 6164 "overruling", you might be able to convince them to start supporting /127 as well. But what to do with those cases that require different length subnets. These all seem mostly arbitrary decisions made by somebody, which get copied by others based on the "let's not try invent the wheel ourselves". So it still seems reasonable to always assign the /64, no matter what you configure on the box. As anything else might come back and haunt you one day. And, putting on my co-chair hat, is there anything this WG might be able to do in providing some advice to the audience. Maybe issue a BCP on how to handle such cases ? Grtx, Marco From Jasper.Jans at espritxb.nl Thu May 26 11:22:54 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 26 May 2011 11:22:54 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> Marco, You have pretty much nailed it there. There is a million ways to do it - there is more (or less) reason and rhyme to pick your favorite flavour of the day. And yes we have the whole "let's do what they do" approach. It still leaves me facing several RFCs that says different things, vendors that might or might not support things and an all together bigger mess than I was hoping for. Anything that can be put forward as a clear cut proposal on how to handle these addressing cases would be appreciated from my point of view. It might even be something to whack your vendor over the head with - not much different from the IPv6 feature list that was put together that is now being used in tenders with regards to IPv6 feature parity. Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans at espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. -----Original Message----- From: Marco Hogewoning [mailto:marcoh at marcoh.net] Sent: Thursday, May 26, 2011 11:13 AM To: Gunter Van de Velde Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links > 2001:db8:C15c:0::/127 has as two addresses on the link: > 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) > and 2001:db8:C15c:0::1/127 > > While if it would have been a /126 > 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126 > > Which matches much more the /30 stuff in v4: > 192.168.1.1/30 and 192.168.1.2/30 > > I can tell you many people were very confused about this little change > and as result many made mistakes configuring p2p's during the Interop > event Yes it looks confusing, but that is the case anyway and unfortunately the IETF didn't make things easier in this case :( We have rfc 4291stating that interface identifiers for all unicast addresses unless those starting with binary 000 must be 64 bits, that one is standards track. At the same time we have rfc 3627, informational, which states that /127 is considered harmful and finally rfc 6164 which is on standards track again contradicting that by describing the use of /127 for router point-to-point links. So far in the field it seems even more confusing, I've seen various lengths over the years. Mostly you see /126, /127 and also I come across /112 a lot and recently a /124 popped up on this list as well. I have a feeling we are heading for another disaster with this. No I'm not predicting the end of the world, the internet turns out to be resilient enough to survive these kind of things, but there is a serious risk of running into compatibility issues. Where do vendors stand on this ? I know some are really sticking to /64 pointing to rfc 3627. Now with rfc 6164 "overruling", you might be able to convince them to start supporting /127 as well. But what to do with those cases that require different length subnets. These all seem mostly arbitrary decisions made by somebody, which get copied by others based on the "let's not try invent the wheel ourselves". So it still seems reasonable to always assign the /64, no matter what you configure on the box. As anything else might come back and haunt you one day. And, putting on my co-chair hat, is there anything this WG might be able to do in providing some advice to the audience. Maybe issue a BCP on how to handle such cases ? Grtx, Marco Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From gvandeve at cisco.com Thu May 26 11:36:30 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Thu, 26 May 2011 11:36:30 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> Ok, I bite on this one... Jan Zorz and his team are doing a great job with the RIPE501Bis, particular to make it inline with existing recommendations out there. A vendor as Cisco is really happy with this as it unifies a global expectations pattern and will make the world the nice internet place it currently is because of aligned expectations and investments. Which means things will materialize quicker. Next to that, the recommendations now will be more tailored to a more distinct target audience, as not every little feature availability has meaning for every kind of user. (like a SOHO office has no need for ISIS or 50 msec fast convergence or so). So, I think the key is that 'wacking your vendor' randomly is not the right path... it may sound cool to do, but is not the most constructive idea, however asking the right expected IPv6 services is important and crucial for business continuity of the user/enterprise/customer. Responsibility for a good IPv6 infrastructure is the responsibility of Vendors, Service providers, content providers and enterprise organizations as a congruent mutual effort. G/ -----Original Message----- From: Jasper Jans [mailto:Jasper.Jans at espritxb.nl] Sent: 26 May 2011 11:23 To: Marco Hogewoning; Gunter Van de Velde (gvandeve) Cc: Pierre-Yves Maunier; ipv6-wg at ripe.net Subject: RE: [ipv6-wg] IPv6 on P2P links Marco, You have pretty much nailed it there. There is a million ways to do it - there is more (or less) reason and rhyme to pick your favorite flavour of the day. And yes we have the whole "let's do what they do" approach. It still leaves me facing several RFCs that says different things, vendors that might or might not support things and an all together bigger mess than I was hoping for. Anything that can be put forward as a clear cut proposal on how to handle these addressing cases would be appreciated from my point of view. It might even be something to whack your vendor over the head with - not much different from the IPv6 feature list that was put together that is now being used in tenders with regards to IPv6 feature parity. Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans at espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. -----Original Message----- From: Marco Hogewoning [mailto:marcoh at marcoh.net] Sent: Thursday, May 26, 2011 11:13 AM To: Gunter Van de Velde Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links > 2001:db8:C15c:0::/127 has as two addresses on the link: > 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) > and 2001:db8:C15c:0::1/127 > > While if it would have been a /126 > 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126 > > Which matches much more the /30 stuff in v4: > 192.168.1.1/30 and 192.168.1.2/30 > > I can tell you many people were very confused about this little change > and as result many made mistakes configuring p2p's during the Interop > event Yes it looks confusing, but that is the case anyway and unfortunately the IETF didn't make things easier in this case :( We have rfc 4291stating that interface identifiers for all unicast addresses unless those starting with binary 000 must be 64 bits, that one is standards track. At the same time we have rfc 3627, informational, which states that /127 is considered harmful and finally rfc 6164 which is on standards track again contradicting that by describing the use of /127 for router point-to-point links. So far in the field it seems even more confusing, I've seen various lengths over the years. Mostly you see /126, /127 and also I come across /112 a lot and recently a /124 popped up on this list as well. I have a feeling we are heading for another disaster with this. No I'm not predicting the end of the world, the internet turns out to be resilient enough to survive these kind of things, but there is a serious risk of running into compatibility issues. Where do vendors stand on this ? I know some are really sticking to /64 pointing to rfc 3627. Now with rfc 6164 "overruling", you might be able to convince them to start supporting /127 as well. But what to do with those cases that require different length subnets. These all seem mostly arbitrary decisions made by somebody, which get copied by others based on the "let's not try invent the wheel ourselves". So it still seems reasonable to always assign the /64, no matter what you configure on the box. As anything else might come back and haunt you one day. And, putting on my co-chair hat, is there anything this WG might be able to do in providing some advice to the audience. Maybe issue a BCP on how to handle such cases ? Grtx, Marco Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From Jasper.Jans at espritxb.nl Thu May 26 12:04:31 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 26 May 2011 12:04:31 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> Gunter, I agree with you that just putting something down on paper so that you have something to whack other parties with should not be the intention, apart from the fact that it's hardly constructive as you point out. The problem I see myself facing at the moment though is that as a result of several conflicting documents available and the community as a whole inventing their own wheels we might somewhere down the line run into trouble with compatibility. I personally would like to be able to point at a clear guideline for deployment that has been followed, ideally supported by several RFCs, when ultimately I will end up talking to a third party about the issue. (Third party can be vendor/customer/other sp/etc) Besides that it would ofcourse be even nice if we could all agree on a standard that has been tried and tested before we deploy and avoid issues all together - which as it currently stands is most likely not going to happen - but one can dream I guess. Jasper -----Original Message----- From: Gunter Van de Velde (gvandeve) [mailto:gvandeve at cisco.com] Sent: Thursday, May 26, 2011 11:36 AM To: Jasper Jans; Marco Hogewoning Cc: Pierre-Yves Maunier; ipv6-wg at ripe.net Subject: RE: [ipv6-wg] IPv6 on P2P links Ok, I bite on this one... Jan Zorz and his team are doing a great job with the RIPE501Bis, particular to make it inline with existing recommendations out there. A vendor as Cisco is really happy with this as it unifies a global expectations pattern and will make the world the nice internet place it currently is because of aligned expectations and investments. Which means things will materialize quicker. Next to that, the recommendations now will be more tailored to a more distinct target audience, as not every little feature availability has meaning for every kind of user. (like a SOHO office has no need for ISIS or 50 msec fast convergence or so). So, I think the key is that 'wacking your vendor' randomly is not the right path... it may sound cool to do, but is not the most constructive idea, however asking the right expected IPv6 services is important and crucial for business continuity of the user/enterprise/customer. Responsibility for a good IPv6 infrastructure is the responsibility of Vendors, Service providers, content providers and enterprise organizations as a congruent mutual effort. G/ Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From dez at otenet.gr Thu May 26 14:25:08 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Thu, 26 May 2011 15:25:08 +0300 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> Message-ID: <4DDE46A4.3000705@otenet.gr> so, other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links? From marcoh at marcoh.net Thu May 26 14:43:36 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 May 2011 14:43:36 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4DDE46A4.3000705@otenet.gr> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> <4DDE46A4.3000705@otenet.gr> Message-ID: <2983F071-E9A0-4D31-9CC7-168F7035B4C0@marcoh.net> On May 26, 2011, at 2:25 PM, Yannis Nikolopoulos wrote: > so, > > other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links? I wouldn't describe it as wastwful, every subnet is per standard /64 anyway. The primary reason are security concerns like the fact that you might be able to trick a machine into sending loads of ND messages (or responses), filling up the neighbor cache or CAM table. Marco From marcoh at marcoh.net Thu May 26 16:34:25 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 May 2011 16:34:25 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> Message-ID: <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> On May 26, 2011, at 11:36 AM, Gunter Van de Velde (gvandeve) wrote: > Ok, I bite on this one... > > Jan Zorz and his team are doing a great job with the RIPE501Bis, > particular to make it inline with existing > recommendations out there. A vendor as Cisco is really happy with this > as it unifies a global expectations > pattern and will make the world the nice internet place it currently is > because of aligned expectations and investments. Which means things will > materialize quicker. > Next to that, the recommendations now will be more tailored to a more > distinct target audience, as not every little feature availability has > meaning for every kind of user. (like a SOHO office has no need for ISIS > or 50 msec fast convergence or so). > > So, I think the key is that 'wacking your vendor' randomly is not the > right path... it may sound > cool to do, but is not the most constructive idea, however asking the > right expected IPv6 > services is important and crucial for business continuity of the > user/enterprise/customer. > Responsibility for a good IPv6 infrastructure is the responsibility of > Vendors, Service > providers, content providers and enterprise organizations as a congruent > mutual effort. Ok, so there is a document on the RIPE NCC website which describes how to build an addressing plan. It originated in Surfnet, the Dutch NREN, who agreed on having it translated and published by RIPE NCC. It can be found at http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf and on page 18 it addresses the problem: 4.10 Addressing Point-to-point Links If you use point-to-point links, using a /64 address may present problems in combination with certain router configurations. Unused addresses in the /64 system are bounced back by the routers on either side of the link. Data packages sent to this address will thus be sent back and forth between the routers like ping pong balls. This places an unwanted burden on the network. It might therefore, be practical in some cases to configure a /127 prefix instead of a /64 for these links. Please note: this configuration often works, but it is not in accordance with IPv6 standards. We therefore recommend reserving a /64 prefix for such links in the addressing plan, even if you use only a /127. As soon as the router configuration has been corrected by the supplier, you may proceed to configure a /64 prefix without having to modify the addressing plan. So the documentation exists, although not as a RIPE document. I'm a bit stuck here wether we should try and solve this and if so, in which way ? We could look into producing an informational RIPE document on this topic and issue it as BCP from this working group, hoping it provides some guidance and be picked up. On the other hand, the IETF did exactly that with RFC 6164 and even moved it beyond that point by putting it on standards track. So what would we gain by stating the same and putting a green RIPE logo on it ? Or as you mentioned ripe-501 should we include more than just the issue of point-to-point links and take on addressing habits in general ? In which case I have the feeling most of the work is already done by Surfnet in the quoted document and it might be easier to point there. Marco From gvandeve at cisco.com Thu May 26 16:59:58 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Thu, 26 May 2011 16:59:58 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> Some work a while ago was to deliver some considerations on address planning at IETF: http://tools.ietf.org/html/rfc5375 As you mention the /64 has for P2P a severe issue due to no ND process the Link resulting in ping-pong problem, and by doing that I have tested I can generate spikes of few Gig on a p2p with a single laptop connection, which is quite unfortunate. Imho this is the biggest driver for the /127 on a p2p connection from technological perspective. I would be willing to contribute together with Surfnet and other interested people to extend the RFC5375 and Surfnets paper to a more formal RIPE piece of work? One of the drivers of creating rfc5375 I had was that there is indeed inconsistency, and as result it should be fixed, but I am not sure RIPE can fix it. RIPE501Bis should imho be focused upon features for 'asking the right IPv6 support'... asking for /127 is silly I think... (btw Cisco IOS device's have no issue with it at all btw... so I am speaking here with my technology hat on). G/ -----Original Message----- From: Marco Hogewoning [mailto:marcoh at marcoh.net] Sent: 26 May 2011 16:34 To: Gunter Van de Velde (gvandeve) Cc: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links On May 26, 2011, at 11:36 AM, Gunter Van de Velde (gvandeve) wrote: > Ok, I bite on this one... > > Jan Zorz and his team are doing a great job with the RIPE501Bis, > particular to make it inline with existing > recommendations out there. A vendor as Cisco is really happy with this > as it unifies a global expectations > pattern and will make the world the nice internet place it currently is > because of aligned expectations and investments. Which means things will > materialize quicker. > Next to that, the recommendations now will be more tailored to a more > distinct target audience, as not every little feature availability has > meaning for every kind of user. (like a SOHO office has no need for ISIS > or 50 msec fast convergence or so). > > So, I think the key is that 'wacking your vendor' randomly is not the > right path... it may sound > cool to do, but is not the most constructive idea, however asking the > right expected IPv6 > services is important and crucial for business continuity of the > user/enterprise/customer. > Responsibility for a good IPv6 infrastructure is the responsibility of > Vendors, Service > providers, content providers and enterprise organizations as a congruent > mutual effort. Ok, so there is a document on the RIPE NCC website which describes how to build an addressing plan. It originated in Surfnet, the Dutch NREN, who agreed on having it translated and published by RIPE NCC. It can be found at http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf and on page 18 it addresses the problem: 4.10 Addressing Point-to-point Links If you use point-to-point links, using a /64 address may present problems in combination with certain router configurations. Unused addresses in the /64 system are bounced back by the routers on either side of the link. Data packages sent to this address will thus be sent back and forth between the routers like ping pong balls. This places an unwanted burden on the network. It might therefore, be practical in some cases to configure a /127 prefix instead of a /64 for these links. Please note: this configuration often works, but it is not in accordance with IPv6 standards. We therefore recommend reserving a /64 prefix for such links in the addressing plan, even if you use only a /127. As soon as the router configuration has been corrected by the supplier, you may proceed to configure a /64 prefix without having to modify the addressing plan. So the documentation exists, although not as a RIPE document. I'm a bit stuck here wether we should try and solve this and if so, in which way ? We could look into producing an informational RIPE document on this topic and issue it as BCP from this working group, hoping it provides some guidance and be picked up. On the other hand, the IETF did exactly that with RFC 6164 and even moved it beyond that point by putting it on standards track. So what would we gain by stating the same and putting a green RIPE logo on it ? Or as you mentioned ripe-501 should we include more than just the issue of point-to-point links and take on addressing habits in general ? In which case I have the feeling most of the work is already done by Surfnet in the quoted document and it might be easier to point there. Marco From millnert at gmail.com Thu May 26 17:37:34 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 26 May 2011 11:37:34 -0400 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <2983F071-E9A0-4D31-9CC7-168F7035B4C0@marcoh.net> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> <4DDE46A4.3000705@otenet.gr> <2983F071-E9A0-4D31-9CC7-168F7035B4C0@marcoh.net> Message-ID: Hi, On Thu, May 26, 2011 at 8:43 AM, Marco Hogewoning wrote: > On May 26, 2011, at 2:25 PM, Yannis Nikolopoulos wrote: > >> so, >> >> other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links? > > I wouldn't describe it as wastwful, every subnet is per standard /64 anyway. The primary reason are security concerns like the fact that you might be able to trick a machine into sending loads of ND messages (or responses), filling up the neighbor cache or CAM table. > Yes. I recommend http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for more details on this. It seems to be a pretty serious issue in most implementations. The author of the PDF recommends allocating /64 but using whatever fits your need. This way you'll stay ready for the future, should you have a reason to change, interoperability or other. Best regards, Martin From daniele at orlandi.com Thu May 26 18:33:42 2011 From: daniele at orlandi.com (Daniele Orlandi) Date: Thu, 26 May 2011 18:33:42 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> Message-ID: <201105261833.42713.daniele@orlandi.com> On Thursday 26 May 2011 10:07:39 Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P > links in their network? I've not yet been able to figure out another aspect of prefixes longer than /64. How are TCAMs in hardware routers and routing lookup code going to handle matches longer than 64 bits? Are ALL vendors putting all the 128 bits in the TCAMs or is there someone (or most?) with reduced match size that implies a second lookup? Or is the CPU-based algorithm going to be slower if the match is greater than the native CPU word size? That, alone would justify avoiding having prefixes longer than a /64 in the FIB since it would mean reduced PPS throughput for those destinations. Is anyone with an insight view of actual lookup method able to enlighten me a bit? Bye, -- Daniele "Vihai" Orlandi Bieco Illuminista #184213 From gvandeve at cisco.com Thu May 26 18:56:59 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Thu, 26 May 2011 18:56:59 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <201105261833.42713.daniele@orlandi.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <201105261833.42713.daniele@orlandi.com> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB7415@XMB-AMS-101.cisco.com> Inline: GV> -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Daniele Orlandi Sent: 26 May 2011 18:34 To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links On Thursday 26 May 2011 10:07:39 Jasper Jans wrote: > Can anyone give me some real world experience with IPv6 numbering on P2P > links in their network? I've not yet been able to figure out another aspect of prefixes longer than /64. How are TCAMs in hardware routers and routing lookup code going to handle matches longer than 64 bits? GV> it doesn't really matter as those are destinations that are normally not in the data-path, but just in the "testing path", so optimization doesn't really matter for these prefixes for the data-path services. Are ALL vendors putting all the 128 bits in the TCAMs or is there someone (or most?) with reduced match size that implies a second lookup? GV> oh.. I think there is more to it then just TCAM... what about route-convergence preferences etc... However in this case the TCAM is not a big practical issue I believe. Or is the CPU-based algorithm going to be slower if the match is greater than the native CPU word size? That, alone would justify avoiding having prefixes longer than a /64 in the FIB since it would mean reduced PPS throughput for those destinations. GV> important is that host/user stations are on /64 bit length prefixes, the point-2-point's don't really matter actually in that case as they are just transport path and not a routing destination. Is anyone with an insight view of actual lookup method able to enlighten me a bit? G/ From ip at ioshints.info Thu May 26 20:19:33 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 26 May 2011 20:19:33 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> Message-ID: <003d01cc1bd1$785a9960$690fcc20$@info> Nice to hear Cisco has no problems with /127 (now I don't have to test it and blog about it ;) As for RIPE501bis - I would add RFC 6164 to the list of "optional" RFCs in the "Router requirements" section. Makes sense? Ivan > RIPE501Bis should imho be focused upon features for 'asking the right > IPv6 support'... asking > for /127 is silly I think... (btw Cisco IOS device's have no issue with > it at all > btw... so I am speaking here with my technology hat on). > > G/ From jan at go6.si Thu May 26 22:40:45 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 26 May 2011 22:40:45 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <003d01cc1bd1$785a9960$690fcc20$@info> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> <003d01cc1bd1$785a9960$690fcc20$@info> Message-ID: <4DDEBACD.4040600@go6.si> On 5/26/11 8:19 PM, Ivan Pepelnjak wrote: > Nice to hear Cisco has no problems with /127 (now I don't have to test it and blog about it ;) > > As for RIPE501bis - I would add RFC 6164 to the list of "optional" RFCs in the "Router requirements" section. Makes sense? > > Ivan > >> RIPE501Bis should imho be focused upon features for 'asking the right >> IPv6 support'... asking >> for /127 is silly I think... (btw Cisco IOS device's have no issue with >> it at all >> btw... so I am speaking here with my technology hat on). >> >> G/ Hehe, I see you two guys will have a lot to talk about at dinner after v6 summit here in Ljubljana on Thursday :) ok, there is that draft document requested in RIPE-501, we need to change it to RFC6164 now, when it's published. Thnx for a note :) /jan From millnert at gmail.com Fri May 27 04:28:03 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 26 May 2011 22:28:03 -0400 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB7415@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <201105261833.42713.daniele@orlandi.com> <4269EA985EACD24987D82DAE2FEC62E503BB7415@XMB-AMS-101.cisco.com> Message-ID: Hi Gunter, On Thu, May 26, 2011 at 12:56 PM, Gunter Van de Velde (gvandeve) wrote: > GV> important is that host/user stations are on /64 bit length prefixes, > the point-2-point's > don't really matter actually in that case as they are just transport > path and not a routing destination. And there's no major technical reason I'm aware of why the NDP must be used on p2p links at all. A router in theory need only figure out what (p2p-) port to send a packet out on, and.. then do it. If there's only one receiver connected, it's going to get the bits. Not sure if vendors have NDP-less p2p-link features yet. Regards, Martin From achatz at forthnet.gr Fri May 27 10:36:40 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 27 May 2011 11:36:40 +0300 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> Message-ID: <4DDF6298.6010506@forthnet.gr> Gunter Van de Velde (gvandeve) wrote on 26/05/2011 17:59: > Some work a while ago was to deliver some considerations on address > planning at IETF: > http://tools.ietf.org/html/rfc5375 > > As you mention the /64 has for P2P a severe issue due to no ND process > the > Link resulting in ping-pong problem, and by doing that I have tested I > can > generate spikes of few Gig on a p2p with a single laptop connection, > which is > quite unfortunate. Imho this is the biggest driver for the /127 on a p2p > connection > from technological perspective. > > Shouldn't that (the ping-pong problem) be avoided by default, according to (standards track) RFC 4443? If the reason for the failure to deliver cannot be mapped to any of other codes, the Code field is set to 3. Example of such cases are an inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort. One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. -- Tassos From mir at ripe.net Fri May 27 10:54:55 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 27 May 2011 10:54:55 +0200 Subject: [ipv6-wg] Test your connectivity for World IPv6 Day Message-ID: <4DDF66DF.8030100@ripe.net> Dear colleagues, The RIPE NCC is preparing some measurements for World IPv6 Day. One of them is the IPv6 eye chart, a web page that allows you to test your connectivity to selected dual-stacked web sites and World IPv6 participants. The goal is to see if an end user has connectivity problems to dual-stacked websites. You can read more on RIPE Labs: http://labs.ripe.net/Members/emileaben/world-ipv6-day-ipv6-eye-chart The test can be found here: http://ipv6eyechart.ripe.net/ If you have any questions or want to be included in the test, please contact us at labs at ripe dot net. Kind Regards, Mirjam Kuehne RIPE NCC From gvandeve at cisco.com Fri May 27 11:08:03 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Fri, 27 May 2011 11:08:03 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <4DDF6298.6010506@forthnet.gr> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> <4DDF6298.6010506@forthnet.gr> Message-ID: <4269EA985EACD24987D82DAE2FEC62E503BB7541@XMB-AMS-101.cisco.com> It should :-) G/ -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr] Sent: 27 May 2011 10:37 To: ipv6-wg at ripe.net Cc: Gunter Van de Velde (gvandeve) Subject: Re: [ipv6-wg] IPv6 on P2P links Gunter Van de Velde (gvandeve) wrote on 26/05/2011 17:59: > Some work a while ago was to deliver some considerations on address > planning at IETF: > http://tools.ietf.org/html/rfc5375 > > As you mention the /64 has for P2P a severe issue due to no ND process > the > Link resulting in ping-pong problem, and by doing that I have tested I > can > generate spikes of few Gig on a p2p with a single laptop connection, > which is > quite unfortunate. Imho this is the biggest driver for the /127 on a p2p > connection > from technological perspective. > > Shouldn't that (the ping-pong problem) be avoided by default, according to (standards track) RFC 4443? If the reason for the failure to deliver cannot be mapped to any of other codes, the Code field is set to 3. Example of such cases are an inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort. One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. -- Tassos From jan at pragma.si Thu May 26 22:04:11 2011 From: jan at pragma.si (Jan Zorz) Date: Thu, 26 May 2011 22:04:11 +0200 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: <003d01cc1bd1$785a9960$690fcc20$@info> References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <298AF7CF-A3A1-4EDF-AD2F-6708A9C6CC68@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB736A@XMB-AMS-101.cisco.com> <003d01cc1bd1$785a9960$690fcc20$@info> Message-ID: <4DDEB23B.3000300@pragma.si> On 5/26/11 8:19 PM, Ivan Pepelnjak wrote: > Nice to hear Cisco has no problems with /127 (now I don't have to test it and blog about it ;) > > As for RIPE501bis - I would add RFC 6164 to the list of "optional" RFCs in the "Router requirements" section. Makes sense? > > Ivan > >> RIPE501Bis should imho be focused upon features for 'asking the right >> IPv6 support'... asking >> for /127 is silly I think... (btw Cisco IOS device's have no issue with >> it at all >> btw... so I am speaking here with my technology hat on). >> >> G/ Hehe, I see you two guys will have a lot to talk about at dinner after v6 summit here in Ljubljana on Thursday :) ok, there is that draft document requested in RIPE-501, we need to change it to RFC6164 now, when it's published. Thnx for a note :) /jan From dez at otenet.gr Mon May 30 10:00:04 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Mon, 30 May 2011 11:00:04 +0300 Subject: [ipv6-wg] IPv6 on P2P links In-Reply-To: References: <55557D0EBE9495428BFE94EF8BC5EBD201039B15CCED@EXCH01.campus.local> <20110526083118.GA3749@cilaos> <364A9938-A58D-4B84-9B45-F5B46DA393CB@marcoh.net> <4269EA985EACD24987D82DAE2FEC62E503BB717A@XMB-AMS-101.cisco.com> <8839776F-A5DA-485C-8E00-0C49AC690D68@marcoh.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CD80@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E503BB71C9@XMB-AMS-101.cisco.com> <55557D0EBE9495428BFE94EF8BC5EBD201039B15CDE6@EXCH01.campus.local> <4DDE46A4.3000705@otenet.gr> <2983F071-E9A0-4D31-9CC7-168F7035B4C0@marcoh.net> Message-ID: <4DE34E84.5030509@otenet.gr> On 05/26/2011 06:37 PM, Martin Millnert wrote: > Hi, > > On Thu, May 26, 2011 at 8:43 AM, Marco Hogewoning wrote: >> On May 26, 2011, at 2:25 PM, Yannis Nikolopoulos wrote: >> >>> so, >>> >>> other than the fact that it's wasteful, is there any other reason for not using /64 (that's what we're using) on p2p links? >> I wouldn't describe it as wastwful, every subnet is per standard /64 anyway. The primary reason are security concerns like the fact that you might be able to trick a machine into sending loads of ND messages (or responses), filling up the neighbor cache or CAM table. >> > Yes. I recommend http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf > for more details on this. It seems to be a pretty serious issue in > most implementations. The author of the PDF recommends allocating /64 > but using whatever fits your need. This way you'll stay ready for the > future, should you have a reason to change, interoperability or other. > > Best regards, > Martin > i should've been more elaborate in my original post. One one hand, allocating a /64 per p2p link *could* be considered wasteful and Cisco's "official" word was to use /64 on p2p links as all code is optimized for that boundary. On the other hand, there's the NDP cache exhaustion issue mentioned in rfc6164 (this issue can be minimized by a sane security policy btw) plus Gunter's (very informative) comments. Allocating and using /64 on p2p links sounds tidy. The "allocating" part, we'll stick with, the "using" part remains to be seen regards, Yannis From mir at ripe.net Tue May 31 15:10:13 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 31 May 2011 15:10:13 +0200 Subject: [ipv6-wg] How DNS caching affects the start of World IPv6 Day Message-ID: <4DE4E8B5.2050608@ripe.net> [apologies for duplicates] Dear colleagues, Please find a new article on RIPE Labs showing how DNS caching affects the start of World IPv6 Day and how World IPv6 Day participants can minimise these effects: http://labs.ripe.net/Members/emileaben/when-does-world-ipv6-day-start Kind regards, Mirjam Kuehne RIPE NCC