unsubscribe On Mon, Aug 8, 2011 at 00:55, <[email protected]> wrote: > Send NANOG mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: IPv6 end user addressing (Joel Jaeggli) > 2. Re: AT&T -> Qwest ... Localpref issue? ([email protected]) > 3. Re: AT&T -> Qwest ... Localpref issue? (Joel Jaeggli) > 4. Re: US internet providers hijacking users' search queries > (Joe Provo) > 5. Re: IPv6 end user addressing (Jeff Wheeler) > 6. RE: IPv6 end user addressing (Jonathon Exley) > 7. Re: IPv6 end user addressing (Joel Jaeggli) > 8. Re: IPv6 end user addressing (David Conrad) > 9. Re: STRIKE: VZN (Matthew S. Crocker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 7 Aug 2011 08:26:09 -0700 > From: Joel Jaeggli <[email protected]> > To: Brian Mengel <[email protected]> > Cc: [email protected] > Subject: Re: IPv6 end user addressing > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > 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 > > > > > ------------------------------ > > Message: 2 > Date: Sun, 07 Aug 2011 11:39:31 -0400 > From: [email protected] > To: Graham Wooden <[email protected]> > Cc: [email protected] > Subject: Re: AT&T -> Qwest ... Localpref issue? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > 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...) > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 227 bytes > Desc: not available > URL: > <http://mailman.nanog.org/pipermail/nanog/attachments/20110807/d629ee01/attachment-0001.bin> > > ------------------------------ > > Message: 3 > Date: Sun, 7 Aug 2011 08:48:14 -0700 > From: Joel Jaeggli <[email protected]> > To: [email protected] > Cc: "<[email protected]> list" <[email protected]> > Subject: Re: AT&T -> Qwest ... Localpref issue? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > 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, [email protected] 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...) > > > > > ------------------------------ > > Message: 4 > Date: Sun, 7 Aug 2011 12:10:30 -0400 > From: Joe Provo <[email protected]> > To: [email protected] > Subject: Re: US internet providers hijacking users' search queries > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Sat, Aug 06, 2011 at 01:25:18PM -0500, Jimmy Hess wrote: >> On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo <[email protected]>wrote: >> >> > 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 > > > > ------------------------------ > > Message: 5 > Date: Sun, 7 Aug 2011 15:00:39 -0400 > From: Jeff Wheeler <[email protected]> > To: [email protected] > Subject: Re: IPv6 end user addressing > Message-ID: > <capwatbjtpmdx-nzu8uphosy+97ygo4fknz5_esghsjp-an9...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <[email protected]> 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. > >>> AT&T 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 <[email protected]> > Sr Network Operator? /? Innovative Network Concepts > > > > ------------------------------ > > Message: 6 > Date: Mon, 8 Aug 2011 10:09:11 +1200 > From: Jonathon Exley <[email protected]> > To: "[email protected]" <[email protected]> > Subject: RE: IPv6 end user addressing > Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> > Content-Type: text/plain; charset="us-ascii" > > 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). > > > > > > ------------------------------ > > Message: 7 > Date: Sun, 7 Aug 2011 15:41:23 -0700 > From: Joel Jaeggli <[email protected]> > To: Jonathon Exley <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: IPv6 end user addressing > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > 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). >> >> >> >> > > > > > ------------------------------ > > Message: 8 > Date: Sun, 7 Aug 2011 12:44:00 -1000 > From: David Conrad <[email protected]> > To: Jonathon Exley <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: IPv6 end user addressing > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > 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 > > > > > ------------------------------ > > Message: 9 > Date: Sun, 07 Aug 2011 18:55:31 -0400 (EDT) > From: "Matthew S. Crocker" <[email protected]> > To: Zaid Ali <[email protected]> > Cc: NANOG <[email protected]> > Subject: Re: STRIKE: VZN > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > > 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" <[email protected]> >> To: "Jay Ashworth" <[email protected]> >> Cc: "NANOG" <[email protected]> >> 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 <[email protected]> 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 >> > [email protected] >> > 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 >> > >> >> >> > > > > End of NANOG Digest, Vol 43, Issue 24 > ************************************* >
