Re: Did I miss a problem: FCC and CISA stress need for access during pandemic

[Benson Schliesser via NANOG]

Good question -

Of the listed “key points” the first and second, regarding designation as
essential employees, has been explicitly included in the several state and
county orders that I’ve personally read. By no means a complete survey, but
at least some locales are aware of the issue.

The only one that I’ve heard is (anecdotally) a problem is the last one,
regarding permits. E.g. in some cases state, county, and/or local
permitting offices have been operating slower than usual or simply closed.
In some cases because they’re reliant on agents, inspectors, etc, who
aren’t considered essential...

But this seems like more of an issue for new deployments (e.g. 5G masts)
rather than security and/or maintaining existing infrastructure. Not to
diminish the importance of new infrastructure, but it’s a mixed bag - some
of it is about connecting people in need, some of it is driven
predominantly by business / competitive concerns.

I’d be interested to hear others’ experiences if they can illuminate more.

Thanks,
- Benson


On Tue, May 26, 2020 at 21:41 Sean Donelan  wrote:

>
> I have not heard of any problems with access for ISP and communications
> workers in any U.S. state or locality during the pandemic.
>
> Did I miss a big problem requiring the FCC chairman and CISA Director send
> a letter?
>
>
>
>
> https://www.fcc.gov/document/fcc-cisa-stress-need-communications-industry-access-resources-0
>
>
> Federal Communications Commission Chairman Ajit Pai and the Cybersecurity
> and Infrastructure Security Agency (CISA) Director Christopher Krebs
> today sent a letter to the nation’s governors encouraging them to provide
> necessary access and resources to the communications workers helping to
> keep Americans connected during the COVID-19 pandemic.
>
> [...]
>
> The letter includes these key points:
> - Highlights recent guidance from CISA related to the essential critical
> infrastructure workforce and 911 centers during the pandemic
> - Asks that certain communications industry entities and personnel be
> declared essential to the pandemic response and afforded all appropriate
> access and resources
> - Asks that states consider prioritizing the distribution of personal
> protective equipment to communications personnel when available
> - Underscores the role of various communications industry personnel to
> supporting consumers’ remote emergency communications needs
> - Encourages industry and government to work together to prioritize and
> complete communications infrastructure and next generation 911 projects
> - Calls on states to facilitate the maintenance, repair, and provisioning
> of communications infrastructure and services by providing online access
> to relevant government functions, such as the permitting process, where
> not already available electronically.
>

Re: RIPE NCC Executive Board election

[Benson Schliesser via NANOG]

To many (or most) of the people participating in this thread -

I enjoy watching flame wars as much - perhaps more - than the next
person...

But please keep in mind the NANOG mailing list guidelines at
https://www.nanog.org/resources/usage-guidelines/ as well as the Code of
Conduct that's included by reference at
https://www.nanog.org/about/code-conduct/. Clearly, there are multiple
NANOG mailing list guidelines that are being violated by people in this
thread. I encourage all of you to read the guidelines and evaluate each
message carefully before sending it.

I'd especially like to draw your attention to one guideline in particular:

#2 - Posts should be thoughtfully crafted for an audience of more than
10,000 Internet-networking engineers, operators, and architects in our
community.

Even if I am insanely generous in how I characterize the technical and
operational value of these messages, it's pretty clear that many of them
don't pass this particular test. So, please up your game. Otherwise, you're
wasting the time of thousands of people. And you're creating more work for
NANOG staff - they will have to issue warnings, place people into
moderation queues, etc. It's just a pain in the ass for everybody involved,
so don't do it.

Thanks,
 - Benson
(I am a NANOG Board Member, but I am sending this message only in my
personal capacity at this time.)

Re: FCC grants WISPs temporary 5.9 GHz spectrum access

[Benson Schliesser via NANOG]

Indeed, this does seem like good news under the current situation. It's
good for users, and it's nice PR for both the FCC and the WISPs. But I'm
curious: What do these 33 operators anticipate after the STA expires in 60
days?

Obviously their plans may need to adjust depending on the pandemic response
at that time... But thinking ahead: Do the WISPs migrate users before the
60 days expire, or does the STA morph into something more permanent? What's
the strategy?

 - Benson

On Wed, Apr 1, 2020 at 8:56 PM Jared Mauch  wrote:

> The big announcement is the 6ghz space opening up. This will be big for
> people doing p2p links.
>
> Sent from my iCar
>
> > On Apr 1, 2020, at 8:42 PM, Sean Donelan  wrote:
> >
> > 
> > I missed this announcement last week.
> >
> >
> >
> https://www.fcc.gov/document/fcc-grants-wisps-temporary-59-ghz-spectrum-access-rural-broadband
> >
> > The FCC’s Wireless Telecommunications Bureau today granted temporary
> spectrum access to 33 wireless Internet service providers serving 330
> > counties in 29 states to help them serve rural communities facing an
> increase in broadband needs during the COVID-19 pandemic. The Special
> Temporary Authority (STA) granted today allows these companies to use the
> lower 45 megahertz of spectrum in the 5.9 GHz band for 60 days.
>

Reminder: NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community -

As a reminder, the NANOG Program Committee (PC) is still accepting
proposals for talks, tutorials, tracks & panels at the upcoming NANOG 77 in
Austin, Texas, October 28-30, 2019.

Below is a summary of key details and dates from the Call For Presentations
on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Key dates for NANOG 77:

Date

Event/Deadline

Aug. 19, 2019

CFP Deadline

Sep. 23, 2019

CFP Topic List & NANOG Meeting Highlights Page posted

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins


We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC

NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community,

The NANOG Program Committee (PC) is excited to announce that we are now
accepting proposals for all sessions at NANOG 77 in Austin, Texas, October
28-30, 2019. Below is a summary of key details and dates from the Call For
Presentations on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Given by many of the industry’s top minds, presentations at NANOG meetings
are meant to spark the imagination, encourage dialog, and drive new
solutions to our greatest networking challenges. The PC is currently
seeking proposals, and also welcomes suggestions for speakers and topics.
Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Timeline for submission and proposal review:

   -

   Submitter enters abstract (and draft slides if possible) in PC Tool
   prior to the deadline for slide submission.
   -

   PC performs initial review and assigns a “shepherd” to help develop the
   submission — within 2 weeks.
   -

   Submitter develops draft slides of talk if not already submitted with
   the initial proposal. Please submit initial draft slides early — the PC
   does not evaluate submissions until draft slides are available for review.
   NANOG Staff is available to assist with slide templates upon request from
   the submitter.
   -

   Panel and Track submissions should provide a topic list and
   intended/confirmed participants in the abstract.
   -

   PC reviews the slides and continues to work with Submitter as needed to
   develop the topic.
   -

   Draft presentation slides should be submitted prior to the published
   deadline for slides (Aug. 19, 2019).
   -

   PC evaluates submissions to determine presentations for the agenda
   (posted on Sep 30, 2019).
   -

   Agenda assembled and posted.
   -

   Submitters notified.
   -

   Final presentation slides must be submitted prior to the published
   deadline for slides (Oct. 21, 2019).


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the PC (
nano...@nanog.org), and a representative will respond to you in a timely
manner. Otherwise, submit your talk, keynote, track, or panel proposal to
the PC Tool at your earliest convenience. We look forward to reviewing your
submission!

Key dates for NANOG 77:

Date

Event/Deadline

Jul. 1, 2019

CFP Opens & Agenda Outline Posted, Early Registration Begins

Jul. 22, 2019

Standard Registration Begins

Aug. 19, 2019

CFP Deadline: Presentation Slides Due

Sep. 23, 2019

CFP Topic List & NANOG Meeting HIghlights Page posted, Late Registration
Begins

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins

Final slides must be submitted by Monday, October 21, 2019, and no changes
will be accepted between that date and the conference. Materials received
after that date may be updated on the website after the completion of the
conference.

We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC

NANOG 76 call for presentations is open

[Benson Schliesser]

NANOG Community,

The NANOG Program Committee (PC) is excited to announce that we are now
accepting proposals for all sessions at NANOG 76 in Washington, DC, June
10-12, 2019. Below is a summary of key details and dates from the Call For
Presentations on the NANOG website, which can be found at
http://www.cvent.com/d/s6qzk4/6K

Given by many of the industry’s top minds, presentations at NANOG meetings
are meant to spark the imagination, encourage dialog, and drive new
solutions to our greatest networking challenges. The PC is currently
seeking proposals, and also welcomes suggestions for speakers and topics.
Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 76 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Timeline for submission and proposal review:

   -

   Submitter enters abstract (and draft slides if possible) in PC Tool
   prior to the deadline for slide submission.
   -

   PC performs initial review and assigns a “shepherd” to help develop the
   submission — within 2 weeks.
   -

   Submitter develops draft slides of talk if not already submitted with
   the initial proposal. Please submit initial draft slides early — the PC
   typically does not accept submissions until draft slides are available for
   review. NANOG Staff is available to assist with slide templates upon
   request from the submitter.
   -

   Panel and Track submissions should provide a topic list and
   intended/confirmed participants in the abstract.
   -

   PC reviews the slides and continues to work with Submitter as needed to
   develop the topic.
   -

   Draft presentation slides should be submitted prior to the published
   deadline for slides (May 06, 2019).
   -

   PC accepts or declines the submission.
   -

   Agenda assembled and posted.
   -

   Submitters notified.
   -

   Final presentation slides must be submitted prior to the published
   deadline for slides (Jun. 03, 2019).


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the PC (
nano...@nanog.org), and a representative will respond to you in a timely
manner. Otherwise, submit your talk, keynote, track, or panel proposal to
the PC Tool at your earliest convenience. We look forward to reviewing your
submission!

Key dates for NANOG 76:

Date

Event/Deadline

Mar. 18, 2019

CFP Opens & Agenda Outline Posted, Early Registration Begins

Apr. 15, 2019

Standard Registration Begins

May 06, 2019

CFP Deadline: Presentation Slides Due

May 13, 2019

CFP Topic List & NANOG Meeting HIghlights Page posted

May 28, 2019

NANOG 76 Agenda Posted, Late Registration Begins

Jun. 03, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Jun. 09, 2019

Lightning Talk Submissions Open, Onsite Registration Begins

Final slides must be submitted by Monday, June 3, 2019, and no changes will
be accepted between that date and the conference. Materials received after
that date may be updated on the website after the completion of the
conference.

We look forward to seeing you in June in Washington, DC!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC

Re: Oct. 3, 2018 EAS Presidential Alert test

[Benson Schliesser via NANOG]

Hi, Andy.

I don't have a helpful answer for you, because I'm at the NANOG meeting in
Canada right now and as far as I could tell none of the attendees' phones
alerted. But I am curious if perhaps your office has a micro-cell for AT&T,
or something like that, which might have caused different behavior versus
the public tower?

Cheers,
-Benson


On Wed, Oct 3, 2018, 12:22 Andy Ringsmuth  wrote:

> Did anyone on AT&T or an iPhone receive the test today? I believe it was
> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20
> EDT.
>
> I’m in CDT, so 1:18 and 1:20 p.m. CDT.
>
> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the
> sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full
> of AT&T iPhones and not a single one of them alerted.
>
> FEMA says https://www.fema.gov/emergency-alert-test
>
> "Cell towers will broadcast the WEA test for approximately 30 minutes
> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones
> that are switched on, within range of an active cell tower, and whose
> wireless provider participates in WEA should be capable of receiving the
> test message. Some cell phones will not receive the test message, and cell
> phones should only receive the message once."
>
> My wife, with a Sprint iPhone, received the test.
>
>
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com
>
>

Re: ARIN RPKI TAL deployment issues

[Benson Schliesser via NANOG]

Hi, John.

On Tue, Sep 25, 2018, 22:56 John Curran  wrote:

>
> Indeed - In the process of complying with a different legal environment,
> ARIN sometimes has to behave differently than RIRs that are located
> elsewhere...
>
> [...]
>
> The significant difference for ARIN is that we operate under a different
> legal regime, and as a matter of US law, it appears that we cannot rely
> only upon terms and conditions published in our website as evidence of
> informed agreement; i.e. within the US legal framework, we need a specific
> act of acceptance in order to have a binding agreement.
>

Without venturing too far off topic, can you briefly compare this situation
versus e.g. licensing of open source software? Often, such software is
(apparently) licensed without express agreement - using bundled license
files, comments inside source files, etc - and seems to accommodate the IPR
and liability needs of developers and their supporting organizations. Is it
ARIN's understanding that this approach is not useful for RPKI data in the
US, etc?

In any case, I also look forward to hearing the Overcoming Legal Barriers
to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope
that the Q&A discussion (and evening follow-up) will be helpful.

Thanks,
-Benson

Re: Recent trouble with QUIC?

[Benson Schliesser]

Hi, Sean.

I had precisely this experience, mostly noticed just in the past day or so.
I assumed it was an effect of the firewall/NAT setup that my corporate IT
network has implemented, because it often is a culprit in these kind of
situations... But noticing that it was only for QUIC connections to Google
(I likewise use Apps hosted email) I just turned off QUIC in Chrome and the
problem went away.

I have no real insight about the issue beyond that. Except to say that the
packets captures I performed were not very useful to me, personally,
because encrypted QUIC traffic isn't very revealing in Wireshark. :) Though
I may simply be missing some clue and/or skill in making sense of it.

I guess I'm glad to hear that others such as yourself are seeing the same
problem. Because now I don't have to harass my corporate IT dept. Instead
we can look forward to speculation about Google, QUIC adoption in the near
future, etc.

Cheers,
-Benson


On Wednesday, September 23, 2015, Sean Hunter  wrote:

> Hi all,
>
> I work for a 2500 user university and we've seen some odd behavior
> recently. 2-4 weeks ago we started seeing Google searches that would fail
> for ~2 minutes, or disconnects in Gmail briefly. This week, and
> particularly in the last 2-3 days, we've had reports from numerous users on
> campus, even those who generally do not complain unless an issue has been
> ongoing for a while. Those reports include Drive disconnecting, searches
> failing, Gmail presenting a "007" error, and calendar failing to create
> events.
>
> In fact, the issue became so widespread today, that the campus paper is
> writing about it as a last minute article before they're weekly
> publication's deadline this evening. (Important in our little world where
> we try to look good.)
>
> We aren't really staffed or equipped to figure out exactly what's happening
> (and issues are sporadic, so packet captures are difficult, to say the
> least), but we found that disabling QUIC dramatically and immediately
> improved the experience of a couple of users on campus. We're recommending
> via the paper that others do so as well.
>
> What I'm curious about is:
>
> a) Has anyone here had a similar experience? Was the root cause QUIC in
> your case?
>
> b) Has anyone noticed anything remotely similar in the last few
> weeks/days/today?
>
> We're an Apps domain, so this may be specific to universities in the Apps
> universe.
>
> If anyone has any useful information or hints, or if someone from Google
> would like more information, please feel free to contact me, on or off
> list.
>
> Thanks for reading and have a great night everyone! Happy Wednesday!
>

Re: Thousands of hosts on a gigabit LAN, maybe not

[Benson Schliesser]

Morrow's comment about the ARMD WG notwithstanding, there might be some 
useful context in https://tools.ietf.org/html/draft-karir-armd-statistics-01


Cheers,
-Benson


Christopher Morrow 
May 8, 2015 at 12:19 PM

consider the pain of also ipv6's link-local gamery.
look at the nvo3 WG and it's predecessor (which shouldn't have really
existed anyway, but whatever, and apparently my mind helped me forget
about the pain involved with this wg)

I think 'why one lan' ? why not just small (/26 or /24 max?) subnet
sizes... or do it all in v6 on /64's with 1/rack or 1/~200 hosts.
John Levine 
May 8, 2015 at 11:53 AM
Some people I know (yes really) are building a system that will have
several thousand little computers in some racks. Each of the
computers runs Linux and has a gigabit ethernet interface. It occurs
to me that it is unlikely that I can buy an ethernet switch with
thousands of ports, and even if I could, would I want a Linux system
to have 10,000 entries or more in its ARP table.

Most of the traffic will be from one node to another, with
considerably less to the outside. Physical distance shouldn't be a
problem since everything's in the same room, maybe the same rack.

What's the rule of thumb for number of hosts per switch, cascaded
switches vs. routers, and whatever else one needs to design a dense
network like this? TIA

R's,
John

Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Benson Schliesser]

Hi, Eric -

Bill already described the salient points. The "transition" space is 
meant to be used for cases where there are multiple stacked NATs, such 
as CGN with CPE-based NAT. In theory, if the NAT implementations support 
it, one could use it repeatedly by stacking NAT on top of NAT ad 
nauseum, but the wisdom of doing so is questionable. If one uses it like 
additional RFC1918 space then routing could become more difficult, 
specifically in the case where hosts (e.g. VPC servers) are numbered 
with it. This is true because, in theory, you don't need the transition 
space to be routed on the "internal" network which avoids having NAT 
devices hold conflicting routes etc. Even if the edge NAT devices don't 
currently see conflicting routes to 100.64/10, if that changes in the 
future then client hosts may find themselves unable to reach the VPC 
hosts at that time.


That being said, if you understand the risks that I described above, 
then it may work well for a "community of interest" type of 
inter-network that hosts non-global resources. From your description it 
sounds like that might be the situation you find yourself in. To be 
clear, it's not unwise to do so, but it does carry risk that needs to be 
evaluated (and documented).


Cheers,
-Benson



William Herrin 
February 23, 2015 at 12:58 PM

Hi Eric,

The main risk is more or less as you summarized it. Customer has no
firewall or originates the VPN directly from their firewall. Customer
buys a non-hosting commodity Internet product that uses carrier NAT to
conserve IP addresses. The customer's assigned address AND NETMASK
combined overlap some of the hosts you're trying to publish to them.



Mitigations for that risk:

Can you insist that the customer originate connections from inside
their firewall (on RFC1918 space)?

Most service providers using 100.64/10 either permit customers to opt
out (getting dynamic globally routable addresses) or offer customers
the opportunity to purchase static global addresses for a nominal fee.
Are you comfortable telling impacted customers that they have to do
so?


A secondary risk comes in to play where a customer may wish to
interact with another service provider doing the same thing as you.
That essentially lands you back in the same problem you're having now
with RFC1918.


One more question you should consider: what is the nature of your
customer's networks? Big corps that tend to stretch through 10/8 won't
let their users originate VPN connections in the first place. They
also don't touch 100.64/10 except where someone is publishing a
service like yours. Meanwhile, home and SOHO users who are at liberty
to originate VPNs might currently hold a 100.64/10 address. But they
just about never use the off-bit /16s in 10/8. By off-bit I mean the
ones with 4 or 5 random 1-bits in the second octet.


My opinion: The likelihood of collisions in 100.64/10 increases
significantly if you use them on servers. I would confine my use to
client machines and try to put servers providing service to multiple
organizations on globally unique IPs. Confining 100.64/10 to client
machines, you're unlikely to encounter a problem you can't readily
solve.

Regards,
Bill Herrin


Eric Germann 
February 23, 2015 at 10:02 AM
Currently engaged on a project where they’re building out a VPC 
infrastructure for hosted applications.


Users access apps in the VPC, not the other direction.

The issue I'm trying to get around is the customers who need to 
connect have multiple overlapping RFC1918 space (including overlapping 
what was proposed for the VPC networks). Finding a hole that is big 
enough and not in use by someone else is nearly impossible AND the 
customers could go through mergers which make them renumber even more 
in to overlapping 1918 space.


Initially, I was looking at doing something like (example IP’s):


Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC 
<——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24)


Classic overlapping subnets on both ends with allocations out of 
100.64.0.0/10 to NAT in both directions. Each sees the other end in 
100.64 space, but the mappings can get tricky and hard to keep track 
of (especially if you’re not a network engineer).



In spitballing, the boat hasn’t sailed too far to say “Why not use 
100.64/10 in the VPC?”


Then, the customer would be allocated a /28 or larger (depending on 
needs) to NAT on their side and NAT it once. After that, no more NAT 
for the VPC and it boils down to firewall rules. Their device needs to 
NAT outbound before it fires it down the tunnel which pfSense and 
ASA’s appear to be able to do.


I prototyped this up over the weekend with multiple VPC’s in multiple 
regions and it “appears” to work fine.


From the operator community, what are the downsides?

Customers are businesses on dedicated business services vs. consumer 
cable modems (although there are a few on busines

Inevitable death, was Re: Verizon Public Policy on Netflix

[Benson Schliesser]

Thanks for adding this perspective, Barry. I think it's realistic. But I
also think it might miss an orthogonally connected issue - this isn't just
about bandwidth, but about commoditization, consolidation, size etc. It may
be that small ISPs just can't compete (at least in the broader market) as
the market evolves. Similar to how I was disappointed by the loss of my
local bookstore, but still buy all my stuff from Amazon. ... I hear Brett
essentially asking for Netflix to do more for him than it does for big
ISPs, because his small rural business model can't compete with the big
guys.

Thoughts?

Cheers,
-Benson
 On Jul 13, 2014 3:59 PM, "Barry Shein"  wrote:

>
> Just an observation:
>
> I've been on the internet since dirt was rocks.
>
> It seems to me that one theme which has come up over and over and over
> is that some new-ish technology demands more bandwidth than whatever
> it was people were doing previously and as it popularizes people begin
> fighting.
>
> In the early 80s it was downloading the host table, "could people
> please try NOT to all download via a script at exactly midnight!!!"
>
> Then it was free software in the eighties, did WSMR et al really have
> a RIGHT to become a magnet for such popular program downloads?!
>
> And graphic connection to remote super-computer centers. Could the
> images please be generated locally and downloaded "off hours"
> (whatever "off hours" meant on the internet) or even shipped via tape
> etc rather than all these real-time graphical displays running???!!!
>
> Hey, the BACKBONE was 56kb.
>
> Then Usenet, and images, particularly, oh, explicit images because OMG
> imagine if our administration found out our link was slow because
> students (pick a powerless political class to pick on and declare
> THEIR use wasteful) were downloading...um...you know.
>
> And games OMG games.
>
> I remember sitting in an asst provost's office in the 80s being
> lectured about how email was a complete and total waste of the
> university's resources! Computers were for COMPUTING (he had a phd in
> physics which is where that was coming from.)
>
> And the public getting on the internet (ahem.)
>
> On and on.
>
> Now it's video streaming.
>
> And then the bandwidth catches up and it's no big deal anymore.
>
> And then everyone stops arguing about it and goes on to the next thing
> to argue about. Probably will be something in the realm of this
> "Internet of Things" idea, too many people conversing with their
> toaster-ovens.
>
> My comment has always been the same:
>
>There are two kinds of people in this world: Those who try to
>figure out how bake more bread, and those who herd people into
>bread lines.
>
> I've always tried to be the sort of person who tries to figure out how
> to bake more bread. This too shall pass.
>
> --
> -Barry Shein
>
> The World  | b...@theworld.com   |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
> Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
>

Re: net neutrality and peering wars continue

[Benson Schliesser]

On 2013-06-21 4:54 AM, Bill Woodcock wrote:

Again, this only matters if you place a great deal of importance both on the 
notion that size equals fairness, and that fairness is more important than 
efficiency.
...

I think the point is here that networks are nudging these decisions by making 
certain services suck more than others by way of preferential network access.

I agree completely that that's the problem.  But it didn't appear to be what 
Benson was talking about.



It's clear to me that you don't understand what I've said. But whether 
you're being obtuse or simply disagreeing, there is little value in 
repeating my specific points. Instead, in hope of encouraging useful 
discussion, I'll try to step back and describe things more broadly.


The behaviors of networks are driven (in almost all cases) by the needs 
of business. In other words, decisions about peering, performance, etc, 
are all driven by a P&L sheet.


So, clearly, these networks will try to minimize their costs (whether 
"fair" or not). And any imbalance between peers' cost burdens is an easy 
target. If one peer's routing behavior forces the other to carry more 
traffic a farther distance, then there is likely to be a dispute at some 
point - contrary to some hand-wave comments, carrying multiple gigs of 
traffic across the continent does have a meaningful cost, and pushing 
that cost onto somebody else is good for business.


This is where so-called "bit mile peering" agreements can help - 
neutralize arguments about balance in order to focus on what matters. Of 
course there is still the "P" side of a P&L sheet to consider, and 
networks will surely attempt to capture some of the success of their 
peers' business models. But take away the legitimate "fairness" excuses 
and we can see the real issue in these cases.


Not that we have built the best (standard, interoperable, cheap) tools 
to make bit-mile peering possible... But that's a good conversation to have.


Cheers,
-Benson

Re: net neutrality and peering wars continue

[Benson Schliesser]

On Jun 19, 2013, at 23:41, "Siegel, David"  wrote:

> Well, with net flow Analytics, it's not really the case that we don't have a 
> way of evaluating the relative burdens.  Every major net flow Analytics 
> vendor is implementing some type of distance measurement capability so that 
> each party can calculate not only how much traffic they carry for each peer, 
> but how far.

Admittedly, it's been a few years since I looked at such tools... So
please help me understand: does the tool evaluate distance (and
therefore burden) as it extends into the peer's network, or just into
the local network? And in either case, is this kind of data normalized
and shared between peers? It seems like there could be a mechanism
here to evaluate fairness of burdens, but I'm skeptical that these
tools are used in such a way. I'd be glad to be incorrect. ;)

Cheers,
-Benson

Re: net neutrality and peering wars continue

[Benson Schliesser]

On Jun 20, 2013, at 8:09, Martin Barry  wrote:

> On 20 June 2013 13:07, Bill Woodcock  wrote:
>
>> On Jun 19, 2013, at 7:21 PM, Benson Schliesser 
>> wrote:
>>> The sending peer (or their customer) has more control over cost.
>>
>> I'll assume that, by "sending peer," you mean the content network.  If so,
>> I disagree.  The content network has no control whatsoever over the
>> location of the eyeball customer.
>> ...
> I think his point was that the receiving side can massage their BGP
> announcements all they like but the sending network has more instantaneous
> control over how the traffic will flow. This is before analysis,
> communication, application of policies / contractual arrangements,
> de-peering etc.etc. kick in.

Right. By "sending peer" I meant the network transmitting a packet,
unidirectional flow, or other aggregate of traffic into another
network. I'm not assuming anything about whether they are offering
"content" or something else - I think it would be better to talk about
peering fairness at the network layer, rather than the business /
service layer.

Cheers,
-Benson

Re: net neutrality and peering wars continue

[Benson Schliesser]

On 2013-06-19 8:46 PM, Leo Bicknell wrote:


That was a great argument in 1993, and was in fact largely true in system that 
existed at that time.  However today what you describe no longer really makes 
any sense.

While it is technically true that the protocols favor asymmetric routing, your 
theory is based on the idea that a content site exists in one location, and 
does not want to optimize the user experience.
...

A much better business arrangement would be to tie a sliding fee to the ratio.  
Peering up to 2:1 is free.  Up to 4:1 is $0.50/meg, up to 6:1 is $1.00/meg, up 
to 10:1 is $1.50 a meg.  Eyeball network gets to recover their long haul 
transport costs, it's cheaper to the CDN than buying transit,


Agreed that CDN, traffic steering, etc, changes the impact of routing 
protocols. But I think you made my point. The sending peer (or their 
customer) has more control over cost. And we don't really have a good 
proxy for evaluating relative burdens.


That's not to suggest that peering disputes are really about technical 
capabilities. Nor fairness, even...


Cheers,
-Benson

Re: net neutrality and peering wars continue

[Benson Schliesser]

On 2013-06-19 7:03 PM, Randy Bush wrote:
as someone who does not really buy the balanced traffic story, some 
are eyeballs and some are eye candy and that's just life, seems like a 
lot of words to justify various attempts at control, higgenbottom's 
point. randy 


What do you mean "not really buy the balanced traffic story"? Ratio can 
matter when routing is asymmetric. (If costs can be approximated as 
distance x volume, forwarding hot-potato places a higher burden on the 
recipient...) And we've basically designed protocols that route 
asymmetrically by default. Measuring traffic ratios is the laziest 
solution to this problem, and thus the one we should've expected.


Cheers,
-Benson

Re: shared address space... a reality!

[Benson Schliesser]

I'm sure it happened much sooner than 72 hours post allocation. In fact, there 
were probably folks already squatting on that space long before any of this. 
Maybe their life just got a little easier. :)

Cheers,
-Benson


On Mar 15, 2012, at 3:57 PM, Robert E. Seastrom wrote:

> 
> More like "wasting no time in fulfilling the prophesy that people will
> treat it like just another rfc1918 space and deploy it wherever they want".
> 
> not that randy is likely to get bitten because he's not behind a cgn
> nor is he planning to be, but still, that took all of what, 72 hours?
> 
> -r
> 
> George Herbert  writes:
> 
>> What, senior network people testing out new test/transitional space at
>> home before they test it at work is bad?
>> 
>> On Thu, Mar 15, 2012 at 6:26 AM, Jérôme Nicolle  wrote:
>>> Le 15/03/12 07:59, Randy Bush a écrit :
 and i have configured two home LANs to use it
>>> 
>>> So wrong...
>>> 
>>> --
>>> Jérôme Nicolle
>>> 
>> 
>> 
>> 
>> -- 
>> -george william herbert
>> george.herb...@gmail.com
> 

Re: Sad IPv4 story?

[Benson Schliesser]

On Dec 9, 2011, at 2:57 PM, Mark Blackman wrote:
>> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:
>>> We're going to be hearing a lot more of these. It's the nature of finite 
>>> resources, and of human nature when faced with them. At some point, this 
>>> will find its way into courtrooms under the rubric of a barrier to entry. 
>>> It already has in terms of antitrust when a company wanted to move its PA 
>>> prefix to different upstream.
> 
> I've had transit service pulled, so the provider can reclaim the /21 that was 
> bundled with the transit.

I'm sorry to hear about that...  Do you know why they reclaimed the block?  
E.g. was it used to support a "higher margin" service for another customer?

-Benson

Re: Sad IPv4 story?

[Benson Schliesser]

On Dec 9, 2011, at 1:07 PM, Fred Baker wrote:

> On Dec 9, 2011, at 10:37 AM, Franck Martin wrote:
> 
>> I just had a personal email from a brand new ISP in the Asia-Pacific area 
>> desperately looking for enough IPv4 to be able to run their business the way 
>> they would like…
>> 
>> This is just a data point.
> 
> We're going to be hearing a lot more of these. It's the nature of finite 
> resources, and of human nature when faced with them. At some point, this will 
> find its way into courtrooms under the rubric of a barrier to entry. It 
> already has in terms of antitrust when a company wanted to move its PA prefix 
> to different upstream.

+1 to Fred's comments.  Hopefully, the existence of an open IPv4 address market 
will help avoid some of the worst.  (At least for a while, until the rising 
prices get too high for a competitive environment.  And maybe by then the price 
of IPv4 addresses will have made IPv6 deployment a much more obvious choice to 
reluctant CFO-types.)

Cheers,
-Benson

---
Disclaimers:
1. I am not a lawyer, and nothing in this message should be construed as advice.
2. I, Benson Schliesser, am an employee of Cisco Systems; however, opinions 
expressed in this email are my own views and not those of Cisco Systems or 
anybody else.

Re: IP addresses are now assets

[Benson Schliesser]

It's hard to sustain that kind of commitment... so we need to form a Humor 
Advisory Committee. Their job would be to determine which behaviors the 
community finds most humorous. When the community doesn't produce enough 
material, the comedy HAC would write jokes on our behalf (for adoption by John 
following legal assessment, board approval, etc).

Cheers,
-Benson


On Dec 3, 2011, at 2:26 PM, Gary Buhrmaster wrote:

> On Fri, Dec 2, 2011 at 20:01,   wrote:
> .
>> 
>> Suggestion received and needing confirmation:
>> 
>> That ARIN or a party it designates assign one or more sense(s) of humour to 
>> the CEO.
>> 
> 
> I believe this suggestion suffers from being too non-specific,
> and could lead to unintended consequences.  ARIN could,
> for example, assign John a slapstick comedy sense of humor
> and all the chairs at the next meeting would have a whoopee
> cushion.  And do you really want John taking on the role
> of a Don Rickles as an insult comedian?
> 
> And, of course 87% percentage of the population believes
> that they already have an above average sense of humor
> (and 62% of the population believes any statement with
> a statistic in it).
> 
> I would recommend that this suggestion be revised
> with community input into what type of humor can
> achieve a community consensus.
> 
> Gary
> 

Re: Botnets buying up IPv4 address space

[Benson Schliesser]

The important outcome is that transfers are documented. Making it easier for 
sellers to update Whois (so it points to the buyer) will encourage 
documentation.  If "needs justification" is ever a disincentive to update 
Whois, then it will discourage documentation.

Granted, a seller that doesn't update Whois should be more worried about the 
reputation of the buyer. But regardless, it is incorrect to assume that "needs 
justification" will prevent bad actors from acquiring address blocks. Even bad 
actors can justify their need, and some of them might even (*gasp*) lie about 
it in order to get what they want. The result would look like a normal transfer 
(with justified need, a Whois update, etc) and yet would result in a bad actor 
becoming an address holder.

Cheers,
-Benson


On Oct 7, 2011, at 6:08 PM, Jimmy Hess wrote:

> On Fri, Oct 7, 2011 at 1:11 PM, Joly MacFie  wrote:
>> I'd welcome comments as to solutions to this. Or is it just scaremongering?
> Probably scaremongering... but it does raise an interesting thought.
> 
> It provides another argument why RIRs don't need to abandon justified
> need as a mandatory
> criteria for transferring addresses to specified recipients out of
> fear that  legacy and other
> holders will engage in "unofficial" sales and transfers that they
> intentionally fail to record via WHOIS.
> 
> The legacy holder/unofficial transferror would be putting the
> reputation of their entire address block,
> and their other allocations at risk;  if the buyer eventually hands
> some of the unofficial allocation
> to a spammer, either by accident, or intentionally, doesn't matter.
> 
> The holder of addresses that unofficially transferred them, could have
> some major headaches,
> including service-affecting headaches to their network...  just to
> sell  spare IP addresses faster for
> a few extra bucks;   when there is a legitimate process available
> that doesn't have that risk?
> 
>> j
> --
> -JH
> 

Re: Botnets buying up IPv4 address space

[Benson Schliesser]

On Oct 7, 2011, at 1:31 PM, Arturo Servin wrote:

>   What do you mean with "purchasing or renting IPv4".
> 
>   Last time that I check it was not possible in the RIR world.

Nevertheless, it is possible in the real world.

> On 7 Oct 2011, at 15:11, Joly MacFie wrote:
> 
>> I'd welcome comments as to solutions to this. Or is it just scaremongering?
>> ...
>> Botnets buying up IPv4 address space
>> 
>> http://j.mp/nMJ5Lr  (Threat Post)

Domain names, IP addresses, network connectivity, etc - all of these are 
resources that people can acquire, (mis)use, and replace.  The fact that 
reputation systems often conflate people and their (impermanent) resources is 
unfortunate, and is the source of much operational pain.

I don't see anything new in the article, and would classify parts of it as 
scaremongering. (e.g. the criticism of IPv6)

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

Hi, Paul.

On Sep 22, 2011, at 8:03 PM, Paul Vixie wrote:

>> My understanding is that the NomCom consists of 7 people. Of those, 2
>> come from the board and 2 come from the AC. Together, those 4 members of
>> the existing establishment choose the remaining 3 NomCom members. In the
>> past, there was at least the appearance of random selection for some of
>> the NomCom members. But in any case, due to its composition, the NomCom
>> has the appearance of a body biased in favor of the existing
>> establishment.
>> 
>> Please correct any misunderstanding that I might have. Otherwise, I
>> encourage an update to the structure of future NomComs.
> 
> can you explain what it was about prior nomcoms that gave the appearance
> of random selection?  to the best of my knowledge, including knowledge i
> gained as chair of the 2008 ARIN NomCom, we've been doing it the same way
> for quite a while now.  so i do not understand your reference to "at least
> the appearance of random selection" in the past.

Earlier this year I received the following from ARIN member services:  "This 
year the NomCom charter was changed by the Board.  In the past the 3 Member 
volunteers were selected at random.  This year the 3 volunteers will be chosen 
by the 4 current members of the NomCom (2 from the Board 2 from the AC)"

The above quote was sent to me in response to a query I made, inquiring how the 
NomCom would be chosen in 2011.  It is consistent with what I was told in 2010, 
when I was chosen to be part of the 2010 NomCom.  At that time I was told that 
Member volunteers were chosen randomly.  During my NomCom tenure, however, it 
was suggested to me privately that there was very little randomness involved in 
the selection process; I was told that individuals were specifically chosen for 
NomCom.  I don't know what to make of this disparity, honestly, which is why I 
referenced "the appearance of random selection".

> since ARIN members-in-good-standing elect the board and advisory council,
> and also make up three of the four seats of the nominations committee, i
> do not share your view on "bias" as expressed above.  i think it shows
> that ARIN is clearly governed by its members -- which is as it should be.
> 
> by your two references to "the existing establishment" do you intend to
> imply that ARIN's members don't currently have the establishment that they
> want, or that they could not change this establishment if they wanted to,
> or that ARIN's members are themselves part of "the existing establishment"
> in some way that's bad?

The NomCom acts as a filter, of sorts.  It chooses the candidates that the 
membership will see.  The fact that the NomCom is so closely coupled with the 
existing leadership has an unfortunate appearance that suggests a bias.  I'm 
unable to say whether the bias exists, is recognized, and/or is reflected in 
the slate of candidates.  But it seems like an easy enough thing to avoid.

As for my use of "existing establishment":  I'm of the impression that a 
relatively small group of individuals drive ARIN, that most ARIN members don't 
actively participate.  I have my own opinions on why this is, but they aren't 
worth elaborating at this time - in fact, I suspect many ARIN members here on 
NANOG can speak for themselves if they wanted to.  In any case, this is just my 
impression.  If you would rather share some statistics on member participation, 
election fairness, etc, then such facts might be more useful.

> ARIN's bylaws firmly place control of ARIN into the hands of its members.
> if you think that's the wrong approach, i'm curious to hear your reasoning
> and your proposed alternative.

One of ARIN's governance strengths is the availability of petition at many 
steps, including for candidates rejected by the NomCom.  Likewise, as you 
noted, leaders are elected by the membership.  For these reasons I previously 
noted that "ARIN has a pretty good governance structure" and I continue to 
think so.  It could be improved by increased member involvement, as well as 
broader involvement from the community. (For instance, policy petitions should 
include responses from the entire affected community, not just PPML.)  But my 
criticisms should be interpreted as constructive, and are not an indictment of 
the whole approach.

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

Hi, Paul.

On Sep 20, 2011, at 11:43, Paul Vixie  wrote:

> Benson Schliesser  writes:
> 
>> For what it's worth, I agree that ARIN has a pretty good governance
>> structure. (With the exception of NomCom this year, which is shamefully
>> unbalanced.) ...
> 
> as the chairman of the 2011 ARIN NomCom, i hope you'll explain further,
> either publically here, or privately, as you prefer.

My understanding is that the NomCom consists of 7 people. Of those, 2 come from 
the board and 2 come from the AC. Together, those 4 members of the existing 
establishment choose the remaining 3 NomCom members. In the past, there was at 
least the appearance of random selection for some of the NomCom members. But in 
any case, due to its composition, the NomCom has the appearance of a body 
biased in favor of the existing establishment.

Please correct any misunderstanding that I might have. Otherwise, I encourage 
an update to the structure of future NomComs.

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

On Sep 18, 2011, at 21:20, John Curran  wrote:

> On Sep 18, 2011, at 2:53 PM, Benson Schliesser wrote:
>> 
>> In John's case (on behalf of ARIN as is befitting his role) he welcomes 
>> change as long as it's funneled through the ARIN-managed channels.  In other 
>> words, change is welcome as long as it reinforces ARIN's role as 
>> facilitator.  
> 
> ...  ...

For what it's worth, I agree that ARIN has a pretty good governance structure. 
(With the exception of NomCom this year, which is shamefully unbalanced.) That 
hasn't stopped it from becoming an ideological anachronism. Or from becoming 
interested in self-preservation. It's only natural for such organizations. 

And despite this, I do encourage folks here to participate in PPML. It's the 
only way ARIN will get more perspective. (Though, admittedly it is a bit like 
banging ones own head against the wall...)

> However, your statement that I only welcome change funneled through 
> "ARIN-managed channels" is incorrect, as I have made it quite plain 
> on multiple occasions that the structure of the Internet number 
> registry system itself is not necessarily a discussion that should
> be held within the existing structure (e.g. RIRs and ICANN), but might 
> also be appropriately held external to the existing structure (such as 
> by operator forums or the Internet Governance Forum).

Are you suggesting that ARIN policy or procedure might change as a direct 
result of discussion in e.g. IGF? Or perhaps here on NANOG?

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

On Sep 18, 2011, at 15:51, Randy Bush  wrote:

>> I'm told of others that have bought legacy IPv4 prefixes with no
>> intention of updating whois at this time - no desire to enter into a
>> relationship with ARIN and be subjected to existing "policy", for
>> instance.
> 
> so your point is that your friends at depository.com will be attractive
> to ip address space buyers because they will offer a less religious rsa.
> and the question is whether the ops community will believe their whois
> and install a separate rpki trust root for them?

For instance, yes.

I'm also wondering if the ops community will accept other sources of proof such 
as legal documents (or something else?), in lieu of Whois records from an RIR, 
Depository, or elsewhere. 

> could be.  but i would not want to have that as my business plan.
> 
> randy, who is all for a less religious rsa

You wouldn't bet on ARIN being religious for the foreseeable future? ;) Or, you 
wouldn't bet on the ops community embracing alternatives?

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

On Sep 18, 2011, at 3:09 PM, Randy Bush wrote:

>> IPv4 trading is already taking place, what are you (as operators)
>> planning to do when asked to route prefixes that have been
>> bought/sold?  Will you accept alternative (whois) registry sources?
> 
> why the heck should i have to?  the iana and the frelling rirs' one
> principal task is to register.  if they do not register transfers then
> what are we all smoking?

I don't disagree...

>  and, as far as i know, they are registering
> transfers from sale of ip assets.


Apparently true for some.  But I'm told of others that have bought legacy IPv4 
prefixes with no intention of updating whois at this time - no desire to enter 
into a relationship with ARIN and be subjected to existing "policy", for 
instance.  I can't speak for their rationale beyond this.  But I do believe 
that several of them will try to get their prefix routed, at some point.

Cheers,
-Benson

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Benson Schliesser]

On Sep 18, 2011, at 10:49 AM, Randy Bush wrote:
> i just think that we, as a culture, have let things get wy out of
> whack.  john is paid to defend the status grow.


I like that: "status grow".  It seems pretty clear to me that, as humans, we're 
not very good at organizational contraction.  We're much better at expanding 
scope, even until it produces undesirable consequences.  Competition is a 
friend in such scenarios, when it's allowed...  As are revolutions, when 
competition is not allowed.

In John's case (on behalf of ARIN as is befitting his role) he welcomes change 
as long as it's funneled through the ARIN-managed channels.  In other words, 
change is welcome as long as it reinforces ARIN's role as facilitator.  
Unfortunately, the gauntlet of "policy weenies" that influence ARIN don't 
necessarily represent the "community" as they might claim - they represent 
themselves, their ideologies, etc.  So if you want the ARIN system to change, 
it's your choice whether to engage within that system or outside it.  Neither 
seems very useful to me; we can just ignore ARIN as alternatives emerge, and 
ARIN can catch up or not.

Which, astoundingly, leads to an operational comment / question:  As IPv4 
trading is already taking place, what are you (as operators) planning to do 
when asked to route prefixes that have been bought/sold?  Will you accept 
alternative (whois) registry sources?  Will you accept legal documentation 
proving ownership and/or right-to-use, as an alternative to registry validation?

Cheers,
-Benson

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Benson Schliesser]

On Jul 11, 2011, at 7:19 PM, Jeff Wheeler wrote:

> Again, this is only hard to understand (or accept) if you don't know
> how your routers work.
> * why do you think there is an ARP and ND table?
> * why do you think there are policers to protect the CPU from
> excessive ARP/ND punts or traffic?
> * do you even know the limit of your boxes' ARP / ND tables?  Do you
> realize that limit is a tiny fraction of one /64?
> * do you understand what happens when your ARP/ND policers are reached?
> * did you think about the impact on neighboring routers and protocol
> next-hops, not just servers?
> * did you every try to deploy a /16 on a flat LAN with a lot of hosts
> and see what happens?  Doesn't work too well.  A v6 /64 is 281
> trillion times bigger than a v4 /16.  There's no big leap of logic
> here as to why one rogue machine could break your LAN.

FYI, in case you're interested in these topics, the IETF working group ARMD was 
chartered to explore address resolution scale.  I'm one of the co-chairs.  It's 
in the Operations Area, and we'd love to have more operators involved - if 
you're willing to contribute, your input will help set the direction.  (If 
operators don't contribute, it will be just another vendor-led circle... well, 
you know the score.)

For details please see http://tools.ietf.org/wg/armd/charters.

Cheers,
-Benson

Re: ICANN to allow commercial gTLDs

[Benson Schliesser]

On Jun 17, 2011, at 4:21 PM, David Conrad wrote:

> On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote:
>> Aw, Jeezus.
>> 
>> No.  Just, no.
>> 
>> http://tech.slashdot.org/story/11/06/17/202245/
> 
> You just learned about this now?

On a related topic, the US DoJ recently wrote a letter suggesting that DNS 
registry/registrar vertical integration might not be a good idea (from an 
anti-trust perspective).

http://www.icann.org/en/correspondence/strickling-to-dengate-thrush-16jun11-en.pdf

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 19, 2011, at 4:26 PM, Jeff Wheeler wrote:

> I don't think the cost of IPv4 addresses has anywhere to go but up.
> This mysterious Nortel/Microsoft transaction would seem to give
> credibility to an assumption of increasing cost.

I think we can agree on this.  It is the natural result of exhaustion - scarce 
supply, ongoing demand.

It is important to note, however, that this is orthogonal to the registry 
management structure; we could have increased IPv4 acquisition costs with ARIN, 
or increased IPv4 acquisition costs with somebody else.

>  Therefore, it stands
> to reason that the cost of "database services" associated with being a
> holder of IP addresses will be inconsequential.
...
> If anyone thinks that won't be true for IP addresses, by all means,
> let that person propose to overhaul the IN-ADDR system and possibly
> the WHOIS database.  I do not think stakeholders will agree with their
> views.  IP addresses are finite, and the cost of acquiring them will,
> in all likelihood, dwarf the cost of publishing ownership/custodial
> information or operational DNS records.


As I agreed above, acquisition costs will go up regardless.  The real question 
is total cost, which is (basically) the acquisition price plus the ongoing 
registry maintenance costs.

As one possibility, an overhaul might result in less expensive (or even "free") 
registry services being provided by brokers.  Assuming market prices aren't 
affected by the overhaul, the total cost might thus be lower with a broker 
versus ARIN.  Perhaps this is a small impact, but it's real.

More importantly, an overhaul to the registry system that facilitates liquidity 
in the market may introduce additional benefits.  (e.g. more predictable and/or 
lower acquisition costs)  I'm not an economist and I'm open to contrary 
arguments, but I see potential upsides to an overhaul that don't exist with the 
status quo.

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 19, 2011, at 3:46 PM, Jeff Wheeler wrote:

> On Tue, Apr 19, 2011 at 4:14 PM, Benson Schliesser
>  wrote:
>> Meanwhile, under the current system, ARIN has managed to accumulate a >$25M 
>> cash reserve despite an increasing budget. (see 
>> https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf)
> ...
> Is your problem that ARIN spends its money poorly?  I believe it does
> in some ways, but the community generally does not care enough to try
> to improve this.  I questioned ARIN's travel budget a few years ago
> and was essentially flamed for doing so.

I might agree that ARIN wastes money, but that wasn't my point.  The context of 
my comment was your original message, which argued that a competitive registry 
system would enable vendors to "over-charge".  Without defining what an optimal 
cost might be, my comment was intended to show that our current baseline 
already results in a surplus.  And I agree with DRC's comment that competition 
might improve / optimize costs, rather than inflate them.

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 19, 2011, at 2:56 PM, David Conrad wrote:

> On Apr 19, 2011, at 10:19 AM, Jeff Wheeler wrote:
>> Are you saying there are people who advocate creating a new ecosystem
>> of service providers for supplying several things that the RIRs
>> exclusively supply today?
> 
> Yes.
> 
>> Sign me up.  As a vendor.  I'd love to over-charge for the dead simple
>> task of using an API to push DNS delegation updates to the IN-ADDR
>> servers, and running a whois server.
> 
> My guess is that lacking a monopoly, if you over-charge you won't have many 
> customers.

Meanwhile, under the current system, ARIN has managed to accumulate a >$25M 
cash reserve despite an increasing budget. (see 
https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf)

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 18, 2011, at 10:08 PM, Randy Bush wrote:

>> If anybody has any doubts and/or I can clarify anything about my
>> interests, let me know.
> 
> could you please clarify your relationship to depository.com?

I know some of the people involved in Depository, and I have spoken with them 
about what they're trying to do.  I might go so far as to call some of them 
friends.  But to my knowledge I have no formal relationship with Depository or 
any affiliated company.

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

Hi, Randy.

On Apr 18, 2011, at 9:20 PM, Randy Bush wrote:

>> I introduced several policy proposals to ARIN that deal with the
>> question of authority and ownership.
>> ...
>> If anybody on NANOG supports these concepts, please express your
>> support to PPML so that the proposals can move forward.
> 
> perhaps, if you are seeking support for commercial activity, you should
> make your employment more clear and declare any conflicts of interest.

Fair enough.

I am employed by Cisco Systems, but all of my statements are my own and I do 
not represent my employer.  I believe that my employer may benefit from any 
policy that makes IP addresses more available to more of our customers - we can 
perhaps sell more routers if more people have addresses - but nobody from Cisco 
has encouraged me to work in this topic.  Otherwise, I have no commercial 
interest in the outcome of the policy proposals that I've made.  The proposals 
that I've put forward are an honest attempt to motivate conversation.

If anybody has any doubts and/or I can clarify anything about my interests, let 
me know.

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 18, 2011, at 6:33 PM, David Conrad wrote:

> As far as I can tell, the participants in ARIN's processes are more 
> interested in trying to be a regulator than in being a registry. Given ARIN 
> is not a government body and it does not have full buy-in from those who they 
> would try to regulate, I suspect this will directly result in a proliferation 
> of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure 
> this will have negative repercussions for network operations (unless someone 
> steps in and provides a definitive "address titles registry").

I agree completely with this concern.  Against good advice of friends (who said 
I would be wasting my time), I tried to do something about it:  I introduced 
several policy proposals to ARIN that deal with the question of authority and 
ownership.

At John Curran's advice, the ARIN Advisory Council abandoned my proposals.  Two 
of them are now in "petition" for further discussion, including ARIN-prop-134 
which outlines how to identify a "legitimate address holder" and ARIN-prop-136 
which allows a Legacy holder to "opt-out" of ARIN's services.  The idea is to 
make it possible for legacy holders (who don't have a contract with ARIN) to 
disarm ARIN's whois weapon.

If anybody on NANOG supports these concepts, please express your support to 
PPML so that the proposals can move forward.

Please see these links for more info:

> http://lists.arin.net/pipermail/arin-ppml/2011-April/020604.html

> http://lists.arin.net/pipermail/arin-ppml/2011-April/020605.html

Cheers,
-Benson

Re: IPv4 address exchange

[Benson Schliesser]

On Apr 18, 2011, at 6:33 PM, David Conrad wrote:

> Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that 
> according to the court documents I've seen,

John Curran has stated unambiguously (on the ARIN PPML mailing list) that NRPM 
policy *was* followed.  While I may disagree, at present I'm rather focused on 
understanding how he interprets and implements this policy.  Here are my 
understandings at this time:

> Microsoft appears to have signed an LRSA (not an RSA as would seem to be 
> required by the NPRM and as mentioned on ARIN's press release)

Court documents show that "a LRSA" has been agreed rather than "the RSA".  As 
you point out, the actual text of NRPM requires RSA.  Thus I assume that ARIN 
staff procedure will accept any form of RSA as satisfying this requirement, 
including the standard LRSA or a negotiated LRSA.

(This latter possibility makes me wonder about what MSFT actually agreed to, in 
their version of the LRSA, and whether it will be fairly offered to all 
parties...)

> and there doesn't appear to be anything suggesting Nortel entered into any 
> agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too 
> closely)?

The court documents do not indicate that Nortel has agreed anything with ARIN.  
This brings to question, how were the blocks "released" to ARIN for transfer?  
In answer, John Curran has stated that the court filings satisfy this 
requirement without any further agreement with Nortel.  Thus I assume that ARIN 
will accept any legal document confirming ownership and the desire to transfer.

There is another aspect of NRPM 8.3 (specified transfer policy) that appears, 
to an outside observer, to have been ignored by this Nortel/Microsoft transfer: 
needs justification.  However, John Curran has stated that it did occur.  
Somehow, according to him, Microsoft has demonstrated a need for 666,624 IPv4 
addresses in the form of the exact block(s) that are being transferred.  (For 
what it's worth, I think "needs justification" is bad policy for a market. My 
only concern here is whether ARIN follows community developed policy, as John 
says they have.)

Cheers,
-Benson

Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million

[Benson Schliesser]

On Mar 24, 2011, at 9:59 PM, Jimmy Hess wrote:

> So I wonder  rhetorically speaking.. what happens when a bankruptcy
> court accidentally sells something that doesn't actually exist,
> ...
> Because that's what IP addresses are.  Totally worthless unless community
> participants voluntarily route traffic for those IPs to the assignee.

There are a small number of examples, of intellectual property that exists 
solely by convention and yet has value.  But you're correct: the property 
structure of IP addresses is ambiguous.  We never had to define it because we 
had free supply, but times are changing.

> Meaning if MS has an RSA in force, all their resources should be compliant
> with ARIN policies,  and all transfer policies should be followed with regards
> to justified need.

If I recall correctly, the ARIN RSA only applies to resources acquired from 
ARIN.  It's a contract for ARIN services and doesn't cover legacy blocks, 
blocks from other RIRs, etc - it doesn't automatically extend ARIN's authority.

On Mar 24, 2011, at 10:34 PM, Marshall Eubanks wrote:

> If ARIN reassigned the space, and Microsoft continued to announce it anyway, 
> would either announcing entity be have enough of a critical mass
> that the conflict wouldn't matter to it  ? 
> 
> I would submit that any address assignments with continual major operational 
> issues arising from assignment conflicts would not be very attractive.  
> 
> I also don't think that that would be good for the Internet. 

I agree.  Which is why ARIN should keep their Whois updated with accurate data, 
rather than fighting for control of resources beyond RSA scope.

Cheers,
-Benson

Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million

[Benson Schliesser]

Hi, John.

On Mar 24, 2011, at 10:35 AM, John Curran wrote:
>> http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html
> 
> Read the comment at the end (attached here for reference).
>> Did you have an opportunity to review the actual docket materials, or is 
>> your "coverage" based just on your review of the referenced article? 
>> 
>> The parties have requested approval of a sale order from the Bankruptcy 
>> judge. There is a timeline for making filings and a hearing date. There is 
>> not an approved sale order at this time, contrary to your blog entry title. 
>> 
>> ARIN has a responsibility to make clear the community-developed policies by 
>> which we maintain the ARIN Whois database, and any actual transfer of number 
>> resources in compliance with such policies will be reflected in the 
>> database. 

At your suggestion, I went to the IGP blog and read the last comment.  I see 
there is a response by Ernie Rubi to your blog comment, which captures my 
question so well that (with apologies to Mr Rubi) I'll quote him:

"1) a non-party to a bankruptcy proceeding can intervene in a purported asset 
sale during said proceeding if they have an interest (i.e property-type) in the 
asset.  2) ARIN's position is that there is no property interest in IP 
addresses (LRSA, RSA, etc)."

