[143369] in North American Network Operators' Group
Re: NANOG Digest, Vol 43, Issue 24
daemon@ATHENA.MIT.EDU (Artis Schlossberg)
Mon Aug 8 05:57:29 2011
In-Reply-To: <mailman.1893.1312757734.1873.nanog@nanog.org>
From: Artis Schlossberg <artis@infosec.lv>
Date: Mon, 8 Aug 2011 11:55:51 +0200
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
unsubscribe
On Mon, Aug 8, 2011 at 00:55, <nanog-request@nanog.org> wrote:
> Send NANOG mailing list submissions to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0nanog@nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailman.nanog.org/mailman/listinfo/nan=
og
> or, via email, send a message with subject or body 'help' to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0nanog-request@nanog.org
>
> You can reach the person managing the list at
> =C2=A0 =C2=A0 =C2=A0 =C2=A0nanog-owner@nanog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>
>
> Today's Topics:
>
> =C2=A0 1. Re: IPv6 end user addressing (Joel Jaeggli)
> =C2=A0 2. Re: AT&T -> Qwest ... Localpref issue? (Valdis.Kletnieks@vt.edu=
)
> =C2=A0 3. Re: AT&T -> Qwest ... Localpref issue? (Joel Jaeggli)
> =C2=A0 4. Re: US internet providers hijacking users' search queries
> =C2=A0 =C2=A0 =C2=A0(Joe Provo)
> =C2=A0 5. Re: IPv6 end user addressing (Jeff Wheeler)
> =C2=A0 6. RE: IPv6 end user addressing (Jonathon Exley)
> =C2=A0 7. Re: IPv6 end user addressing (Joel Jaeggli)
> =C2=A0 8. Re: IPv6 end user addressing (David Conrad)
> =C2=A0 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=3Dus-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. =C2=A0/64 and /56 seem to be the favorite candidates, with /56 be=
ing
>> slightly preferred.
>>
>> I am most curious as to why a /60 prefix is not considered when trying
>> to address this problem. =C2=A0It provides 16 /64 subnetworks, which see=
ms
>> 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 pr=
efix, and delegating a fraction of it to a downstream device, you need enou=
gh bits that you can make them out, possibly more than once. if you want th=
at to happen automatically you want enough bits that user-intervention is n=
ever (for small values of never) required in to subnet when connecting devi=
ces together...
>
> the homenet wg is exploring how devices in the home might address the iss=
ue of topology discovery in conjunction with delegation, which realisticall=
y 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=3D"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 ev=
en
>> thinking about changing my routes to a pref of 70 on our behalf (they do=
n'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 He=
ll
> 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/d629e=
e01/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=3Dus-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 su=
pport rfc blah communities" or "what's your rfc blah community mapping" rat=
her 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 e=
ven
>>> thinking about changing my routes to a pref of 70 on our behalf (they d=
on'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 H=
ell
>> 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=3Dus-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>wr=
ote:
>>
>> > 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 actuall=
y
>> > [snip]
>> > =C2=A0 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. =C2=A0 =C2=
=A0 a clue,
>> > instead all the mouth-flapping about MItM and https. While
>>
>>
>> Maybe =C2=A0instead 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 =C2=A0that doesn't actually explain everything Paxfire is rep=
orted to
>> do, how it works, =C2=A0and 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 =C2=A0_own_ recursive servers is o=
ld 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 =C2=A0appliances can t=
amper
>> with DNS
>> traffic =C2=A0received from authoritative DNS servers not operated by th=
e ISP.
>> A paxfire box can alter NXDOMAIN queries, and =C2=A0queries that respond=
with
>> known search engines' IPs.
>> to send your HTTP traffic to their HTTP proxies instead.
>>
>> Ty, =C2=A0http://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
>
> --
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 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:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0<CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-=
aN9x_A@mail.gmail.com>
> Content-Type: text/plain; charset=3DISO-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. =C2=A0You'd then summarize at your ABRs so the
> entire POP need only inject one route for customer addressing into the
> backbone. =C2=A0Of 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. =C2=A0Yes, 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? =C2=A0You 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. =C2=A0I think it requires you to ha=
ve
> 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. =C2=A0This 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. =C2=A0It should, but my read is that the
> authors have a very different opinion about what "hierarchical"
> addressing means than I do. =C2=A0It 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. =C2=A0Pretty 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=3D"us-ascii"
>
> This has probably been said before, but it makes me uncomfortable to thin=
k 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 s=
ites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but woul=
dn't it be wise to apply some conservatism now to allow the IPv6 address sp=
ace 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=3Dus-ascii
>
>
> On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote:
>
>> This has probably been said before, but it makes me uncomfortable to thi=
nk 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 wou=
ldn't it be wise to apply some conservatism now to allow the IPv6 address s=
pace to last for many more years?
>
> 2000::/3 is 1/8th of the address range. There are other things worth cons=
erving =C2=A0not 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=3Dus-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 g=
iven /48 subnets by default.
>
> This isn't where the worry should be. =C2=A0Do the math. =C2=A0Right now,=
we're allocating something like 300,000,000 IPv4 addresses per year with a=
reasonable (handwave) percentage being used as NAT endpoints. =C2=A0If you=
cross your eyes sufficiently, that can look a bit like 300,000,000 network=
s being added per year. =C2=A0Translate that to IPv6 and /48s:
>
> There are 35,184,372,088,832 /48s in the format specifier currently defin=
ed for "global unicast". =C2=A0For the sake of argument, let's increase the=
the 'network addition' rate by 3 orders of magnitude to 300,000,000,000 pe=
r year. =C2=A0At that rate, which is equivalent to allocating 42 /48s per p=
erson 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 netwo=
rk bureaucratic layer. =C2=A0I believe current allocation policy states an =
ISP gets a minimum of a /32 (allowing them to assign 65536 /48s), but "if j=
ustified" an ISP can get more. =C2=A0There have been allocations of all sor=
ts of shorter prefixes, e.g., /19s, /18s, and even (much) shorter. =C2=A0An=
ISP that has received a /19 has the ability to allocate half a billion /48=
s. 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. =C2=A0There is no finite resource poor policy making can't make sca=
rce.
>
> 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=3Dutf-8
>
>
> Historically the network gets more stable when they are on strike. =C2=A0=
It is amazing how well stuff works when nobody is mucking with the network.=
=C2=A0We received new keys for all of our Verizon colos the other day, =C2=
=A0first 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-idUSTRE7760=
C320110807
>> >
>> > 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Baylink
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 jra@baylink.com
>> > Designer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 The Things I Think
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 RFC 2100
>> > Ashworth & Associates =C2=A0 =C2=A0 http://baylink.pitas.com =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 2000
>> > Land Rover DII
>> > St Petersburg FL USA =C2=A0 =C2=A0 =C2=A0http://photo.imageinc.us =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
>> > 727 647 1274
>> >
>>
>>
>>
>
>
>
> End of NANOG Digest, Vol 43, Issue 24
> *************************************
>
