Re: Errant Advertisement - 128.1/16
Did you fix it? My traceroute shows last hop is 64.119.128.44. On Fri, Aug 5, 2011 at 12:07 AM, Rick Altmann raltm...@bbn.com wrote: Is there anyone from ATT on the list that could help with a likely misconfiguration? I have not received any response yet to my complaint (see below) submitted to the abuse address on July 26. We have since started advertising this space and would like to resolve the MOAS condition we have created. The 128.1.0.0/16 address block is registered to BBN Technologies (AS11488) but is currently unused on any BBN networks. BBN would like to begin using this address space however AS7018 is currently originating public BGP routes for this address block. We believe this to be a configuration error. Please help us resolve this. A traceroute to 128.1.0.1 shows the following routers as the last 4 responding hops: cr1.n54ny.ip.att.net (12.122.81.106) cr81.nw2nj.ip.att.net (12.122.105.30) gar18.n54ny.ip.att.net (12.122.105.101) 12.89.231.190 Thanks, Rick
Re: ATT - Qwest ... Localpref issue?
Thanks Paul. Localpref with Qwest on my ATT prefixes was 100 until last week ... So my prepends to balance between the two was working just fine for the past 2 years or so. My announcements to CenturyLink to Qwest are coming out as 100. I am not a direct customer of Qwest, so sending the community of 209:70 won¹t work (already tried that). I am a direct customer of CenturyLink and unfortunately the two networks haven¹t really come together as one just yet. I sent a note to ATT maybe the can help do something, as I reviewed the communities with them and I am already doing what I need to do. The main problem here is that our CenturyLink connection is pure crap ... Even originating routes from their network, I had them take our ATT (the other transit at this particular POP) - faster and less hops (go figure). At our other pops with more than 1 transits, we like to utilize both as much as possible. Contract is up in December ... can¹t wait until it¹s gone. On 8/6/11 11:57 PM, PC paul4...@gmail.com wrote: Qwest uses 80 for peers; 100 for customers. As I'm sure Qwest had ATT as a peer prior to today (and you tagged as a customer), it probably should have been 80 since the beginning. What was the local pref to ATT before? Maybe they found a misconfiguration on a router. If your only objective is to make your Qwest peering backup, send community 209:70 to Qwest and it'll drop your local pref on their network to 70. This will cause their 80 local pref peering with ATT to be preferred. I also suggest you read: http://www.onesc.net/communities/as209/ and http://www.onesc.net/communities/as7018/ However, depending on if your network topology and situational circumstances permit it, it may not be a bad idea to take on-net customer routes for performance reasons. On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden gra...@g-rock.net wrote: Hi folks, Anyone else noticed a localpref change on Qwest network in regards to ATT prefixes? I noticed my ATT assigned prefixes dropping to 80, causing my backup transit peering with Centurylink to take preference with Qwest originators ... All was working fine with my prepends .. But not anymore... Any insight would be great. I haven¹t reached out to ATT or Qwest yet. Curious if this is a bigger change than just me. Thanks, -graham
Re: ATT - Qwest ... Localpref issue?
I should also note that Centurylink has been less than cooperative on even thinking about changing my routes to a pref of 70 on our behalf (they don't accept communities). I think time to get the account rep involved ... On 8/7/11 8:30 AM, Graham Wooden gra...@g-rock.net wrote: Thanks Paul. Localpref with Qwest on my ATT prefixes was 100 until last week ... So my prepends to balance between the two was working just fine for the past 2 years or so. My announcements to CenturyLink to Qwest are coming out as 100. I am not a direct customer of Qwest, so sending the community of 209:70 won¹t work (already tried that). I am a direct customer of CenturyLink and unfortunately the two networks haven¹t really come together as one just yet. I sent a note to ATT maybe the can help do something, as I reviewed the communities with them and I am already doing what I need to do. The main problem here is that our CenturyLink connection is pure crap ... Even originating routes from their network, I had them take our ATT (the other transit at this particular POP) - faster and less hops (go figure). At our other pops with more than 1 transits, we like to utilize both as much as possible. Contract is up in December ... can¹t wait until it¹s gone. On 8/6/11 11:57 PM, PC paul4...@gmail.com wrote: Qwest uses 80 for peers; 100 for customers. As I'm sure Qwest had ATT as a peer prior to today (and you tagged as a customer), it probably should have been 80 since the beginning. What was the local pref to ATT before? Maybe they found a misconfiguration on a router. If your only objective is to make your Qwest peering backup, send community 209:70 to Qwest and it'll drop your local pref on their network to 70. This will cause their 80 local pref peering with ATT to be preferred. I also suggest you read: http://www.onesc.net/communities/as209/ and http://www.onesc.net/communities/as7018/ However, depending on if your network topology and situational circumstances permit it, it may not be a bad idea to take on-net customer routes for performance reasons. On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden gra...@g-rock.net wrote: Hi folks, Anyone else noticed a localpref change on Qwest network in regards to ATT prefixes? I noticed my ATT assigned prefixes dropping to 80, causing my backup transit peering with Centurylink to take preference with Qwest originators ... All was working fine with my prepends .. But not anymore... Any insight would be great. I haven¹t reached out to ATT or Qwest yet. Curious if this is a bigger change than just me. Thanks, -graham
Re: IPv6 end user addressing
On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? When you have a device that delegates, e.g. a cpe taking it's assigned prefix, and delegating a fraction of it to a downstream device, you need enough bits that you can make them out, possibly more than once. if you want that to happen automatically you want enough bits that user-intervention is never (for small values of never) required in to subnet when connecting devices together... the homenet wg is exploring how devices in the home might address the issue of topology discovery in conjunction with delegation, which realistically home networks are going to have to do... https://www.ietf.org/mailman/listinfo/homenet
Re: ATT - Qwest ... Localpref issue?
On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: I should also note that Centurylink has been less than cooperative on even thinking about changing my routes to a pref of 70 on our behalf (they don't accept communities). I think time to get the account rep involved ... they don't accept communities??!? Just... wow. ;) (That's if they flat out don't support it - there's a separate ring of Hell reserved for the ones who do support it but forget to document the part about singing the Zimbabwe national anthem backwards while standing on your head...) pgp0LElBopvOs.pgp Description: PGP signature
Re: ATT - Qwest ... Localpref issue?
This is one of the reasons that I thought a useful output from the opsec or idr working group would be a documented set of community functions. Not mapped to values mind you. but I really like to say to providers do you support rfc blah communities or what's your rfc blah community mapping rather than what communities do you support. On Aug 7, 2011, at 8:39 AM, valdis.kletni...@vt.edu wrote: On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: I should also note that Centurylink has been less than cooperative on even thinking about changing my routes to a pref of 70 on our behalf (they don't accept communities). I think time to get the account rep involved ... they don't accept communities??!? Just... wow. ;) (That's if they flat out don't support it - there's a separate ring of Hell reserved for the ones who do support it but forget to document the part about singing the Zimbabwe national anthem backwards while standing on your head...)
Re: US internet providers hijacking users' search queries
On Sat, Aug 06, 2011 at 01:25:18PM -0500, Jimmy Hess wrote: On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo nanog-p...@rsuc.gweep.netwrote: On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote: Correct, I don't believe that any of the providers noted are actually [snip] Disappointing that nanog readers can't read http://www.paxfire.com/faqs.php and get a clue, instead all the mouth-flapping about MItM and https. a clue, instead all the mouth-flapping about MItM and https. While Maybe instead of jumping to the conclusion NANOG readuers should get a clue, you should actually do a little more research than reading a glossyware/ vacant FAQ that doesn't actually explain everything Paxfire is reported to do, how it works, and what the criticism is? I'm not jumping to conclusions, merely speaking to evidence. My personal experience involves leaving a job at a network that insisted on implementing some of this dreck. There is a well-known, long-standing monetization by breaking NXDOMAIN. DSLreports and plenty of other end-user fora have been full of information regarding this since Earthlink starded doing it in ... 2006? Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat, and not the issue. That sentence makes no sense. Hijacking NXDOMAIN doesn't have anything to do with pointing to a recursive resolver, but returning a partner/ affiliate web site, search helper site or proxy instead of the NXDOMAIN. What the FAQ doesn't tell you is that the Paxfire appliances can tamper with DNS traffic received from authoritative DNS servers not operated by the ISP. A paxfire box can alter NXDOMAIN queries, and queries that respond with known search engines' IPs. to send your HTTP traffic to their HTTP proxies instead. Ty, http://netalyzr.icsi.berkeley.edu/blog/ This is finally something new, and I retract my assertion that the new scientist got it wrong. Drilling through to actual evidence and details, rather than descriptions which match previous behavior, we have both http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little indirect with 'example.com', etc) and http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual domains) provide detail on the matter. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
Re: IPv6 end user addressing
On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong o...@delong.com wrote: Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone. Yes we would. No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind. Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3. There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out. We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48. We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it. How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s. However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3. My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes. While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances. I don't think it does allow for that. I think it requires you to have at least one POP prefix 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme. 2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what hierarchical addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself. ATT serves some entire states out of a single POP, as far as layer-3 termination is concerned. Are any of the states with populations larger than Philadelphia among them? Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
RE: IPv6 end user addressing
This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Jonathon This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
Re: IPv6 end user addressing
On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote: This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? 2000::/3 is 1/8th of the address range. There are other things worth conserving not just /48s like the ability aggregate your whole assignment. 3.5 * 10^13 is a lot of /48s, but it's likely not enough so we'll get to crack the seal on 4000::/3 eventually and so on. After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Jonathon This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
Re: IPv6 end user addressing
Jonathon, On Aug 7, 2011, at 12:09 PM, Jonathon Exley wrote: This has probably been said before, Once or twice :-) but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. This isn't where the worry should be. Do the math. Right now, we're allocating something like 300,000,000 IPv4 addresses per year with a reasonable (handwave) percentage being used as NAT endpoints. If you cross your eyes sufficiently, that can look a bit like 300,000,000 networks being added per year. Translate that to IPv6 and /48s: There are 35,184,372,088,832 /48s in the format specifier currently defined for global unicast. For the sake of argument, let's increase the the 'network addition' rate by 3 orders of magnitude to 300,000,000,000 per year. At that rate, which is equivalent to allocating 42 /48s per person on the planet per year, the current format specifier will last about 100 years. And there are 7 more format specifiers. but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? The area to be more conservative is, perhaps unsurprisingly, in the network bureaucratic layer. I believe current allocation policy states an ISP gets a minimum of a /32 (allowing them to assign 65536 /48s), but if justified an ISP can get more. There have been allocations of all sorts of shorter prefixes, e.g., /19s, /18s, and even (much) shorter. An ISP that has received a /19 has the ability to allocate half a billion /48s. And of course, there are the same number of /19s, /18s, and even (much) shorter prefixes in IPv6 as there are in IPv4... After all, there are only 4 bits of IP version field so the basic packet format won't last forever. True. There is no finite resource poor policy making can't make scarce. Regards, -drc
Re: STRIKE: VZN
Historically the network gets more stable when they are on strike. It is amazing how well stuff works when nobody is mucking with the network. We received new keys for all of our Verizon colos the other day, first time that has happened. - Original Message - From: Zaid Ali z...@zaidali.com To: Jay Ashworth j...@baylink.com Cc: NANOG nanog@nanog.org Sent: Sunday, August 7, 2011 1:39:19 AM Subject: Re: STRIKE: VZN I heard a few days ago this might happen through another carrier who depends on a local loop from VZ. If you are waiting on circuit installs or someone has to swap out an NI card this may impact you. Thanks for the link. Zaid Sent from my iPhone On Aug 6, 2011, at 10:14 PM, Jay Ashworth j...@baylink.com wrote: As of midnight, 45,000 IBEW and CWA members are striking Verizon, as their contract has expired. http://www.reuters.com/article/2011/08/07/us-verizon-labor-idUSTRE7760C320110807 It's not clear how this might affect what we do, but it might, and I figured the heads up would probably be useful. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: IPv6 end user addressing
In message capwatbjtpmdx-nzu8uphosy+97ygo4fknz5_esghsjp-an9...@mail.gmail.com , Jeff Wheeler writes: On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong o...@delong.com wrote: Well, you aren't actually doing this on your network today. =A0If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone. Yes we would. No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind. Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3. There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out. So you want HE to force all their clients to renumber. We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48. The client can request a /48 or /64 as the initial allocation. We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it. How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s. However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3. My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. =A0This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes. While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances. I don't think it does allow for that. I think it requires you to have at least one POP prefix 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme. 2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what hierarchical addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself. ATT serves some entire states out of a single POP, as far as layer-3 termination is concerned. Are any of the states with populations larger than Philadelphia among them? Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory. --=20 Jeff S Wheeler j...@inconcepts.biz Sr Network Operator=A0 /=A0 Innovative Network Concepts -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 end user addressing
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews ma...@isc.org wrote: So you want HE to force all their clients to renumber. No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough. Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise: There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed. The effect of 2011-3 is that an out-sized ISP like ATT has every justification for deciding to allocate 24 bits worth of subnet ID for their largest POP, say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full. So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way. Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for POP ID. So ATT is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves. Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv6 end user addressing
ATT serves some entire states out of a single POP, as far as layer-3 termination is concerned. Are any of the states with populations larger than Philadelphia among them? Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory. Does ATT seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me. I have a few customers in Indiana that are small ILECs and they each have multiple (2-3) POPs even though they have no more than about 1,000 customers. -Randy
Re: IPv6 end user addressing
On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said: Does ATT seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me. It makes sense if they're managing to bill customers by the cable mile from their location to the POP. Imagine a POP in Terre Haute or Indianapolis and 1,500+ customers in the Gary area and another 1K in the South Bend and Fort Wayne areas... Of course, some other provider would get a clue and and offer the same price per mile your location to our POP - after putting a POP in Gary, South Bend, and Fort Wayne. :) pgp1Ex5J9sZBv.pgp Description: PGP signature
Re: IPv6 end user addressing
On Sun, Aug 07, 2011 at 09:45:31PM -0400, valdis.kletni...@vt.edu wrote: On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said: Does ATT seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me. It makes sense if they're managing to bill customers by the cable mile from their location to the POP. Imagine a POP in Terre Haute or Indianapolis and 1,500+ customers in the Gary area and another 1K in the South Bend and Fort Wayne areas... Of course, some other provider would get a clue and and offer the same price per mile your location to our POP - after putting a POP in Gary, South Bend, and Fort Wayne. :) ATT doesn't serve the entire state of Indiana from a single POP. The question at hand was how many POPs *with layer 3 service* they had. I don't know the answer to that question and don't claim that it is or is not one, but the TDM or L2 backhaul from the nearest POP to whatever other POP has the Layer 3 service isn't paid for by the customer. It's also not clear if they were talking about ATT the LEC (offering services like DSL) or ATT the IXC (offering things like business Internet service, V4VPN services, etc). If the latter, it's not at all surprising; legacy IXCs often have more POPs than POPs w/ Layer 3 services, and they backhaul L3 services over their legacy TDM and/or Layer 2 (ATM or FR) networks to a POP that has a router. This was a way for them to get IP service everywhere without installing routers everywhere; as the service took off, more POPs could be IP enabled to reduce the about of TDM (etc.) backhaul. But large legacy IXCs have a lot of POPs and, in general, still don't have routers (customer facing routers, anyway) in all of them. -- Brett
Re: IPv6 end user addressing
On Sun, Aug 7, 2011 at 6:09 PM, Jonathon Exley jonathon.ex...@kordia.co.nz wrote: This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Hi Jonathan, IPv6 uses a slightly different mental model when it comes to address allocation. In IPv4 you assigned blocks of 32-bit addresses. In IPv6 this is no longer the case. You do not assign blocks of 128-bit addresses. In IPv6 you assign blocks of 64-bit LANs. Each LAN is 64-bits long as required by technologies like SLAAC. So, a /48 is 65k LANs, _not_ however many bazillion addresses. The question you should be asking is: is it excessive or unwise to go around assigning 65,000 LANs to every customer? Would 256 (/56) or 1 (/64) be a better number? Assigning 1 LAN seems questionable. We're trying to avoid NAT with IPv6 which means a customer may want to spend a LAN on things like the interior network of a virtual machine server. It's hard to do this if you only have one LAN. On the other hand, a whole lot of folks have through this through before you and concluded that a /56 (256 LANs per customer) is a smarter starting point than a /48. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