I would add that ARIN, as a non-profit business league, has no statutory or 
regulatory authority in this matter.

It's obvious that ARIN, as well as other whois database providers, should pay 
attention to the proceedings.  But under what premise might ARIN act as a party 
to this lawsuit?

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 22, 2011, at 6:29 PM, Randy Bush wrote:

 There seems to be a position, taken by others on these lists, that
 IPv6 is the only address family that matters.  Interestingly, this
 position seems to be most pronounced from people not involved in
 operating production networks.
>>> 
>>> excuse me!
>> 
>> Hi, Randy.  I didn't mean to deny you exist; you apparently do. ;) But
>> in my sampling, operators
> 
> benson,
> 
> vendors saying what operators want went *seriously* out of fashion a
> couple of years back.  we can speak for ourselves, tyvm.

I agree completely.  I'm responding to what I've heard from operators.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 22, 2011, at 4:42 PM, Tony Hain wrote:

> Seriously, some people will not move until the path they are on is already
> burning, which is why they did nothing over the last 5 years despite knowing
> that the IANA pool was exhausting much faster than they had wanted to
> believe. It took getting within months of exhausting the IANA pool before
> the crowd woke up and noticed the path was on fire. Now you want 'just a
> little more'... after which it will be 'just a little more'.

This won't go on forever.  The "price" of IPv4 has been kept artificially low 
for the past decade, through a RIR-based system of rationing.  There was never 
an immediate incentive to migrate.  If we really wanted to motivate people 
before they reached the precipice, we should have increasingly raised the cost 
of an IPv4 address.

Now, IPv4 exhaustion has effectively raised that cost for us, and people are 
motivated to migrate to IPv6.  But since we didn't force this situation sooner, 
we now also have to deal with the effects of exhaustion.  That's all I'm 
talking about.  IPv4 hacks will not be better or cheaper than IPv6, and they're 
nothing to fear in terms of IPv6 adoption.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 22, 2011, at 3:40 AM, Owen DeLong wrote:

>> There seems to be a position, taken by others on these lists, that IPv6 is 
>> the only address family that matters.  Interestingly, this position seems to 
>> be most pronounced from people not involved in operating production 
>> networks.  But, regardless, if I were to accept this position then I might 
>> also agree that it doesn't matter whether or not draft-donley-nat444-impacts 
>> is misleading.
>> 
> I don't think anyone has said that IPv6 is the only address family
> that matters. What I think people, myself included, have been saying
> is that IPv6 is the only way forward that does not involve many of these
> problems. (See my earlier Titanic post).

I agree completely: IPv6 is the only way forward that avoids these problems.  
In fact, an understanding of CGN impacts should be enough motivation for 
operators and users to start deploying IPv6 immediately.

> As to whether or not it matters that people misinterpred draft-donly...,
> I'm not sure whether it actually does or not. There is no flavor of NAT
> that is particularly desirable. It's a matter of choosing the one that is
> least damaging to your environment where least damage may
> boil down to a choice between 5% and 3% remaining functionality.

I agree with your sentiment, that we should choose the least damaging 
solutions.  Call it the "lesser evil" if you'd like.

However, I think your estimates (5% vs 3%) are backwards.  CGN-based solutions 
work for the vast majority of network traffic today - it's the stuff in the 
margin that breaks, according to all test reports I've seen.

> I don't think anyone is saying IPv4 no longer matters. I think we are
> saying that effort spent attempting to make the deteriorating IPv4
> situation deteriorate less is both futile and better spent on making
> the IPv6 deployment situation better.

It's not an exclusive situation - we can roll out IPv6 while continuing to 
maintain our existing IPv4 connectivity, support new customers with IPv4 needs, 
etc.  As I mentioned before, we have to support the bridge we're crossing 
(crumbling IPv4 infrastructure) until we're on the other side (fertile IPv6 
farmland).

>> Of course, we can also rely on an IPv4 address market to avoid NAT in the 
>> more sensitive situations (i.e. situations with more sensitive users).  But 
>> that's a different conversation.
>> 
> Only if you expect that you can rely on a supply side in such a market.
> I am unconvinced that such will be reliable, especially after about 6
> months of trading. This also presumes that more sensitive users can
> be defined in terms of what those users are willing (or able) to pay.

This is an interesting discussion, because the timeframe is central to 
everything I've commented above.

Considering RIR exhaustion (4-12 months) plus ISP exhaustion (TBD, but let's 
say anywhere from 1 month to 5+ years after RIR exhaustion), I expect some 
network providers to struggle with IPv4 address exhaustion before the 3rd 
quarter of 2011.  On the other hand, other network providers will have enough 
resources to last for years - let's call that "excess supply".

By all realistic estimates, any network provider that hasn't deployed IPv6 
support into their infrastructure will need anywhere from 3 months to 3 years 
or more - let's generously say around 18 months to the point where 60% - 80% of 
hosts have reached IPv6 connectivity.  Just considering these facts, I think we 
can see why some ISPs might be interested in acquiring more addresses through 
2012.  And those with excess supply might be motivated (financially) by a 
marketplace to share their resources, to meet this need.

Further, let's consider that some network services (such as content / hosting) 
will need IPv4 connectivity longer than others, in order to reach the 
long-tail.  For this category, I can see why some networks might be interested 
in acquiring more addresses through 2013 - 2016.  Fortunately, on the other 
side of 2012 prices should decrease because supply goes up (as some people give 
up IPv4).  Thus the market value of an address probably can be represented by a 
curve peaking in a couple years and then declining to zero a few years after 
that.

Feedback on this would be appreciated - but my current belief is that it's 
realistic to plan for a couple years of trading rather than "about 6 months".

(Side note: If we really wanted people to move to IPv6 before now, we should 
have instituted increasing prices for RIR-provided addresses. I posit that we 
just didn't have the collective balls to do this.)

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 22, 2011, at 3:54 PM, valdis.kletni...@vt.edu wrote:

> On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said:
>> There seems to be a position, taken by others on these lists, that IPv6
>> is the only address family that matters.  Interestingly, this position
>> seems to be most pronounced from people not involved in operating
>> production networks.
> 
> "most pronounced from people not involved in operating production networks
> that are way behind the planning curve for IPv6 deployment".
> 
> There, fixed that for you.

My original text remains true, because I tend to hear IPv6-only advocacy from 
vendors and policy folks more than operators - even more so versus operators of 
commercial ISP networks.  But I take your point, that operators ahead of the 
IPv6 deployment curve are most likely to stand up with that opinion.

Of course, the "network effect" being what it is...  Your network being 100% 
IPv6 doesn't solve the overall problem of reachability.  I think your example 
of 4% traffic from VT is applicable - you will have to worry about IPv4 
connectivity, in one form or another, until it diminishes significantly.  It's 
a bit like a tragedy of the commons.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 22, 2011, at 3:14 AM, Randy Bush wrote:

>> There seems to be a position, taken by others on these lists, that
>> IPv6 is the only address family that matters.  Interestingly, this
>> position seems to be most pronounced from people not involved in
>> operating production networks.
> 
> excuse me!

Hi, Randy.  I didn't mean to deny you exist; you apparently do. ;)  But in my 
sampling, operators with the opinion that 'IPv4 doesn't matter' represent the 
minority.  Of course, it also depends on how you define "doesn't matter".  I 
think that ongoing operation matters, especially when "ongoing" means a 
continued expectation of both existing and new customers.  It's easy to say, 
"burn the IPv4 bridge" so we're forced to migrate to IPv6.  But it's another 
thing to actually do it, when you're competing for customers that want IPv4 
connectivity.

That said, we're not forced to choose only one: IPv4 vs. IPv6.  We should 
migrate to IPv6 because it makes sense - IPv4 is going to become more expensive 
and painful (to use and support).  That doesn't preclude us from patching IPv4 
together long enough to cross the bridge first.

Thoughts?

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote:

> On Mon, Feb 21, 2011 at 19:08, Dan Wing  wrote:
> 
>> Its title, filename, abstract, and introduction all say the problems
>> are specific to NAT444.  Which is untrue.
> 
> I just re-read the filename, abstract and introduction, and I disagree
> that any of those say that the problems are specific to NAT444. They
> all do state that these problems are present in NAT444, but not that
> it's the only technology/scenario/configuration where you might find
> them.

Let's at least agree that the text isn't precise.  I've had a large number of 
conversations in which relatively intelligent people advocated other 
(non-NAT444) scenarios involving CGN, built on the premise that NAT444 is 
broken and draft-donley-nat444-impacts is evidence.  Either the draft is 
perfectly clear and all of these people are stupid, or the draft is misleading 
(intentionally or unintentionally).

> More importantly, I am unsure the point of this argument. Are you
> trying to say that the items listed as broken in the draft are not
> actually broken? Because in my experience they are. IMHO, the fact
> that they are also broken in other (similar) scenarios is not evidence
> that they are not broken in this one. On the contrary, this scenario
> seems to be evidence to the brokenness in the others (until we get a
> chance to test and document them all - are you volunteering? ;).

There seems to be a position, taken by others on these lists, that IPv6 is the 
only address family that matters.  Interestingly, this position seems to be 
most pronounced from people not involved in operating production networks.  
But, regardless, if I were to accept this position then I might also agree that 
it doesn't matter whether or not draft-donley-nat444-impacts is misleading.

On the contrary: While I emphatically agree that IPv6 is the path forward, I 
don't accept the notion that IPv4 no longer matters.  IPv4 is the present-day 
Internet, and IPv4 connectivity is demanded by present-day paying customers - 
you don't burn the bridge until *after* you've crossed it.  Further, given that 
IPv4 does matter yet has an exhausted address supply, there exists a need for 
IPv4 address sharing technology.  Fundamentally, this means that we need to 
discuss and engineer the best possible address sharing technology.  It may 
never be as good as native end-to-end IPv6, but sub-optimal is not the same 
thing as "broken" as others have claimed, and sub-optimal might be acceptable 
if it's the only alternative.

Of course, we can also rely on an IPv4 address market to avoid NAT in the more 
sensitive situations (i.e. situations with more sensitive users).  But that's a 
different conversation.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote:

> On Fri, Feb 18, 2011 at 16:07, Benson Schliesser  
> wrote:
> 
>> Broken DNS will result in problems browsing the web.  That doesn't make it 
>> accurate to claim that the web is broken, and it's particularly weak support 
>> for claims that email would work better.
> 
> I don't think that's a great analogy. NAT444 is CGN, the web is not
> DNS. If I say I can chop down a tree with a red ax, can you disprove
> that by saying that you can chop it down with any color ax?

I agree that it's an imperfect analogy, so I won't bother defending it. :)  But 
my point remains:  NAT444 is a deployment scenario, which includes a CGN 
element.  Other deployment scenarios that also include a CGN element will have 
the same issues, and perhaps more.  And, indeed, a number of "transition" (i.e. 
exhaustion) scenarios include a CGN.  Thus it is appropriate to focus on the 
root of the problem (CGN) rather than pointing at just one scenario that 
leverages it.

So...  I agree that CGN is painful, relative to native connectivity and even 
relative to CPE-based NAT44.  But I'd like to understand why NAT444 is better 
or worse than other CGN-based scenarios, before I agree with that conclusion.


> If we get dual v4+v6 connectivity quickly enough, we do not need LSN
> (including NAT444).

Amen, brother.  I guess I'm just pessimistic about the definition of "quickly" 
versus operationally realistic timeframes.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 18, 2011, at 4:46 PM, Owen DeLong wrote:
> On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote:
>> The document is titled "Assessing the Impact of NAT444 on Network 
>> Applications" and it claims to discuss NAT444 issues.  However, it conflates 
>> NAT444 with CGN.  And it is often used as an explanation for supporting 
>> alternative technology such as DS-lite, even though DS-lite also leverages 
>> CGN.  This line of reasoning is broken and, as I've stated already, I'm 
>> waiting for somebody to offer evidence that NAT444 is more problematic than 
>> CGN.
>> 
> NAT444 is one implementation of CGN and the issues it describes all apply to 
> NAT444.
> 
> It does not claim that it discusses issues unique to NAT444. It claims that 
> all of the issues it discusses
> apply to NAT444. That claim is accurate.

You continue to conflate NAT444 and CGN.  I'm not sure I can say anything that 
hasn't already been said, but perhaps an example will help:

Broken DNS will result in problems browsing the web.  That doesn't make it 
accurate to claim that the web is broken, and it's particularly weak support 
for claims that email would work better.


>> Yes.  And today's customers enjoy being able to communicate with the IPv4 
>> Internet.  CGN may be sub-optimal, but it's the lesser of two evils 
>> (disconnection being the other choice).
>> 
> I remain unconvinced of the accuracy of this statement.

Well, if your user does nothing but send email then perhaps even UUCP would be 
good enough.  But for the rest of us, until IPv6 penetration reaches all the 
content/services we care about, we need dual v4+v6 connectivity.

Cheers,
-Benson

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:

> On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
>> 
>> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.
>> 
>> "draft-donley-nat444-impacts-01 is somewhat misleading.  It claims to 
>> analyze NAT444, but it really analyzes what fails when two problems occur: 
>> (a) port forwarding isn't configured and (b) UPnP is unavailable or is 
>> broken. Several architectures share those two problems:
>> 
>> * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network)
>> * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home)
>> * DS-Lite (which is an LSN / NAPT44 in the carrier's network)
>> * stateful NAT64"
>> 
> 
> I don't think the draft makes any attempt to claim that the problems are 
> unique to NAT444, so, the above, while
> technically accurate isn't particulrarly meaningful.

The document is titled "Assessing the Impact of NAT444 on Network Applications" 
and it claims to discuss NAT444 issues.  However, it conflates NAT444 with CGN. 
 And it is often used as an explanation for supporting alternative technology 
such as DS-lite, even though DS-lite also leverages CGN.  This line of 
reasoning is broken and, as I've stated already, I'm waiting for somebody to 
offer evidence that NAT444 is more problematic than CGN.


>> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
>> 
>> Be that as it may and putting my devil's advocate hat on, aren't the 
>> unintended consequences of NAT444 a net win for ISPs? :)
>> 
> I guess that depends on whether you like having customers or not.

Yes.  And today's customers enjoy being able to communicate with the IPv4 
Internet.  CGN may be sub-optimal, but it's the lesser of two evils 
(disconnection being the other choice).

Of course, tomorrow morning's customers will enjoy communicating with the IPv6 
Internet even more, so as somebody else already said: deploy IPv6 alongside any 
CGN solution.

Cheers,
-Benson

Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...

[Benson Schliesser]

On Feb 11, 2011, at 3:44 PM, Michael Dillon wrote:

> Not true. Two of my former employers went to ARIN every year or two and
> received blocks around a /16 in size, specifically for use on global IP 
> networks
> that did not intend to ever announce those addresses on the Internet. There
> are several other companies which operate somewhat similar networks.
> 
> Also, "announce to the Internet" doesn't mean what you think it does.

Exactly.  Further, just because it's announced doesn't mean it's reachable or 
even connected.

Cheers,
-Benson

NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

[Benson Schliesser]

On Feb 10, 2011, at 2:58 PM, Owen DeLong wrote:

>> In terms of CGN44 versus NAT444, I'd like to see evidence of something that 
>> breaks in NAT444 but not CGN44.  People seem to have a gut expectation that 
>> this is the case, and I'm open to the possibility.  But testing aimed at 
>> demonstrating that breakage hasn't been very scientific, as discussed in the 
>> URLs I posted with my previous message.
>> 
> Technologies which depend on a rendezvous host that can know about both sides 
> of both NATs in a private->public->private
> scenario will break in a private->private2->public->private2->private 
> scenario. There are technologies and applications which
> depend on this. (I believe, among others, that's how many of the p2p systems 
> work, no?)

This is an oft-repeated rumor, but as I stated in my recent message: the 
evidence doesn't support the theory.

NAT traversal architectures that leverage "public" rendezvous such as STUN, 
etc, should continue to work and testing demonstrates this.  The tiering of NAT 
does mean that "neighborhood-local" traffic must traverse the CGN, which is 
sub-optimal but not broken.

Dynamic control protocols like UPNP are the only source of problems I'm aware 
of.  Frequently, the solution for a given app is as simple as turning off UPNP. 
 But in the near future, PCP will replace and/or augment UPNP and is more 
scalable.

If you have more experience (not including rumors) that suggests otherwise, I'd 
very much like to hear about it.  I'm open to the possibility that NAT444 
breaks stuff - that feels right in my gut - but I haven't found any valid 
evidence of this.

Regardless, I think we can agree that IPv6 is the way to avoid NAT-related 
growing pains.  We've known this for a long time.

Cheers,
-Benson

Re: Looking for an IPv6 naysayer...

[Benson Schliesser]

On Feb 10, 2011, at 9:53 AM, Jack Bates wrote:

> On 2/10/2011 8:36 AM, Benson Schliesser wrote:
>> DS-lite is still CGN.
> 
> It is still LSN, but it is not NAT444, and the failure rate reduces because 
> of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 
> makes no such assertion.

DS-lite *uses* IPv6 connectivity, it doesn't provide it.  That's like saying 
6rd or 6to4 "guarantees you have IPv4 connectivity".

As for NAT444 (or double-NAT):  One could just as easily deploy DS-lite with a 
NAT444 configuration.  Or deploy CGN without NAT444 (e.g. CGN44, by managing 
subnets delegated to each subscriber).  The two topics are related but separate.

In terms of CGN44 versus NAT444, I'd like to see evidence of something that 
breaks in NAT444 but not CGN44.  People seem to have a gut expectation that 
this is the case, and I'm open to the possibility.  But testing aimed at 
demonstrating that breakage hasn't been very scientific, as discussed in the 
URLs I posted with my previous message.

Cheers,
-Benson

Re: Looking for an IPv6 naysayer...

[Benson Schliesser]

On Feb 9, 2011, at 6:01 PM, Jack Bates wrote:

> On 2/9/2011 5:56 PM, Robert E. Seastrom wrote:
>> Or 6rd and go native on their permanent prefix as the forklift upgrade
>> schedule allows.  Oh well, it's better than nothing or Crummier Grade NAT.
> 
> ds-lite tends to be friendlier LSN from various tests, and is native v6.

DS-lite is still CGN.

You may be thinking of the comparison versus NAT444 described in 
draft-donley-nat444-impacts 
(https://datatracker.ietf.org/doc/draft-donley-nat444-impacts/).  But you 
should read the criticisms of that draft on the BEHAVE mailing list, 
http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and 
http://www.ietf.org/mail-archive/web/behave/current/msg09030.html.

Cheers,
-Benson

Re: Post-Exhaustion-phase "punishment" for early adopters

[Benson Schliesser]

On Feb 8, 2011, at 5:12 PM, Lynda wrote:

> On 2/8/2011 2:46 PM, Brandon Butterworth wrote:
>>> Before arin etc it was possible to request ip space and on the
>>> form specify you would not be connecting to the Internet.
>> 
>> So those off net users can't complain if ARIN allocated the
>> same ranges on net. Not that it's worth doing so now.
> 
> I hoped I was going to be able to resist answering this. I can't.
> 
> There are networks out there that are large, and interconnected, and using 
> valid, assigned IP addresses, that have never been seen on a public router. 
> Never will, either. It's more convenient to use real addresses than 1918 
> blocks. It works better in the DNS, and it's easier to wrap your mind around 
> when you're working math problems about how much to delegate, and where.
> 
> Those blocks remain allocated to the original recipients. I just looked (via 
> whois). They are all still there. I remain amazed that I have them all still 
> memorized. I guess Alzheimer's hasn't struck yet.

It's not just a case of convenience, either.  Try connecting hundreds of 
private networks (each running their own context of 1918 space) to a common 
network-based service without using globally unique addresses.  Not even NAT 
can help you, if your centralized servers have the same addresses as the 
network participants.  And the uniqueness requirements don't change just 
because this "little i" internet isn't routed on the "big I" Internet.

Cheers,
-Benson

Re: Membership model

[Benson Schliesser]

We all know that many people have no IPv6 connectivity.  But I've only heard 
about future Internet-users without IPv4 connectivity...  I didn't realize it 
was reality for Owen today.

(Even my IPv6 phone via T-Mobile has NAT64 connectivity to www.newnog.org.)

Cheers,
-Benson


On Feb 7, 2011, at 4:10 PM, Patrick W. Gilmore wrote:

> [Reply-To: set to -futures@, as I don't think this is an operational issue.]
> 
> On Feb 7, 2011, at 4:55 PM, Owen DeLong wrote:
> 
>> Reaching the web site requires more than an ip6.arpa record.
>> 
>> It requires an  record:
> 
> In the e-mail to which you are replying (and top-posting, no less :), Mike 
> said: "I'm bugging the powers-that-be about getting forward records working." 
>  While I agree doing v6 is nice and all, I think brow-beating an un-paid 
> volunteer on something they already said they were trying to get working is a 
> bit much.
> 
> Remember, this is a community effort.  The people running the web & name 
> servers are donating their time & their companies' resources to the 
> community.  If you believe they are doing it wrong, please step up and help.  
> Input is great, encouraged even.  Help is better.
> 
> Complaining about NewNOG (soon to be NANOG) is complaining about -yourself-.  
> If you are reading this message, you ARE NewNOG.
> 
> -- 
> TTFN,
> patrick
> 
> 
>> baikal:owen (68) ~ % host -t  www.newnog.org 
>>  2011/02/07 13:51:23
>> www.newnog.org has no  record
>> 
>> And it requires the host answer on port 80 at its IPv6 address, which
>> does appear to already be the case.
>> 
>> So, when I'm informed that the  record is up, I'll retest.
>> 
>> Owen
>> 
>> 
>> On Feb 7, 2011, at 1:45 PM, Scott Weeks wrote:
>> 
>>> 
>>> 
>>> ---
 On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote:
 
> I'll happily join Newnog/NANOG and pay my dues when I can reach the
> web site ot do so on IPv6 rather than legacy IPv4.
>>> 
>>> Yes it does.  2001:4970::::2  I'm bugging the powers-that-be about 
>>> getting forward records working.
>>> 
>>> [root@wa-geeks ~]# host 2001:4970::::2
>>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa 
>>> domain name pointer www.newnog.org.
>>> --
>>> 
>>> 
>>> 
>>> Now your only question is check or pay pal...  :-)
>>> 
>>> scott
>> 
>> 
> 
> 

Re: "Leasing" of space via non-connectivity providers

[Benson Schliesser]

On Feb 5, 2011, at 10:48 PM, John Curran wrote:
>  You are correct that consensus doesn't assure legality; hence
>  all draft policies receive a specific staff and legal review 
>  during the development process. 

Thanks, John.  I'm aware of the legal review, as well as the AC and board 
"gateways" to policy adoption.  I don't have any recommendation for improving 
that process, per se - just a healthy dose of skepticism that it will always 
result in alignment with the law, especially given that the legal authority of 
ARIN isn't clearly defined.


On Feb 5, 2011, at 10:44 PM, Owen DeLong wrote:
> As to reflecting community standards, I'm not sure what better measure of 
> "community standards"
> one could propose beyond a bottom-up open consensus driven policy process 
> such as what
> we have today.

Owen, my point is that the ARIN community does not necessarily reflect the 
community at large.  Just like the common standards within the mafia community 
aren't necessarily aligned with the broader standards of civil society.

If ARIN is appointed in an official capacity (i.e. granted such authority by 
the government, or by popular vote etc) to determine specific community 
standards then we don't have to worry.  Otherwise, ARIN has to work carefully 
to ensure that it doesn't go awry.  In that sense, the relative smallness of 
the ARIN community and ARIN's organizational momentum (natural to any 
self-preserving organization) should be of concern.


Cheers,
-Benson

Re: "Leasing" of space via non-connectivity providers

[Benson Schliesser]

On Feb 5, 2011, at 2:25 PM, Owen DeLong wrote:

> The fact that a very large number of network operators use the data
> contained in the RIR system in a cooperative manner is convenient
> and makes the internet substantially more useful than I can imagine
> it would be under alternative scenarios. However, that does not mean
> that the RIRs are granting any sort of license, right to use, or ownership.
> Nor does it mean that terminating a registration constitutes taking away
> such a grant that was never given.

This is a pretty tenuous position.  If the Whois database isn't specifying the 
proper association between an organization and an address block, what is it 
for?  I think you're suggesting that the definition of "proper" in this case is 
no more than ARIN's non-binding recommendation.  If that's the case then ARIN 
has no "authority" as the address registry.  I think ARIN's own statements, 
relationship with NRO and IANA, etc, all contradict this.

On the other hand, if ARIN intends the Whois to reflect the proper association 
between organizations and address blocks, then it has some responsibility for 
the accuracy of that data.  While not a perfect comparison, it would be 
somewhat like a financial services company hired to maintain shareholder 
ownership records of a public company - negligence in maintaining accurate 
records can result in criminal consequences.  In fact, in my example, if the 
company decided to reallocate one group of shares to new owners they'd find 
themselves in a deep pile of trouble - we have laws that govern property 
rights, define theft and fraud, etc, all of which takes precedence over company 
policy.

It would be disingenuous to offer a database of information, recommend it be 
used by the public, support its use as an authoritative source, and then deny 
any responsibility for the contents.  I don't think your position on this 
particular topic reflects ARIN in reality.

Cheers,
-Benson

Re: "Leasing" of space via non-connectivity providers

[Benson Schliesser]

