Home page logo
/

nanog logo nanog mailing list archives

Re: NANOG Digest, Vol 43, Issue 24
From: Artis Schlossberg <artis () infosec lv>
Date: Mon, 8 Aug 2011 11:55:51 +0200

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
*************************************



  By Date           By Thread  

Current thread:
  • Re: NANOG Digest, Vol 43, Issue 24 Artis Schlossberg (Aug 09)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault