Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On Sat, 12 Dec 2009, Alexandru Petrescu wrote: Frank Bulk a écrit : I think they're (all) listed here: http://www.getipv6.info/index.php/Broadband_CPE And from an operators perspective (not manufacturer): Free ISP ADSL (and fiber) operator in France does IPv6 natively to the end user with Router Advertisement since 2 years now. I think these CPE (Customer Premises Equipment) are called simply box in France (freebox, livebox, dartybox, and more). Between the Free box and the core network there is proprietary IPv6-in-IPv4 encapsualtion, not 6to4. No DHCPv6-PD, which I feel as a big restriction. implementing 6rd (which is used by Free) also a big restriction. Plans for livebox and 9box IPv6 do exist if not already deployed. Spanish FON Fonera based on openwrt, when I checked 2008, did IPv6 somehow, not sure whether natively. http://boards.fon.com/viewtopic.php?f=1t=4532view=previous From memory, at least one Japanese residential operator did IPv6 to the home several years ago, with explicit IPv6 advertisement on TV during prime time. Alex Frank -Original Message- From: Wade Peacock [mailto:wade.peac...@sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog@nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts?
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On 13/12/2009, at 10:10 AM, Frank Bulk wrote: While the support burden will be raised, I think the network needs to be dual-stack from end-to-end if SPs want to keep middle-boxes out. But for those who really do run out of IPv4 addresses, I'm not sure how middle-boxes can be avoided. Kind of hard to tell customer n+1 that they can only visit the IPv6 part of the web. Perhaps new customers will have to use a service provider's CGN and share IPv4 addresses until enough of the internet is dual-stack. The most likely outcome I can see is that customers on services which feature dynamic IPv4 addresses (mostly residential) will end up behind a CGN on a dual stack service. I fully expect the CGN to suck mightily, mitigated somewhat by the fact that the customer would also happen to have a non-NATted IPv6 address if they upgrade their CPE to take advantage of it. Despite the suckage, as long as email, web and VoIP keeps working I think most residential customers wouldn't notice the CGN imposition at all. The act of putting those customers behind a CGN would immediately free up enough IPv4 addresses that the ISP concerned would have a virtually limitless supply for fixed-IP business-grade services -- virtually limitless in the sense that there'd be enough to feed those services with new addresses for however much time it takes to complete an IPv6 transition. How long will that take? I don't think it'll be anywhere near as long as most people appear to be expecting. Sure, there'll be a large installed base of printers and home entertainment devices running legacy IPv4-only software, but by and large they either don't need Internet access at all or are quite happy talking to the world through NAT, and can be mostly ignored for the purpose of a discussion about transition durations (in the same way that we ignored all the HP JetDirect cards when we talked about how long it took to turn the Internet classless). I reckon CGNs will be so bad, with so many bugs and so much support overhead that service providers and customers alike will want to move past them as quickly as humanly possible, and the whole transition will be all done and dusted in a few years from their implementation. It's going to be a total and absolute disaster, and the only way out of it will be to move forward. Of course, all of this is predicated on the notion that CGNs will actually exist. As far as I can tell they're all vapourware at the moment. If there's one thing I've learned from all of this it's that roadmap announcements aren't worth anything, and that if the vendors ever do actually manage to get around to shipping something it'll be so poorly thought out that it's impractical to use in a service provider environment until version 2 -- which, in the case of CGN, will be too late. - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
--On Sunday, December 13, 2009 9:17 AM -0800 Joel Jaeggli joe...@bogus.com wrote: UPnP is a bad idea that (fortunately) doesn't apply to IPv6 anyway. You don't need UPnP if you'r not doing NAT. wishful thinking. you're likely to still have a staeful firewall and in the consumer space someone is likely to want to punch holes in it. Amen indeed. Consumers do not care if its a good idea or not. And honestly in a home network, well, its not as frightening. In a business of any kind (including home based) it is bad. You should have a DMZ with carefully controlled open ports lists. But that's preaching to the choir here. IPv6 doesn't magically negate the need for UPnP, UPnP is not tied to NAT. It's a way for applications to ask the firewall to selectively open ports up to them. Intelligent stateful firewalls can do that for limited applications, perhaps with some sort of policy control even. Though Joe/Jill Gamer (which is what UPnP is for) won't know anything about any of that. They define a gateway as functioning or not. I really am honestly sick of people thinking IPv6 is a panacea. It isn't. UPnP is rather a bit of a hack for sure, protocols should be better designed, but in this modern age of Peer To Peer you need a way for applications to ask the firewall to selectively open incoming ports.
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
In message d73fdb46-bf23-4825-89c6-51601d622...@internode.com.au, Mark Newton writes: Of course, all of this is predicated on the notion that CGNs will actually exist. As far as I can tell they're all vapourware at the moment. Comcast commissioned ISC to develop a working CGN. We are in the final release stages of our CGN product, AFTR. https://www.isc.org/software/aftr You can go and download it now it you want. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: Consumer Grade - IPV6 Enabled Router Firewalls.
Thanks for the link. The most obvious question to me is scalability. What box is going to be running AFTR to do all this translation? It looks like the B4 part is running on the customer's CPE, but if we need to move hundreds of Mbps, if not Gbps, wouldn't that require some C/J/F class type of box? Frank -Original Message- From: ma...@isc.org [mailto:ma...@isc.org] Sent: Sunday, December 13, 2009 4:14 PM To: Mark Newton Cc: frnk...@iname.com; nanog@nanog.org Subject: Re: Consumer Grade - IPV6 Enabled Router Firewalls. In message d73fdb46-bf23-4825-89c6-51601d622...@internode.com.au, Mark Newton writes: Of course, all of this is predicated on the notion that CGNs will actually exist. As far as I can tell they're all vapourware at the moment. Comcast commissioned ISC to develop a working CGN. We are in the final release stages of our CGN product, AFTR. https://www.isc.org/software/aftr You can go and download it now it you want. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
On 14/12/2009, at 9:38 AM, Frank Bulk wrote: I hope you're right. I really hope that there's this phenomenal transition in 2011 of content from 0.1% IPv6-accessible to 99% IPv6-accessible. Forget content, they're just along for the ride. When most service providers have eye-wateringly shite CGNs acting as intermediaries between eyeballs and content, the content providers will be motivated to move to v6 even if only as a means of damage control. And not even by node count, but by percentage of traffic. And pain is one way to get there. Every few months I think of the number of truck rolls we'll need to do to swap out DSL modems and SOHO routers with their IPv6 equivalents. Ah, that's something we don't have. Our customers own their own (which has its own slew of problems: I can't make them upgrade, and if I tell them they'll have to spend a hundred bucks to restore the functionality I broke for them last week I'll have a revolt on my hands...) - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: More ASN collissions
Florian Weimer wrote: * Rene Wilhelm: AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at whois.ripe.net is a user created object in the RIPE routing registry, not an assignment by RIPE NCC. How can you tell one from the other? Is the lack of an org: attribute reliable? The info is in the as-block object which whois.ripe.net returns in addition to the aut-num object when you do a default query for an AS number. For example for as43210 you get this: as-block: AS43008 - AS44031 descr: RIPE NCC ASN block remarks:These AS Numbers are further assigned to network remarks:operators in the RIPE NCC service region. AS remarks:assignment policy is documented in: remarks:http://www.ripe.net/ripe/docs/asn-assignment.html remarks:RIPE NCC members can request AS Numbers using the remarks:form available in the LIR Portal or at: remarks:http://www.ripe.net/ripe/docs/asnrequestform.html org:ORG-NCC1-RIPE admin-c:CREW-RIPE tech-c: RD132-RIPE mnt-by: RIPE-DBM-MNT mnt-lower: RIPE-NCC-HM-MNT source: RIPE # Filtered [...] Only AS numbers which are covered by RIPE NCC ASN blocks have been assigned by RIPE NCC or transferred to RIPE NCC (like AS1707). -- Rene