On Feb 5, 2011, at 1:01 PM, Bill Woodcock wrote:
> On Feb 5, 2011, at 10:27 AM, bmann...@vacation.karoshi.com wrote:
>> If I justified an allocation 20 years ago, under the then current policy, 
>> it's presumptuous to presume the power of expropriation.
> 
> No one presumes it, and a lot of us are in the same boat as you, some of the 
> addresses we're using predating the RIR system.
> 
> That said, there will always be people who will turn up on the mailing list, 
> participating in the public policy process, who are not in that boat, and 
> whose interests differ significantly, and who will speak in favor of those 
> interests.
> 
> And the consensus of the public, the people who participate in the public 
> policy process, is what decides 

The ARIN community decides ARIN policy.  That policy doesn't inherently reflect 
"community standards" in the broader sense, or inherently align with the law 
for that matter.  If the ARIN community were to instruct ARIN to operate in an 
illegal capacity, for instance, the fact that a "community" reached "consensus" 
on the matter would be a ridiculous defense.

Cheers,
-Benson

Re: Post-Exhaustion-phase "punishment" for early adopters

[Benson Schliesser]

On Feb 4, 2011, at 1:08 PM, Fred Baker wrote:
> On Feb 4, 2011, at 6:47 PM, Heinrich Strauss wrote:
>> So once the "early" adopters migrate their networks to IPv6, there is no 
>> business need to maintain the IPv4 allocation and that will be returned to 
>> the free pool, since Business would see it as an unnecessary cost.
> 
> Interesting reasoning. I would think that until we have pretty wide IPv4 
> implementation, the business need to keep the allocation is to talk with the 
> people who have not yet implemented it. From a Reductio ad Absurdum 
> perspective, imagine that facebook or youtube, now that they have implemented 
> IPv6, felt obliged to give up their IPv4 allocation immediately? It would 
> mean that they were out of business, which I should think might be an 
> excellent business reason to not deploy IPv6.

Exactly. Which means that folks deploying IPv6 will keep their IPv4 until no 
longer needed. Which in turn means that the value of redeploying those returned 
addresses would be minimal - the Internet would be dominantly IPv6 at that 
point in time.

Cheers,
-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 2:22 PM, John Curran wrote:

> To be clear, that's not ARIN "legally compelling an entity to cease using 
> a specific block of address space"  We've never claimed that authority,
> and I'm not aware of any entity that does claim such authority to compel
> organizations to make router and system configuration changes.  We do 
> claim authority to manage the database as part of our organizational 
> mission.

I recognize the technical difference, but I don't think it's material in this 
instance.  Although I'm not a lawyer, I see a few legal hazards in the position 
you've described.  Foremost: (a) there still is potential liability in 
contributing to a harm (or crime) even if you're not the firsthand actor, and 
(b) being "community-driven" and "following policy" is not a valid legal 
defense.  ARIN is a business league that maintains a database commonly relied 
upon for establishing "rights" to use addresses (or "ownership" depending on 
your view).  ARIN may not control the networks that leverage this data, but 
there is responsibility in publishing it.  If people act in a coordinated 
manner, directly as a result of data that ARIN publishes, then ARIN would be 
hard pressed to avoid liability.

Having said that, it should be clear that I view ARIN "reclaiming" legacy 
addresses that aren't under contract (i.e. LRSA) as fraud, perhaps even in the 
legal sense of the word.  It might also be considered theft by some.  But 
outright reclaiming from ongoing address holders isn't a big concern of mine, 
because I doubt ARIN will go far down that path (if it goes at all).  My real 
concern is that ARIN might refuse to recognize legacy transfers, fail to update 
the Whois database, issue RPKI inappropriately, and cause real damage to live 
networks.  This would be bad for the networks that implement ARIN Whois-based 
policy, of course.  It would also be bad for ARIN if it causes legal disputes 
(and costs).

On that note, I'm going to take my discussion of policy to the PPML list.  I'd 
be interested, however, in NANOG discussion of my comments on Whois, RPKI, etc.

Cheers,
-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 4:29 PM, John Curran wrote:

> On Feb 3, 2011, at 3:42 PM, David Conrad wrote:
> 
>> Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to 
>> be "successor registries" (whatever they are).  
> 
> David - ARIN succeeded Network Solutions in 1997 in the performance of IP 
> number assignment, Autonomous System number assignment, and IN-ADDR.ARPA 
> tasks.

I succeeded my father.  That fact does not automatically grant me any authority 
of his - it has to be legally provided for (e.g. inherited per the law) if I'm 
to claim it legitimately.

Does ARIN have a privileged legal status as a result of their formation by 
NetSol, by contract with IANA or the US Govt, or otherwise?

-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 4:34 PM, Robert Bonomi wrote:

> Abssolutely *NOT*.  their unique status derives from the actions of a 
> contractor "faithfully executing" it's duties on the behalf of the U.S.
> Gov't.  'Antitrust' does not apply to the Gov't, nor to those acting
> on its behalf, nor to anyone operating a government-sanctioned monopoly.

Maybe that applies to ICANN.  But how does it apply to ARIN?

-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 10:57 AM, John Curran wrote:

> On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote:
>>> Such transfers should be reported when noticed, so the resources can be 
>>> reclaimed and reissued.
>> 
>> Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks 
>> that RIR didn't "issue"?  Without that legal authority, is any RIR prepared 
>> to accommodate the legal damages stemming from "reclamation"? (Does the RIR 
>> membership support such action, in the first place?)
> 
> Resources are listed in the ARIN WHOIS database, which is administered per 
> policies established by the community in this region.
> 
> Short answer: there's no shortage of authority updating that database as long 
> as the community wishes it so.

I respect the community-driven process and I respect that ARIN's role is to 
enforce community-developed policy.  From that perspective, thank you for your 
answer.

But that's only valid up to a point.  If the community declared overwhelmingly 
that ARIN should start clubbing random people over the head, I suspect your 
legal counsel would take issue with that policy and ARIN would refuse to 
enforce it.

Of course this is only theoretical at the moment.  The rubber will meet the 
road soon, now that the exhaustion phase has arrived.

Cheers,
-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 10:39 AM, John Curran wrote:

> On Feb 3, 2011, at 11:22 AM, Benson Schliesser wrote:
>> That's what the RIR might say.  But without legal authority (e.g. under 
>> contract, as a regulator, or through statutory authority) it is difficult or 
>> impossible to enforce.
> 
> Transfers are permitted in the ARIN region per the community developed 
> policies.

Understood.  My point is: legacy holders, unless they've signed the LRSA or 
equivalent, aren't required to submit to the ARIN process.


>> We can talk about how people "should" return addresses, or "should" justify 
>> transfers, etc, but we would only be begging.  Transfers will take place 
>> outside the RIR scope, because RIR transfer/market policy doesn't 
>> accommodate reality.
> 
> Such transfers should be reported when noticed, so the resources can be 
> reclaimed and reissued.

Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks 
that RIR didn't "issue"?  Without that legal authority, is any RIR prepared to 
accommodate the legal damages stemming from "reclamation"? (Does the RIR 
membership support such action, in the first place?)


>> Or, we can fix policy..?
> 
> Absolutely... if the policy doesn't match your needs, please make a policy 
> proposal. 

That's a good suggestion, which I will follow-up on.  I hope the RIR community 
can change despite its own momentum.


Cheers,
-Benson

Re: And so it ends...

[Benson Schliesser]

On Feb 3, 2011, at 9:30 AM, Patrick W. Gilmore wrote:

> On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote:
> 
>> The real fun's going to be over the next several years as the RIR's become 
>> irrelevant in the acquisition of scarce IPv4 resources...and things become 
>> less stable as lots of orgs rush to implement a strange new IP version.
> 
> Supposedly[*] transfers between private entities are still supposed to be 
> justified to the local RIRs.  (At least that's how it works in ARIN's area.)

That's what the RIR might say.  But without legal authority (e.g. under 
contract, as a regulator, or through statutory authority) it is difficult or 
impossible to enforce.

We can talk about how people "should" return addresses, or "should" justify 
transfers, etc, but we would only be begging.  Transfers will take place 
outside the RIR scope, because RIR transfer/market policy doesn't accommodate 
reality.

Or, we can fix policy..?

Cheers,
-Benson

Re: Last of ipv4 /8's allocated

[Benson Schliesser]

On Feb 1, 2011, at 8:10 PM, Jeroen van Aart wrote:

> Randy Carpenter wrote:
>> Touché!  That could theoretically happen. I think Apple should buy HPQDEC 
>> just so they can announce 16/7 :-)
> 
> Nah, one should buy the other just so they can hand over a /7 to APNIC.


How would they justify that to their shareholders?

(I mean turning over the addresses - the merger itself would be a more 
challenging question.)

-Benson

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Benson Schliesser]

On Feb 1, 2011, at 5:13 PM, Dongting Yu wrote:

> Since we are already talking about RIRs, I am curious, who will sign
> the legacy blocks in RPKI?

Since they pre-exist the RIR, it's not clear that any one RIR has authority 
until asked.

(For a discussion of rights, authority, etc, see 
http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf)

Thus, I think the legacy address holders will have to request "services" from 
an RIR.  Or from a trusted third party.

(For instance, see 
http://www.circleid.com/posts/competition_to_regional_internet_registries_rir_for_post_allocation_service/)

Cheers,
-Benson

Re: quietly....

[Benson Schliesser]

On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote:

> NAT solves exactly one problem. It provides a way to reduce address 
> consumption to work around a shortage of addresses.
> 
> It does not solve any other problem(s).

In all fairness, that's not really true.  It just doesn't solve other problems 
in an optimal way.

Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily 
have such a requirement.

Not that I love NAT66, but let's at least be honest about it.

Cheers,
-Benson

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Benson Schliesser]

On Feb 1, 2011, at 3:43 PM, Arturo Servin wrote:

>   Is it really a better alternative? Do we want to pay the cost of a 
> fully distributed RPKI architecture?
> 
>   Or do we just abandon the idea of protecting the routing infrastructure?
> 
>   There is no free-lunch, we just need to select the price that we want 
> to pay.
> 

I agree there is no free-lunch.

Randy Bush addressed the problem, in a recent email, by contrasting his 
"security" personality against his mistrust of authority. (That's my summary, 
not his words.)  And I think that's exactly what I'm struggling with.  I want 
to secure the routing infrastructure, but I don't completely trust centralized 
regimes.  At their best, they're a target for exploitation - at their worst, 
they're authoritarian.

Randy was kind enough to point me toward 
http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-00 which I'm in the process 
of reading.  Perhaps there is a way to balance between "fully distributed" and 
"centralized", e.g. by supporting multiple roots and different trust domains.

Cheers,
-Benson




> On 1 Feb 2011, at 16:29, Benson Schliesser wrote:
> 
>> 
>> On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote:
>> 
>>> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert  wrote:
>>>> Here be dragons,
>>> 
>>>> It should be fairly obvious, by most recently what's going on in
>>>> Egypt, why allowing a government to control the Internet is a Really
>>>> Bad Idea.
>>>> 
>>> 
>>> how is the egypt thing related to rPKI?
>>> How is the propsed rPKI work related to gov't control?
>> 
>> In theory at least, entities closer to the RPKI root (RIRs, IANA) could 
>> invalidate routes for any sort of policy reasons.  This might provide 
>> leverage to certain governments, perhaps even offering the ability to 
>> control routing beyond their jurisdiction.
>> 
>> As an example, it's imaginable that the US government could require IANA or 
>> ARIN to delegate authority to the NSA for a Canadian ISP's routes.  Feel 
>> free to replace the RIR/LIR and country names, to suit your own example.
>> 
>> Cheers,
>> -Benson
>> 
>> 
> 
> 

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Benson Schliesser]

On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote:

> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert  wrote:
>> Here be dragons,
> 
>> It should be fairly obvious, by most recently what's going on in
>> Egypt, why allowing a government to control the Internet is a Really
>> Bad Idea.
>> 
> 
> how is the egypt thing related to rPKI?
> How is the propsed rPKI work related to gov't control?

In theory at least, entities closer to the RPKI root (RIRs, IANA) could 
invalidate routes for any sort of policy reasons.  This might provide leverage 
to certain governments, perhaps even offering the ability to control routing 
beyond their jurisdiction.

As an example, it's imaginable that the US government could require IANA or 
ARIN to delegate authority to the NSA for a Canadian ISP's routes.  Feel free 
to replace the RIR/LIR and country names, to suit your own example.

Cheers,
-Benson

Re: ipv4's last graph

[Benson Schliesser]

On Feb 1, 2011, at 3:08 PM, Randy Bush wrote:
> 
>> Is there really any value in trying to distribute graphs that will all
>> be flat before the end of the year?
> 
> we're ops, often stick in the mud traditionalists and even somewhat
> supersitious.  we've had ipv4 graphs for over 15 years.  we like them.
> geoff is mr graph.  we like his grphs.  heck, you have even used them.

If you're standing near the edge of a cliff, the difference between 1 inch and 
6 inches is significant.  Vendors are watching from the distance, saying "he's 
at the edge of the cliff!".  But to the guy standing there, it matters.

Plus, I like graphs.

Cheers,
-Benson

Re: Verizon acquiring Terremark

[Benson Schliesser]

On Jan 31, 2011, at 10:25 PM, Jimmy Hess wrote:
> 
>> What does neutral really mean anyways?  Terremark has sold, is selling and
> 
> It is the same concept as network neutrality.
> An example of a non-neutral IP network is  one where a competitor's website or
> service is blocked by the network operator.
> 
> A facility is carrier neutral if it is operated by an independent 
> organization.
> An example of a non-neutral exchange is one that  only allows specific
> tenants  to connect to other tenants;   other tenants besides the chosen ones
> are forbidden from connecting to anyone besides a preferred tenant,
> or  have to pay higher rates for each connection to another provider who
> is not a 'preferred' tenant.

