From wwaites at tardis.ed.ac.uk Mon Nov 3 19:37:10 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Mon, 03 Nov 2014 18:37:10 +0000 (GMT) Subject: [bcop] IPv6 deployment for small residential providers Message-ID: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> Just to follow up on the question I just asked following the BCOP draft on troubleshooting IPv6 for residential providers, should we write a companion document focused on small providers that explains how to deploy IPv6? I am happy to start writing, would anyone like to help? Cheers, -w From vicentinho at barretos.com.br Mon Nov 3 23:18:58 2014 From: vicentinho at barretos.com.br (Vicente De Luca) Date: Mon, 3 Nov 2014 22:18:58 +0000 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> Message-ID: Hi William, I have a good experience and background on this subject, since I had a regional ISP in Brazil for the last 17 years before selling the company (sept/2013) and coming to Europe (july/2014) to work for a SaaS provider. I'd be mostly happy to join you on this effort since I understand that this document can be really helpful for lots of small companies that are responsible for providing internet where big companies can't reach, and mostly aren't prepared for v6 yet. Cheers and keep in touch. see you tomorrow. vdeluca On Mon, Nov 3, 2014 at 6:37 PM, William Waites wrote: > Just to follow up on the question I just asked following the BCOP > draft on troubleshooting IPv6 for residential providers, should we > write a companion document focused on small providers that explains > how to deploy IPv6? > > I am happy to start writing, would anyone like to help? > > Cheers, > -w > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayan at bupt.edu.cn Tue Nov 4 18:37:26 2014 From: mayan at bupt.edu.cn (=?gbk?B?wu3Rzw==?=) Date: Tue, 04 Nov 2014 18:37:26 +0800(CST) Subject: [bcop] =?gbk?q?IPv6_deployment_for_small_residential_providers?= Message-ID: <20141104103726.11A0B19F360@mx3.bupt.edu.cn> An HTML attachment was scrubbed... URL: From wwaites at tardis.ed.ac.uk Sun Nov 9 12:47:03 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 09 Nov 2014 11:47:03 +0000 (GMT) Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> Message-ID: <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> I've started writing here: https://pad.okfn.org/p/bcop-small-ipv6 Today, a couple of paragraphs about the intended audience before getting into the meat of it. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rogerj at gmail.com Sun Nov 9 13:54:07 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sun, 9 Nov 2014 13:54:07 +0100 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> Message-ID: On Sun, Nov 9, 2014 at 12:47 PM, William Waites wrote: > I've started writing here: > > https://pad.okfn.org/p/bcop-small-ipv6 > > Today, a couple of paragraphs about the intended audience before > getting into the meat of it. It's a good start, but could you rewrite the part on "Address Allocation" ".... ipv6 not so different (only forget scarcity and use /64 by default and /56 or /48 if requested" I guess the allocation should be replaced with assignment toward end-users as a starter, then the next thing is the size you mention. Giving a /64 toward end-users will break many things, it will break homenet design (IETF homenet) and not to forget it's against the original intention when we relaxed the /48-for-everyone. Probably biggest clue for this is the HD-Ratio in http://www.ripe.net/ripe/docs/ripe-589 "In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56)." Replace it with something along this "by default give everyone a /56, on request a /48". It is really that simple. some background on the /56 size. Sometime before 2005 a discussion started if /48 for everyone was too strict, not so much about wasteful but more than anyone ever would need. After some back and forth RIPE changed it in 2005, the earliest document I found was 2005-08. I've tried to fill a /48 on just my own stuff in many ways but it's almost impossible, a /56 on the other hand is possible to fill but it's hard. I did tunnels between several machines I own/control, vpn so I could inside my own network, each service and LAN that got a /64 etc. It is documented quite a few more places than just in RIPE documents. The original intention was that we thought /56 was the right and recommended (lower cases) sizes for regular end-users. /48 was the right size for bigger end-users like enterprises. Over the years through rewrites it seems to have been relaxes so it's not that easy to see that it was ment as a recommanded (lower cases) on assigments sizes. I guess the reason for it being lower case is that none can dictate how an ISP/or anyone should do their assigment of the address space, only thing was to make an recommendation. Here is a few documents that mention the /56 http://www.ripe.net/ripe/policies/proposals/2005-08 http://datatracker.ietf.org/doc/draft-ietf-6man-why64/?include_text=1 http://www.ripe.net/ripe/policies/proposals/2005-08 http://www.ripe.net/ripe/policies/proposals/2006-02 http://www.ripe.net/ripe/docs/ripe-589 http://tools.ietf.org/html/draft-narten-iana-rir-ipv6-considerations-00 -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From wwaites at tardis.ed.ac.uk Sun Nov 9 14:11:32 2014 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 09 Nov 2014 13:11:32 +0000 (GMT) Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> Message-ID: <20141109.131132.1072912734750264449.wwaites@tardis.ed.ac.uk> On Sun, 9 Nov 2014 13:54:07 +0100, Roger J?rgensen said: > It's a good start, but could you rewrite the part on "Address > Allocation" Well, yes, that was just a placeholder sentence! But I've made the change as you asked. I'm not sure I agree though, and the reason is not to do with efficiency of address space use but operational ease of provisioning. Operationally, what does this mean? The most common case is going to be a single subnet, so how is the gateway going to know which one out of the /56 to use? Somebody has to pick a /64 to put on the inside ethernet interface. How is this done? No problem *assigning* a /56 but using it is another matter. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rogerj at gmail.com Sun Nov 9 14:46:20 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sun, 9 Nov 2014 14:46:20 +0100 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141109.131132.1072912734750264449.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> <20141109.131132.1072912734750264449.wwaites@tardis.ed.ac.uk> Message-ID: On Sun, Nov 9, 2014 at 2:11 PM, William Waites wrote: > On Sun, 9 Nov 2014 13:54:07 +0100, Roger J?rgensen said: > > > It's a good start, but could you rewrite the part on "Address > > Allocation" > > Well, yes, that was just a placeholder sentence! But I've made the > change as you asked. I'm not sure I agree though, and the reason is > not to do with efficiency of address space use but operational ease > of provisioning. > > Operationally, what does this mean? The most common case is going to > be a single subnet, so how is the gateway going to know which one out > of the /56 to use? Somebody has to pick a /64 to put on the inside > ethernet interface. How is this done? No problem *assigning* a /56 but > using it is another matter. ah I see, bad wording from my side. Any _end-user_ should get minimum a /56 for their use, an assignment. How they use that assignment are another technical matter - that's the operational side. On the actual use of IPv6 addresses I guess https://tools.ietf.org/html/draft-carpenter-6man-why64-01 is a better source for information. It mention cases where a /64 is the best choice, and where other sizes can, and can not be used. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From jan at go6.si Mon Nov 10 12:08:17 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 10 Nov 2014 11:08:17 +0000 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141109.131132.1072912734750264449.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> <20141109.131132.1072912734750264449.wwaites@tardis.ed.ac.uk> Message-ID: <54609CA1.5030304@go6.si> On 09/11/14 13:11, William Waites wrote: > Operationally, what does this mean? The most common case is going to > be a single subnet, so how is the gateway going to know which one out > of the /56 to use? Somebody has to pick a /64 to put on the inside > ethernet interface. How is this done? No problem *assigning* a /56 but > using it is another matter. Hi, I've seen all sorts of tricks being made on this topic... Some of them assign /56 to residential customer and: - use wan interfaces unnunmbered (just link-local addreses and installed route on BRAS towards wan ll interface) -or- - use the first /64 for ppp/wan link and the rest for LAN -or- - assign separate /64 for wan link and separate /56 for LAN side. /56 on the LAN side gets auto-configured as on well behaved CPEs there is a script for that. Usually, one address (from first /64) is assigned to local loopback and next /64 is put on first L3 port and next one on next L3 port and so on... you can of course change the ID of where the /64 assignments starts. http://wiki.openwrt.org/doc/uci/network6#downstream.configuration.for.lan-interfaces (an example). Cheers, Jan From nathalie at ripe.net Mon Nov 10 12:23:39 2014 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 10 Nov 2014 12:23:39 +0100 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> Message-ID: <4A8F2761-70B0-4CB5-B3DB-BF53E1F328A9@ripe.net> Hi William, On 09 Nov 2014, at 12:47, William Waites wrote: > I've started writing here: > > https://pad.okfn.org/p/bcop-small-ipv6 > > Today, a couple of paragraphs about the intended audience before > getting into the meat of it. > > -w > Thanks, a good start. Just one comment: "they also need ipv4 addresses to use as router-id (need not be global, but need to be unique).? is not true. It needs to be a 32-bit number, but it doesn?t have to be an IPv4 address. This should be made clear, as I notice in our training courses, a lot of engineers seem to think that the router ID MUST be an IPv4 address, while it normally is, it is not mandatory. 0.0.0.1 is a valid router-ID, I believe. In an IPv6-only network, for example, when you have no IPv4 addresses, you can just make something 32-bitty up and use that as the router ID. On the address assignment: What we see and hear in practice in our courses, is assign something on 4-bit boundary, big enough to cater for the next 10 years. So: a /64 only if you are absolutely sure that the customer will never come back for one more subnet (not likely). a /60 (if you are conservative) a /56 (most common for residential users) a /52 (we see this in some cases for both residential customers and business customers) a /48 (for business customers, or for residential customers if you are generous, and have a one-size-fits-all-approach) I hope this helps, Cheers, Nathalie From mayan at bupt.edu.cn Mon Nov 10 23:24:47 2014 From: mayan at bupt.edu.cn (=?gbk?B?wu3Rzw==?=) Date: Mon, 10 Nov 2014 23:24:47 +0800(CST) Subject: [bcop] =?gbk?q?IPv6_deployment_for_small_residential_providers?= Message-ID: <20141110152447.6447C19F3AE@mx3.bupt.edu.cn> An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Nov 10 19:19:01 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Nov 2014 19:19:01 +0100 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <4A8F2761-70B0-4CB5-B3DB-BF53E1F328A9@ripe.net> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> <4A8F2761-70B0-4CB5-B3DB-BF53E1F328A9@ripe.net> Message-ID: <22AA7805-C4D5-45FF-818B-86D30EA28613@steffann.nl> Hi Nathalie, > This should be made clear, as I notice in our training courses, a lot of engineers seem to think that the router ID MUST be an IPv4 address, while it normally is, it is not mandatory. 0.0.0.1 is a valid router-ID, I believe. In an IPv6-only network, for example, when you have no IPv4 addresses, you can just make something 32-bitty up and use that as the router ID. True, but it has to be unique a least between a router and all its neighbours. So if everybody on an internet exchange starts using 0.0.0.x then there will be trouble :) > On the address assignment: What we see and hear in practice in our courses, is assign something on 4-bit boundary, big enough to cater for the next 10 years. > So: a /64 only if you are absolutely sure that the customer will never come back for one more subnet (not likely). > a /60 (if you are conservative) Don't be :) > a /56 (most common for residential users) > a /52 (we see this in some cases for both residential customers and business customers) > a /48 (for business customers, or for residential customers if you are generous, and have a one-size-fits-all-approach) I would phrase this as "a /48 (for business customers, and for residential customers if you are not stingy, and/or have a one-size-fits-all-approach)" But those are minor details. The most common advice is - give a /48 or a /56 to residential customers - give a /48 to business customers - in case of doubt err in the direction of /48 There are not much advantages in giving other sizes to users. Cheers! Sander From jan at go6.si Mon Nov 10 19:33:02 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 10 Nov 2014 19:33:02 +0100 Subject: [bcop] IPv6 deployment for small residential providers In-Reply-To: <22AA7805-C4D5-45FF-818B-86D30EA28613@steffann.nl> References: <20141103.183710.1462835287798880571.wwaites@tardis.ed.ac.uk> <20141109.114703.998596283268939034.wwaites@tardis.ed.ac.uk> <4A8F2761-70B0-4CB5-B3DB-BF53E1F328A9@ripe.net> <22AA7805-C4D5-45FF-818B-86D30EA28613@steffann.nl> Message-ID: <546104DE.5040600@go6.si> On 10/11/14 19:19, Sander Steffann wrote: > - give a /48 or a /56 to residential customers > - give a /48 to business customers > - in case of doubt err in the direction of /48 Ditto... ;) Cheers, Jan From mayan at bupt.edu.cn Tue Nov 11 07:48:03 2014 From: mayan at bupt.edu.cn (=?gbk?B?wu3Rzw==?=) Date: Tue, 11 Nov 2014 07:48:03 +0800(CST) Subject: [bcop] =?gbk?q?IPv6_deployment_for_small_residential_providers?= Message-ID: <20141110234803.D98BD19F3AE@mx3.bupt.edu.cn> An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Tue Nov 11 21:05:33 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Nov 2014 21:05:33 +0100 (CET) Subject: [bcop] anti-spoofing document Message-ID: Hi, I keep running into people who have never heard of the excellent document that Torbj?rn Ekl?v has created over time. It came out of work to create requirements and certification for access networks, one large reason was to assure a secure end user connection that didn't have MITM and spoofing problems. The main site is here: http://secureenduserconnection.se/ Direct link to the current version of the document: http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC-Secure-End-user-Connection-2014-05-30.pdf I recommend everybody looking for information and requirements on how to create a secure network to read this document. It's very comprehensive. -- Mikael Abrahamsson email: swmike at swm.pp.se From benno at NLnetLabs.nl Tue Nov 11 22:40:12 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 11 Nov 2014 22:40:12 +0100 Subject: [bcop] anti-spoofing document In-Reply-To: References: Message-ID: <5462823C.5090408@NLnetLabs.nl> Hi Mikael, On 11/11/14 21:05, Mikael Abrahamsson wrote: > I keep running into people who have never heard of the excellent > document that Torbj?rn Ekl?v has created over time. It came out of work > to create requirements and certification for access networks, one large > reason was to assure a secure end user connection that didn't have MITM > and spoofing problems. > > The main site is here: > > http://secureenduserconnection.se/ > > Direct link to the current version of the document: > > http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC-Secure-End-user-Connection-2014-05-30.pdf > > > I recommend everybody looking for information and requirements on how to > create a secure network to read this document. It's very comprehensive. Thank you for this reference to this comprehensive work. By its completeness, the document could be a basis for a number of BCOPs. For the IPv4 and IPv6 address spoofing, the documents suggests using a access filtering based on IPv4/6 address whitelist table on customer ports. For IPv6 it gives examples to build such a whitelist table, but I see in the edit history, they removed such examples for IPv4. I will check if the examples are still in previous versions of the document. Good topic for ongoing discussions now we start thinking of TCP FastOpen (https://tools.ietf.org/html/draft-ietf-tcpm-fastopen) and UDP gained new interest as an alternative to surf the web (https://ripe69.ripe.net/wp-content/uploads/presentations/166-quic.v0.1.pdf). Cheers, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From jan at go6.si Wed Nov 12 19:41:25 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 12 Nov 2014 19:41:25 +0100 Subject: [bcop] IPv6 troubleshooting for helpdesk document - feedback from RIPE IPv6 WG Message-ID: <5463A9D5.3000600@go6.si> Dear BCOP community, Just a heads-up - we presented this document at RIPE IPv6 WG, asking for technical feedback and after some discussion the co-chairs decided to open a 2 weeks window for the community to come back with any possible comments and then issue a last call. I think we should do the same here. I know there were no objections and good sense of support and consensus in the room, but if we are doing it in cooperation with other WGs, then we need to adapt with the timings. So, still time for last comments or feedback. https://www.ripe.net/ripe/groups/tf/bcop/ipv6-troubleshooting-for-residential-isp-helpdesks Cheers and thnx, Jan Zorz From cristian.sirbu at gmail.com Wed Nov 12 20:20:22 2014 From: cristian.sirbu at gmail.com (Cristian Sirbu) Date: Wed, 12 Nov 2014 19:20:22 +0000 Subject: [bcop] anti-spoofing document In-Reply-To: References: Message-ID: Hi Mikael, This document is fantastic (more so that it has been built in English!), thanks for pointing it out! There is a lot of information out there nowadays, some of it good, some of it bad - but it's not easy to find such hidden gems. With the risk of sounding ungrateful and pedantic, I have one small issue with the website it's hosted on though, considering we're on the topic of security, MITM and best practices: the website is only available via HTTP and it's running an older version of Wordpress. Upon trying to access it via HTTPS, the certificate offered is for interlan.se and the page is some admin login for Halon SP (whatever that is). Cheers, Cristian On Tue, Nov 11, 2014 at 8:05 PM, Mikael Abrahamsson wrote: > > Hi, > > I keep running into people who have never heard of the excellent document > that Torbj?rn Ekl?v has created over time. It came out of work to create > requirements and certification for access networks, one large reason was to > assure a secure end user connection that didn't have MITM and spoofing > problems. > > The main site is here: > > http://secureenduserconnection.se/ > > Direct link to the current version of the document: > > http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC- > Secure-End-user-Connection-2014-05-30.pdf > > I recommend everybody looking for information and requirements on how to > create a secure network to read this document. It's very comprehensive. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: