Re: IPv6 delivery model to end customers
On 7/02/2009, at 8:45 PM, Mikael Abrahamsson wrote: So, what is the security problem with IPv6 in an IPv4 network? Well, imagine an IPv4 network where security is done via ARP inspection, DHCP snooping and L3 ACLs. Now, insert rogue customer who announces itself via RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can do some NAT-PT like functionality, they are now man in the middle for all the IPv4 traffic (because between the customers it's IPv6 and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. It is worth noting that this problem does not require you to start sending RA messages - this is a problem as soon as one customer is listening to RA messages. The problem may very well exist right now. -- Nathan Ward
Re: One /22 Two ISP no BGP
Re Charles, this is all about control, so you don't lose connectivity in case something outside your control fails. The best idea so far is the ebgp-multihop idea with your ISP's transit provider. This means speaking BGP to them yourself and taking care that the traffic takes the intended path, too (will usually work). If you can spare the money, I'd set up my own hubs on the mainland, tunnel to them through each of my ISPs and use that hub for the routing of all incoming traffic. This does of course mean additional hardware, housing, local loops and probably additional transit providers. It would nonetheless give you full control. The second best idea so far is that the NANOG people could talk to your ISP(s)...this has worked in more than one case. So - where is your island, how's the weather, and are you hiring? ;-) Yours, Elmar.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Feb 7, 2009, at 2:09 AM, Nathan Ward wrote: On 6/02/2009, at 12:00 PM, Joe Maimon wrote: This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting. There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on. If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre. My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food. This has nothing to do with the number of blocks per area. Nice marketing, not useful for reality. How many IP-connected devices do you have on your person right now? How many non-IP-connected devices (e.g. bluetooth) that may someday be IP-connected? And how many more will we have? If you think you can answer the last one, you are lying to yourself. We will find a way to waste fritter away thing. We always have, we always will. In the mean time, we'll do the best with what we have. -- TTFN, patrick
Re: v6 DSL / Cable modems
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. Both of these choices seem perfectly reasonable to me. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: One /22 Two ISP no BGP
For the folks asking what island. http://en.wikipedia.org/wiki/Magdalen_Islands http://www.panoramio.com/user/45210 We are hiring if someone is interested :) It's not like the Bahamas. I wish it was. It's alot colder here. I've talked to ISP1 yesterday and they will let me know what they can do. There's a chance... I will also have to scale up. I don't think my Soekris with OpenBSD can handle two full route of the Internet. Any suggestions ? Charles On Sat, Feb 7, 2009 at 7:16 AM, Elmar K. Bins e...@4ever.de wrote: Re Charles, this is all about control, so you don't lose connectivity in case something outside your control fails. The best idea so far is the ebgp-multihop idea with your ISP's transit provider. This means speaking BGP to them yourself and taking care that the traffic takes the intended path, too (will usually work). If you can spare the money, I'd set up my own hubs on the mainland, tunnel to them through each of my ISPs and use that hub for the routing of all incoming traffic. This does of course mean additional hardware, housing, local loops and probably additional transit providers. It would nonetheless give you full control. The second best idea so far is that the NANOG people could talk to your ISP(s)...this has worked in more than one case. So - where is your island, how's the weather, and are you hiring? ;-) Yours, Elmar.
RE: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
as I've said a few times now, reason #775 that autoconf is a broken and non- useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6. This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise? There IS a similarly featured system. Why is it so hard to accept that in MANY cases SLAAC is enough (especially when RFC5006 is more widely supported, or while IPv4 is still around to cheat off of (glaring at WinXP)) ... and when it isn't enough, or when you feel like doing more DHCPv6 is there waiting for you? Almost no one is arguing that DHCPv6 can't exist, shouldn't exist, etc. Perhaps with the exception of Apple, that is - and that is still OK! I certainly see value in DHCPv6, but I see value in SLAAC as well. I don't want to force anyone to not do DHCPv6, why do others want to force me to do DHCPv6? Can't we all just get along?
RE: v6 DSL / Cable modems
What most people do of course is VRRP. Sure, or HSRP or GLBP ... all still doable. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. Indeed, not universal and in fact default behaviors vary wildly. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). Which I think is pretty slick. OOC - between the router fails and I renew/rebind my address, is the host down and out? So you are accepting either a noticeable outage or tweaking your lease times, yes?
Re: IPv6 delivery model to end customers
If you didn't see it in last thread, http://geekmerc.livejournal.com/699.html may provide some information for you, but I can tell from your concerns that your current choice of edge layouts is different than mine. As such, more below. Mikael Abrahamsson wrote: Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and man in the middle-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like ARP inspection, rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of magic. All of these mechanisms were developed in the first half of the last decade. Unnumbered vlans and RBE support on cisco, I guess could be considered forced forwarding in layer 2. It definitely makes for beautifully long configurations and severely limits dslams to support enough vlans for 1 vlan per port, preferably with q-in-q. It also had the benefit of separation of responsibility, as telco could play with dslams (atm or vlans) and networking played with routers where tracking/policing was implemented. Of course, moving away from ATM terminated systems seems to be the big deal, and not all systems support massive vlan terminations. I believe the vendors said, Why on earth would you want to do that! It's like replicating pvc's! Those vendors do cute things in their dslams such as dhcp snooping and limiting broadcast domains. IPv6 changes this from broadcast domains to multicast. Luckily, thanks to triple play, most of these same dslams also understand multicast and do igmp snooping. Adding support for multicast RA snooping is considered trivial by most, which is why they haven't bothered with it yet. Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't sniff it and enforce security measures mentioned above. Why not? They sniff igmp. What's the difference? Multicast is already commonly supported by most dslam manufacturers using flat topology. My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. I suggest heavy testing of this. I'm not sure that CPE's will be happy about doing PD requests without having received a prefix/IP for the interface. It'll also create create problems for traceroutes. ;) The other option that is extremely simple is statically assign /64 to each port and then if they do PD, insert the route and do anti-spoofing. This is, btw, what RBE sorta does with IPv6 in atm world. So, how can we fit current IPv6 into the IPv4 security model? We can't. Current L2 devices won't do any of the IPv6 security stuff needed, and just turning on RA/DHCPv6 would make it work from a let's move packets-aspect, but it wouldn't be secure (perhaps in some forced-forwarding cases there might be a possibility of doing it securely, but what devices will log what customer had what IP at what time when it's done via RA?). I'll agree that I haven't seen the necessary support by vendors for what should be trivial to change as mentioned above. One reason I took the headache of treating vlans like pvcs is lack of uniform support at layer 2 for security policies. Vlans, though. Simple. They either support the required number, or they don't. and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. Depends on the L2 device and how it's configured to deal with multicast. If you didn't think about multicast when deploying, then IPv6 is doing a service by reminding people that it exists. ;) So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now
RE: IPv6 delivery model to end customers
Michael, From my work in access networks they are: IPv6 native support for: Routed Access - Ethernet or Wireless, global prefix under the main or dot1Q isl encapsulated sub-interfaces. For DSL and ATM PVCs routed RFC 2684 encapsulation with a different IPv6 prefix for each one of the PVCs. Bridged Access - RFC 2684 where the user traffic reaches the access router over a bridged PVC. PPP-Encapsulated IPv6 - PPPoA/IPv4 access was my favorite in the early days and finally moving in about 2004 or so to PPPoE (RFC 2516). Most DSL and Layer 2 providers that I used had PPPoA in their access network and then handed off to me as an ATM PVC with L2TP encapsulated user streams. PPPoE/PPPoA support both IPv4 and IPv6 packets natively. SP can leverage their existing IPv4 access infrastructure by utilizing IPv6 over L2TPv2 or in deploying IPv6 natively to the CPE by utilizing L2TPv3. My IPv4 only deployment in 2001 used DSLAMs that had limited number of active CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM switches in front of Redback aggregation switches connecting to Cisco 6509s and then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS servers using CHAP. The DSLAMs were upgrade over the next two to three years for larger number of CPE tributaries and optical (OC-3c and OC-12c) network uplinks. In my advancing years if memory serves in 2005/2006 timeframe (in the US) the CPE, DSLAMS, aggregation and other switches and routers supported IPv6. Now you have both second and third generation support for IPv6 in these devices (Cisco, Juniper, et al) and rumor has it that Linksys and Netgear have IPv6 plans in their roadmaps or devices in their labs. For PD and DHCPv6 there are other tools that allow much more control over IP address assignment and lifecycle control that I will not discuss here. I am not slighting Cable here, I do not have the first hand experience with cable supporting IPv6. IMHO rolling out IPv6 to the customer is a business decision now not a technical one. John (ISDN) Lee From: Mikael Abrahamsson [swm...@swm.pp.se] Sent: Saturday, February 07, 2009 2:45 AM To: nanog@nanog.org Subject: IPv6 delivery model to end customers I didn't know where to jump in in the current discussion and what I wanted to discuss was quite general, so I thought I'd create a new thread instead. So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a very simplified view of the world. Yes, IPv6 works in the classic routed network model where everything is statically set up (often manually), for example with an ISP run CPE and static/dynamic routing and a fixed /48 issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS etc to the customer DNS. Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and man in the middle-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like ARP inspection, rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of magic. All of these mechanisms were developed in the first half of the last decade. Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't sniff it and enforce security measures mentioned above. My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. (Rationale for link-local only is to have only customer devices in Customer IP space and only ISP infrastructure in that IP-space. This is equivalent to ip unnumbered in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and it's now included in a draft that lists different models of IPv6 delivery. As far as I know, this IPv6 L3 device doesn't exist (in the pricerange needed for massive residential roll-out anyhow).
RE: IPv6 delivery model to end customers
On Sat, 7 Feb 2009, John Lee wrote: My IPv4 only deployment in 2001 used DSLAMs that had limited number of active CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM switches in front of Redback aggregation switches connecting to Cisco 6509s and then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS servers using CHAP. My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC-VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model. IMHO rolling out IPv6 to the customer is a business decision now not a technical one. Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 DSL / Cable modems
On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote: I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. Close, but it is worth clearing up. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. Most clients default out of the box to accept RA, getting a single address within each prefix indicating automatic address assignment. The ones that do support DHCPv6 will also initiate DHCPv6 services based on RA M and O flags. There are some bugs here and there, but it mostly works. This is all well and good, you are right on these points. However, Jack was referring to a practice of temporary address assignments. In this configuration, a client has one permanent (for as long as they are on that wire) address they use (per prefix, because that is how IPv6 multihomes, so they say) for general purpose and reachability from the outside world (dial in). They also have a range of temporary addresses which are in a state of preferred use, unpreferred use, or validity-timer expiration (again, per prefix, for multi-homing). Each temporary address is allocated based on a re-hash of a previously used seed, and half of the seed bits are not used in the public address (so outsiders can not easily predict what the client's next address will be). The theory is that these temporary addresses enhance privacy, as the client seems to hop from address to address. This seems to ignore application context hints such as cookies and keys embedded in URL's, so to my thinking the point of this is to enhance privacy for spammers or illegal file sharers. Anyway. So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. Conversely, with DHCPv6, clients that support normal and temporary addresses simply always ask for them; this indicates they possess support. The service determines which type of address to actually provide (one, the other, both, with multiple bindings in either). In this way, all is automated from a central point. The philosophies of design of these two systems are entirely at odds. In RA the client determines what configuration it seeks, placing its own arbitrary demands upon the network, but still heeds some of its vague handwaving. In DHCPv6, the client submits to the network's will, but still has some of its own vague handwaving choices. It is Marxism (turned Socialism) vs Fascism at its root. I hope I have not spent my year's worth of NANOG tolerance for DHCP related discussions with the above. :) -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgp1JN3RhM7ce.pgp Description: PGP signature
RE: IPv6 delivery model to end customers
Yes it was definitely last century. With your 30 USD per port and no tunnels poses some interesting challenges. Customer CPE tunnel access was the main method discussed in the different v6 meetings I attended. I appreciate you bringing up this set of requirements since it needs to be addressed for fuller deployment of IPv6 to residential customers. John From: Mikael Abrahamsson [swm...@swm.pp.se] Sent: Saturday, February 07, 2009 1:12 PM To: John Lee Cc: nanog@nanog.org Subject: RE: IPv6 delivery model to end customers On Sat, 7 Feb 2009, John Lee wrote: My IPv4 only deployment in 2001 used DSLAMs that had limited number of active CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM switches in front of Redback aggregation switches connecting to Cisco 6509s and then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS servers using CHAP. My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC-VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model. IMHO rolling out IPv6 to the customer is a business decision now not a technical one. Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
Matthew Moyle-Croft wrote: Stephen Sprunk wrote: You must be very sheltered. Most end users, even security folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on security through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. I assume you're referring to ALG code? Indeed, I've found that turning off ALGs in NAT/FW boxes fixes a lot of problems, because every vendor's seem to be broken in a different way. I deal mainly with SIP these days, and the first step in any sort of firewall-related troubleshooting is to turn _off_ any SIP ALG functionality in the CPE because 90% of the time, that's whats breaking things; the end devices can deal with NAT as long as there's nobody in the middle mangling their packets. Ideally, ALGs would fix up the packets such that the endpoints didn't need to be NAT-aware, but they're all (and I mean all, not most) so hideously broken that they make things worse, not better. They can't get even simple, fossilized protocols like active FTP working most of the time; there's no way they'll do better with newer, more complicated ones like SIP or the dizzying array of P2P and IM protocols. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. However, to be safe the endpoints cannot assume any firewalls in the path are going to work properly, and the absence of NAT makes it tougher for endpoints to detect firewalls' presence and react as needed... (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/insert favourite fw is for enterprise). I've found the enterprise NAT/FW gear to be worse: they attempt to implement more ALGs, but they do no better a job at implementing them than the less-ambitious consumer vendors, so more things break. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
RE: v6 DSL / Cable modems
But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. As currently spec'ed, you [would|should|could] allow /48s from the specific PI ranges (1/RIR?) - not just auto-accept all /48s. /TJ
RE: v6 DSL / Cable modems
It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. In theory, RAs can - more specific routes, although I don't believe any vendor (router or client side) supports these as of yet ... (Default Router Preference more widely supported, but less granular) Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? RFC3484 being revisited as we speak, feel free to help :) ... may include things like policy table updates to clients ... Note - no great/clean answer yet to the multi-homed to disparate networks scenario. (It's a hard problem to automagically solve for all cases) /TJ
Re: One /22 Two ISP no BGP
On Fri, 6 Feb 2009, Jason Biel wrote: As I mentioned earlier, you'll want to have one provider announce the /22 unweighted and the other announce it weighted. Just pick the better of the two providers as the primary. Don't base it soley off bandwidth, but check your SLA and any recent outage occurances. Traffic will flow in via the primary until that link to you drops, the provider will remove the route, and traffic will come in the back up route. This is unlikely to work, on a couple of levels. Given the same prefix-length on both announcements, you're unlikely to have much luck keeping traffic off your back-up path as Jason suggests. This means you'll need to have ways to withdraw the routes through both providers if their respective links fail, rather than just being able to withdraw the routes from one. I'm not sure what he means by doing a weighted announcement. If he means using the Cisco weight attribute, it's local to the router where it's set and won't propagate upstream. Your upstream providers could use that to control how traffic exits their networks, but not how traffic gets to them. Indeed, given two routing announcements of the same route to two different upstream providers who connect to the rest of the Internet in different ways, the announcing network has very little control over which route will be followed. Once an announcement is out there, routing decisions get made according to the policies of the networks sending traffic in the announcing network's direction, which are generally based more on customer relationships than on topological distance or anything that can be set on the announcing end. The usual way to attempt to influence inbound traffic flow is with AS path prepending -- making one path into a network look artifically long so that the other will look comparitively short. This partly works. Those who don't have any other reason to prefer one path over the other will prefer the shortest one. But it's not going to shift 100 percent of inbound traffic. The upstream provider, and their upstream providers, and anybody upstream from them, will probably all be using the BGP local-preference attribute to prefer paths they get paid for over paths they don't, and local-preference trumps AS path length no matter how many prepends are put into a path. As others here have suggested, you could have the provider that won't do BGP with you tie their own BGP announcement to your interface, such that if the interface facing you goes down the route will go away. Or you could have them use Cisco's conditional routing feature to only announce your route if they stop seeing your route being announced through your other provider. The problem with both of these approaches is that they depend on some BGP routing flexibility on the part of your upstream provider, and if your upstream provider were flexible in terms of how they handle BGP for customers we wouldn't be having this discussion. If you did want to follow Jason's suggestion of having primary/backup providers, such that inbound routing decisions are made based on whether the primary one is up, the tool you've probably got available is to announce more and less specific routes. Barring filters in your upstream providers' networks, a more specific route will always be chosen over a less specific one. So, if you've got a /22, you could have your non-BGP-speaking provider announce it as a /22 on your backup link, and announce it yourself as two /23s on your BGP-aware primary link. That should more or less work, at the cost of having two more routes in the global routing table and getting you some dirty looks from peers who will consider it irresponsible. That said, if you've got the resources, I think tunneling over the uncooperative provider to somebody who will do BGP with you on the mainland is probably a better answer. -Steve
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Bill Stewart wrote: That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. Customers can land on one of a fleet of large BRAS across multiple POPs in a geographic region so that a failure of one piece of equipment or POP doesn't cause an outage. If I want to run a hint of redundancy then I need to propogate statics out of the POP itself. There are corners that can be cut but none seem to fit into the kind of redundancy we like. Unlike a most BGP routes DSL circuits tend to go up and down a lot, this adds to convergence time and CPU load on the router. My issue is not basic network design skills. My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into iBGP rather than an IGP I feel would add considerably to the load routers face and give a big hit in the event of failure. (We already have a class of customer with statically assigned addresses or ranges). The indication so far seems to be that on this list at least people don't see IPv6 statics for all as the general option. This gives me a bit more hope. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
97.128.0.0/9 allocation to verizon wireless
Dear list, Since IPv4 exhaustion is an increasingly serious and timely topic lately, I would like to point out something that interests me, and maybe everyone else who will be spending a lot on Tylenol and booze when we really do run out of v4 IPs. I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of addresses at once would publish a remark like the one below, indicating that Verizon Wireless has about 2 million IPs allocated. OrgName:Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment:Verizon Wireless currently has 44.3 Million Comment:subscribers with 2.097 Million IP addresses allocated. RegDate:2008-04-14 This may be unscientific and full of error, but if you add up all the IPs behind AS6167, you get a pretty big number, about 27 million. If I make more dangerous assumptions, I might argue that a network with a need for 2 million IPs, at the time this /9 was handed out, already had about 19 million. Then it received 8 million more. Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. But that isn't the case right now, and the ARIN is in the business of supplying its members with six months worth of addresses. If everyone is expected to run out and buy a new phone and start using the Google right away, and stay on it all the time, maybe cellular operators really need a lot more IP addresses. If not, why does Verizon Wireless have 27 million IPs when the above comment indicates they need only a tenth of that? - j
Re: 97.128.0.0/9 allocation to verizon wireless
Whatever happened to NAT? Jeff On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler j...@inconcepts.biz wrote: Dear list, Since IPv4 exhaustion is an increasingly serious and timely topic lately, I would like to point out something that interests me, and maybe everyone else who will be spending a lot on Tylenol and booze when we really do run out of v4 IPs. I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of addresses at once would publish a remark like the one below, indicating that Verizon Wireless has about 2 million IPs allocated. OrgName:Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment:Verizon Wireless currently has 44.3 Million Comment:subscribers with 2.097 Million IP addresses allocated. RegDate:2008-04-14 This may be unscientific and full of error, but if you add up all the IPs behind AS6167, you get a pretty big number, about 27 million. If I make more dangerous assumptions, I might argue that a network with a need for 2 million IPs, at the time this /9 was handed out, already had about 19 million. Then it received 8 million more. Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. But that isn't the case right now, and the ARIN is in the business of supplying its members with six months worth of addresses. If everyone is expected to run out and buy a new phone and start using the Google right away, and stay on it all the time, maybe cellular operators really need a lot more IP addresses. If not, why does Verizon Wireless have 27 million IPs when the above comment indicates they need only a tenth of that? - j -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401.
Re: 97.128.0.0/9 allocation to verizon wireless
Any cell phone that uses data service to download a ringtone, wallpaper, picature, use their TV/radio webcast service, or their walkie talkie feature will use an IP address. In addition to that Verizon wireless sells their EVDO aircards for laptops. Given the size of their customer base it is not shocking that they have 27 million IP addresses in their pool. ARIN doesn't just give them away it would be up to Verizon to prove that they are utilizing 90+% before they could be alloted any additional IP's. Hope this helps explain things a little bit. -Tim Eberhard Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. But that isn't the case right now, and the ARIN is in the business of supplying its members with six months worth of addresses. If everyone is expected to run out and buy a new phone and start using the Google right away, and stay on it all the time, maybe cellular operators really need a lot more IP addresses. If not, why does Verizon Wireless have 27 million IPs when the above comment indicates they need only a tenth of that? - j
Re: 97.128.0.0/9 allocation to verizon wireless
On Sat, Feb 7, 2009 at 9:24 PM, Jeff S Wheeler j...@inconcepts.biz wrote: Dear list, Since IPv4 exhaustion is an increasingly serious and timely topic lately, I would like to point out something that interests me, and maybe everyone else who will be spending a lot on Tylenol and booze when we really do run out of v4 IPs. I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of addresses at once would publish a remark like the one below, indicating that Verizon Wireless has about 2 million IPs allocated. OrgName:Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment:Verizon Wireless currently has 44.3 Million Comment:subscribers with 2.097 Million IP addresses allocated. RegDate:2008-04-14 Why don't you try asking them? OrgTechHandle: MGE16-ARINhttp://ws.arin.net/whois/?queryinput=P%20%21%20MGE16-ARIN OrgTechName: George, Matt OrgTechPhone: +1-908-306-7000 OrgTechEmail: ab...@verizonwireless.com
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On Wednesday 04 February 2009 09:51:16 am Nathan Ward wrote: You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel. Suffice it to say that some vendors are already implementing 'draft-ietf-ospf-af-alt-06.txt', which allows OSPFv3 to handle multiple address families, including IPv4. But this still runs over an IPv6 link. I'd still recommend running IPv4 and IPv6 IGP's separately, unless the IGP integrates both protocols, as in the case of IS-IS. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On Wednesday 04 February 2009 10:10:02 am Steve Bertrand wrote: I'm not ready for MPLS (but I am interested in the theory of it's purpose), so when I'm done what I'm doing now, I'll look at it. Well, having a v6 core will prevent from you running MPLS, as a v6 control plane for MPLS is not yet implemented by the vendors today. A draft for this is already out, though - 'draft-manral- mpls-ldp-ipv6-02'. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