I don't know - it's an oversimplification.  Even the "independent organization" 
is still trying to pull in revenue.  Given the opportunity to make money on 
interconnections, they do so.  And the idea of "neutral" is pretty hard to 
define, when you mix together all of the participants' different business 
relationships and incentives, operating margins and price variations, etc.

They'll say: "Sure you can connect to anybody you want.  As long as you pay a 
monthly cross-connect fee. And as long as the other party is paying for a 
presence in my facility, too."  But do you know who pays how much?  In the end, 
are you sure that a carrier "neutral" facility offers a better price than a 
non-neutral facility, for any given connectivity?  I'd suggest that "carrier 
neutrality" is subjective and isn't really the metric you need in a colo / 
datacenter facility.

Cheers,
-Benson

Re: Connectivity status for Egypt

[Benson Schliesser]

On Jan 28, 2011, at 1:44 PM, andrew.wallace wrote:

> We should be asking the Egyptians to stagger the return of services so that 
> infrastructure isn't affected, when connectivity is deemed to be allowed to 
> come back online.
> 
> Andrew Wallace
> 
> ---
> 
> British IT Security Consultant


You should send them an email about that.

Re: Problems with removing NAT from a network

[Benson Schliesser]

On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote:

> On 1/6/2011 9:28 PM, Dan Wing wrote:
>> 
>> Skype could make it work with direct UDP packets in about 92% of
>> cases, per Google's published direct-to-direct statistic at
>> http://code.google.com/apis/talk/libjingle/important_concepts.html
>> 
> If one end is behind a NAT64 and there is no mechanism for discovering the 
> NAT64's IPv6 interface prefix and mapping algorithm (and at present there is 
> not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 
> literal addresses (that is to say, addresses learned via a mechanism other 
> than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on 
> the IPv4 Internet through said NAT64.
> 
> That's the case we're discussing here.
> 
> It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. 
> Even the protocol described in the referenced document, Jingle (as it 
> essentially uses ICE) fails. The candidate IPv4 addresses for the end that's 
> on the IPv4 Internet (local and STUN-derived) that are delivered over 
> Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to 
> reach the IPv4 Internet because it has no IPv4 sockets available to it and 
> even if it knew that NAT64 existed (which would take a modification to the 
> Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 
> address to use to reach the IPv4 host because there's no discovery mechanism. 
> If you want we can take this back to the BEHAVE list now.

To paraphrase what you're saying: stuff that embeds and passes around IPv4 
addresses will break.  I'm sorry to say this, but that's just reality.  
Embedded IP addresses has always been a Bad Idea (tm) in development and 
operations, and I don't think P2P protocols get a pass - building your own 
discovery and topology mechanisms don't insulate you from having to use the 
underlying network.

The best chance anybody has, is to build dual-stack support and start using DNS 
names rather than IP numbers.  Oh, and expect IPv4 to start breaking in the 
near future.  We're trying to make IPv4 work long enough to survive the 
transition, but it's not a good bet for new protocols.

Cheers,
-Benson

Re: Problems with removing NAT from a network

[Benson Schliesser]

On Jan 5, 2011, at 10:31 PM, Mark Andrews wrote:
> 
> Which is one of the reasons why DS-lite is a better solution for
> providing legacy access to the IPv4 Internet than NAT64/DNS64.
> DS-lite only breaks what NAT44 breaks.  DS-lite doesn't break new
> things.
> 

Or just run a dual-stack network, with centralized NAT44, and avoid the 
headache of tunneling.  If you're going to run two protocol families on the end 
host, and deal with the issues that causes, why require tunneling to make it 
work?  Is it so hard to forward IPv4 packets natively?

Cheers,
-Benson

Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute

[Benson Schliesser]

On Dec 17, 2010, at 11:35 AM, Jeff Wheeler wrote:

> ... Level3 must think that their business
> would be better off with regulatory oversight of peering, or they
> would not have taken this action. 

And they might be correct in thinking that, if we assume the peering ecosystem 
is changing i.e. such that traditional "backbones" are being bypassed.  
Regulatory oversight might have the effect of locking-in today's interconnect 
regime, which would be ideal for Level(3).

Cheers,
-Benson

Re: "potential new and different architectural approach" to solve the

[Benson Schliesser]

On Dec 17, 2010, at 11:23 AM, Joe Greco wrote:

> How effective have variations on hot potato routing been, historically?
> I seem to recall Cogent made lots of noises early on about how they
> could do hot potato routing to encourage peering, but over the years
> that didn't seem to pan out that way.

I can't comment on Cogent...  But, in general: hot-potato reduces network costs 
but doesn't eliminate them--more capacity is still required to carry more 
traffic.  The goal is to balance out the cost, assuming the traffic is of 
adequate value (or equal value, ideally) to both networks.

Cheers,
-Benson

Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute

[Benson Schliesser]

On Dec 17, 2010, at 9:57 AM, Loránd Jakab wrote:

> Since it is Friday, maybe some of peering experts have some time to
> speculate what this new approach proposed by Comcast might be, as they
> assert it would represent "a significant shift of Internet infrastructure."
> 
> http://www.lightreading.com/document.asp?doc_id=202121
> http://blog.comcast.com/2010/12/comcast-continues-discussions-with-level-3offers-to-trial-new-solutions.html

I have no direct knowledge of the situation, but my guess:  I suspect the 
proposal was along the lines of longest-path / best-exit routing by Level(3).  
In other words, if L(3) carries the traffic (most of the way) to the customer, 
then Comcast has no complaint--the costs can be more fairly distributed.  The 
"modest investment" is probably in tools to evaluate traffic and routing 
metrics, to make this work.  This isn't really *new* to the peering community, 
but it isn't normal either.

If anybody knows for sure, I'd be interested to hear.

Cheers,
-Benson

Re: Cost of transit and options in APAC

[Benson Schliesser]

On 12 Aug 10, at 7:26 AM, Dorian Kim wrote:

>> Sadly, I have no first-hand knowledge of these costs.  How does in-country 
>> transport compare to trans-Pacific transport cost? (i.e. on a per Mbps per 
>> kilometer or similar metric)  I assume it's cheaper in-country / in-region 
>> compared to trans-oceanic.  Is this true?
> 
> This is not an assumption you can make safely depending on the country and 
> specific
> sub-region you are talking about.

That's fair; I'm not surprised to hear it.  But I'm curious about the details.  
In specific cases like India and China, what is the underlying contributor to 
higher relative transport costs?  (i.e. taxes, ROW fees, extraordinary shipping 
or operational costs, inadequate competition, low supply, greed, etc)  Further, 
how does the situation compare to past examples like Europe?

I doubt the AP region is forever doomed to exchange traffic via the US, but 
can't quite anticipate change without first understanding the current 
environment.  Network interconnects are designed the way they are, today, for a 
reason.  If anybody has insight they can share on the situation I would 
appreciate it.

Cheers,
-Benson

Re: Cost of transit and options in APAC

[Benson Schliesser]

On 11 Aug 10, at 5:15 PM, Joel Jaeggli wrote:

>> Obviously I can't speak for the providers in question, but I'd guess
>> that the cost for transit in AP is strongly related to the cost of
>> long-haul transport.
> 
> Start with something that can be effectively isolated from the
> transpacific path.
> 
> Gotten a quote for a 1Gbe or 10Gbe between two cities in India recently?

That could be useful.  Sadly, I have no first-hand knowledge of these costs.  
How does in-country transport compare to trans-Pacific transport cost? (i.e. on 
a per Mbps per kilometer or similar metric)  I assume it's cheaper in-country / 
in-region compared to trans-oceanic.  Is this true?

Once that's known, I'd also look at the opposite: excluding any last-mile 
transport costs, what is the price per Mbps for transit service?  That transit 
price has to accommodate both the local/in-region transport as well as 
trans-oceanic transport costs borne by the provider. If the locale of traffic 
is shifting, then the provider's transport costs are also shifting from one 
category to another.

My advice to anybody looking to buy AP regional transit, assuming that 
trans-oceanic bandwidth is more expensive than regional bandwidth, is to 
negotiate a lower price in exchange for only in-region routes.  If my 
assumption about bandwidth costs is backwards, then you're out of luck.  (Maybe 
we need lower taxes, higher bribes, or more competition..?)

Cheers,
-Benson

Re: off-topic: summary on Internet traffic growth History

[Benson Schliesser]

On 11 Aug 10, at 2:10 PM, Chris Boyd wrote:

> My recollection is that Worldcom bought out MFS.  UUnet was a later 
> acquisition by the Worldcom monster (no, no biases here :-).  While this was 
> going on MCI was building and running what was called the BIPP (Basic IP 
> Platform) internally.  That product was at least reasonably successful, 
> enough so that some gummint powers that be required divestiture of the BIPP 
> from the company that would come out of the proposed acquisition of MCI by 
> Worldcom.  The regulators felt that Worldcom would have too large a share of 
> the North American Internet traffic.  The BIPP went with BT IIRC, and I think 
> finally landed in Global Crossing's assets.

Actually, Cable & Wireless acquired the BIPP after regulators forced Worldcom 
to divest one of their networks.  C&W developed a new network architecture as 
an evolution of BIPP called "N3", based on MPLS as an ATM replacement for TE.  
(Perhaps somebody that worked at C&W back then can comment on N3; I can't 
recall what it stood for.)  After a few years, C&W reorganized their American 
operations into a separate entity, which subsequently went bankrupt.  Savvis 
(my current employer) bought the assets out of bankruptcy court.  We then 
upgraded the N3 network to support better QoS, higher capacity, etc, and call 
it the "ATN" (Application Transport Network).  The current Savvis core network, 
AS3561, is thus the evolved offspring of the MCI Internet Services / 
Internet-MCI network.

Of course, before all of this, MCI built the network as a commercial Internet 
platform in parallel to their ARPA network.  That's before my time, 
unfortunately, so I don't know many details.  For instance I'm uncertain how 
the ASN has changed over the years.  Anybody with more history and/or 
corrections would be appreciated.

Cheers,
-Benson

Re: Cost of transit and options in APAC

[Benson Schliesser]

On 11 Aug 10, at 2:53 PM, Joel Jaeggli wrote:

> I think the question is more like why am I being quoted $100 A megabit
> in India for transit in India? Not why am I being charged for for the
> transport cost across the pacific.

Obviously I can't speak for the providers in question, but I'd guess that the 
cost for transit in AP is strongly related to the cost of long-haul transport.  
Once upon a time, the majority of Internet traffic in AP countries *did* 
originate in the US.  Does anybody have data that this is changing?

Cheers,
-Benson

Re: multicast nightmare #42 - REDUX

[Benson Schliesser]

Is the packet loss uniform for each receiver? Or is there a pattern to  
the loss, e.g. each receiver hears a different / non-overlapping 50%  
of the packets?


Off the cuff, I'd suspect a problem with IGMP snooping.

Cheers,
-Benson




On 14 Oct 09, at 12:36 PM, Adrian Minta wrote:


Philip Lavine wrote:

More info if this helps:

Switch Platform:
4500 SUPII+
with gig line cards

Data rate is <100Mbps

Server OS: Windows 2003 R2 (please withhold snickering).



Multicast traffic is routed ?

--
Best regards,
Adrian Minta

Re: Data Centers in England

[Benson Schliesser]

Philip-

I'm only really familiar with my employer's facilities: Savvis has  
data centers in London, Slough, and Reading with good exchange  
connectivity*. There is a financial-firm oriented microsite at http://financial.savvis.net/ 
, but beware the annoying* embedded video. You can look at http://www.savvis.net/en-US/Industries/Financial/Pages/Home.aspx 
 for more info, too.


Cheers,
-Benson


* - Obligatory Legal Statement for which I Personally Apologize: I'm  
employed by Savvis, but my opinions, postings, and all other materials  
are my own and do not necessarily represent those of my employer  
(Savvis, Inc.) or of any other entity.




On 7 Oct 09, at 5:09 PM, Shane Ronan wrote:

As the CTO of a financial company with multiple data centers in  
London, I would recommend Equinix Slough (or London 4) site. They  
have a website setup just for Financial firms. http://financial.equinix.com/


I've got space in both Telehouse and Equinix and would recommend  
Equinix for someone looking for full service collocation and  
Telehouse to someone who is looking for network interconnection.


Shane


On Oct 7, 2009, at 5:59 PM, Simon Lockhart wrote:


On Wed Oct 07, 2009 at 02:33:33PM -0700, Philip Lavine wrote:
Anyone know a good DC on England that caters to financial industry  
clients?


Telehouse London started as a Banking DR centre, so would probably  
meet your
needs. Otherwise, there's Interxion, which claims to have all sorts  
of security
certifications. The other usual suspects are also available in  
London - Level3,

Equinix, C&W, etc...

Simon

Re: why not AS number based prefixes aggregation

[Benson Schliesser]

On Mon, September 8, 2008 09:46, Scott Brim wrote:
> Also, ASNs are not
> aggregatable so we can't use them to represent a large number of
> independently routed networks.

Scott,

I'm not sure an Autonomous System would want to be aggregated. By its
nature it is capable of having arbitrary connectivity. On the other hand,
addresses can be aggregated. An ASN-based address system would support a
more efficient form of aggregation than we have today. And routing
(including TE) could be supported by attributes, rather than by
address/prefix-len. *shrug*

Yang,

As somebody pointed out already, LISP provides approximately the same sort
of mechanism. Though it uses a list of Locators (backbone/core IP
addresses) rather than ASNs to identify an Endpoint's site, relying on a
lightweight form of tunneling through the core to support endpoint
communication. This allows it to preserve both IPv4/v6 and existing global
routing protocols (and thus deployed support). The downside is that it
requires a more dynamic mapping mechanism than a theoretical ASN-based
approach. You can learn more at http://www.lisp4.net/, and discuss it on
the [EMAIL PROTECTED] mailing list.

Cheers,
-Benson