Re: NANOG Digest, Vol 43, Issue 24

[Artis Schlossberg <artis () infosec lv>]

unsubscribe

On Mon, Aug 8, 2011 at 00:55,  <nanog-request () nanog org> wrote:
> Send NANOG mailing list submissions to
>        nanog () nanog org
>
> 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
>        nanog-request () nanog org
>
> You can reach the person managing the list at
>        nanog-owner () nanog org
>
> 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? (Valdis.Kletnieks () vt edu)
>   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 <joelja () bogus com>
> To: Brian Mengel <bmengel () gmail com>
> Cc: nanog () nanog org
> Subject: Re: IPv6 end user addressing
> Message-ID: <404AD93A-F84C-4ABD-8954-216109F22C60 () bogus com>
> 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: Valdis.Kletnieks () vt edu
> To: Graham Wooden <graham () g-rock net>
> Cc: nanog () nanog org
> Subject: Re: AT&T -> Qwest ... Localpref issue?
> Message-ID: <121127.1312731571 () turing-police cc vt edu>
> 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 <joelja () bogus com>
> To: Valdis.Kletnieks () vt edu
> Cc: "<nanog () nanog org> list" <nanog () nanog org>
> Subject: Re: AT&T -> Qwest ... Localpref issue?
> Message-ID: <96A9BBE9-A50A-4D4A-9309-A344C5656E90 () bogus com>
> 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, Valdis.Kletnieks () 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...)
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 7 Aug 2011 12:10:30 -0400
> From: Joe Provo <nanog-post () rsuc gweep net>
> To: nanog () nanog org
> Subject: Re: US internet providers hijacking users' search queries
> Message-ID: <20110807161029.GA50031 () gweep net>
> 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 <nanog-post () rsuc gweep net>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 <jsw () inconcepts biz>
> To: nanog () nanog org
> Subject: Re: IPv6 end user addressing
> Message-ID:
>        <CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-aN9x_A () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen () 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.
>
> > > 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 <jsw () inconcepts biz>
> Sr Network Operator? /? Innovative Network Concepts
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 8 Aug 2011 10:09:11 +1200
> From: Jonathon Exley <Jonathon.Exley () kordia co nz>
> To: "nanog () nanog org" <nanog () nanog org>
> 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 <joelja () bogus com>
> To: Jonathon Exley <Jonathon.Exley () kordia co nz>
> Cc: "nanog () nanog org" <nanog () nanog org>
> Subject: Re: IPv6 end user addressing
> Message-ID: <D2C6BD90-223F-4EC2-84EC-946E364EE495 () bogus com>
> 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 <drc () virtualized org>
> To: Jonathon Exley <Jonathon.Exley () kordia co nz>
> Cc: "nanog () nanog org" <nanog () nanog org>
> Subject: Re: IPv6 end user addressing
> Message-ID: <A52C6266-6633-40A4-8CED-AC5FF834A71C () virtualized org>
> 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" <matthew () corp crocker com>
> To: Zaid Ali <zaid () zaidali com>
> Cc: NANOG <nanog () nanog org>
> Subject: Re: STRIKE: VZN
> Message-ID: <37b62a8d-5dc0-4e95-98da-3ef84bfd5496 () zimbra1 crocker com>
> 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" <zaid () zaidali com>
> > To: "Jay Ashworth" <jra () 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 <jra () 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
> > >                       jra () 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
>
>
>
> End of NANOG Digest, Vol 43, Issue 24
> *************************************