Re: Remember "Internet-In-A-Box"?

[Seth Mos]

So, if i get this right. The problem is not quite as bad to fix.
It just needs a dnscache/dnsproxy process bound to the ipv4 localhost that uses 
the ipv6 dns server.
Basically what dnsmasq does. Biggest problem is that it wouldn't follow 
autoconfigure and thus require manual intervention. That is a no go for dynamic 
networks of any sort.
Cheers Oorspronkelijk bericht Van: Owen DeLong 
 Datum: 16-07-2015  08:51  (GMT+01:00) Aan: Mark Andrews 
 Cc: nanog@nanog.org Onderwerp: Re: Remember 
"Internet-In-A-Box"? 
> On Jul 15, 2015, at 19:32 , Mark Andrews  wrote:
> 
> 
> In message <55a682e6.1050...@matthew.at>, Matthew Kaufman writes:
>> On 7/14/2015 11:22 PM, Mark Andrews wrote:
>>> 
>>> Yet I can take a Windows XP box.  Tell it to enable IPv6 and it
>>> just works.  Everything that a node needed existed when Windows XP
>>> was released.  The last 15 years has been waiting for ISP's and CPE
>>> vendors to deliver IPv6 as a product.  This is not to say that every
>>> vendor deployed all the parts of the protocol properly but they
>>> existed.
>> 
>> This is only true for dual-stacked networks. I just tried to set up an 
>> IPv6-only WiFi network at my house recently, and it was a total fail due 
>> to non-implementation of relatively new standards... starting with the 
>> fact that my Juniper SRX doesn't run a load new enough to include RDNSS 
>> information in RAs, and some of the devices I wanted to test with 
>> (Android tablets) won't do DHCPv6.
> 
> You can blame the religious zealots that insisted that everything
> DHCP does has to also be done via RA's.  This means that everyone
> has to implement everything twice.  Something Google should have
> realised when they releases Android.

Actually, no.

In this case, the problem isn’t the things RA does, but the things his
implementation of RA doesn’t do (RDNSS).

Without RDNSS, android would still be brain-damaged and unable
to figure out what an IPv6 nameserver is. The only way it would be
able to talk to the IPv6 internet was if it got nameservers from DHCP4.

At least with RDNSS, a thin lightweight client can get nameservers on IPv6.
At least with RDNSS, a network administrator that doesn’t want to have
to do DHCPv6 doesn’t have to in most cases.

>> The XP box is in an even worse situation if you try to run it on a 
>> v6-only network.
> 
> Which is fixable with a third party DHCPv6 client / manual configuration
> of the nameservers.

Nope… XP’s resolver is utterly and completely incapable of transmitting
an IPv6 DNS request.

You _HAVE_ to have an IPv4 resolver reachable to the box or forego any
idea of using DNS.

Owen

Re: Remember "Internet-In-A-Box"?

[Owen DeLong]

> On Jul 16, 2015, at 00:34 , Seth Mos  wrote:
> 
> So, if i get this right. The problem is not quite as bad to fix.
> 
> It just needs a dnscache/dnsproxy process bound to the ipv4 localhost that 
> uses the ipv6 dns server.
> 
> Basically what dnsmasq does. Biggest problem is that it wouldn't follow 
> autoconfigure and thus require manual intervention. That is a no go for 
> dynamic networks of any sort.

It’s a fairly safe bet that anything that involves a mobile OS is most likely a 
dynamic network of some sort.

Owen

> 
> Cheers
>  Oorspronkelijk bericht 
> Van: Owen DeLong 
> Datum: 16-07-2015 08:51 (GMT+01:00)
> Aan: Mark Andrews 
> Cc: nanog@nanog.org
> Onderwerp: Re: Remember "Internet-In-A-Box"?
> 
> > On Jul 15, 2015, at 19:32 , Mark Andrews  wrote:
> > 
> > 
> > In message <55a682e6.1050...@matthew.at>, Matthew Kaufman writes:
> >> On 7/14/2015 11:22 PM, Mark Andrews wrote:
> >>> 
> >>> Yet I can take a Windows XP box.  Tell it to enable IPv6 and it
> >>> just works.  Everything that a node needed existed when Windows XP
> >>> was released.  The last 15 years has been waiting for ISP's and CPE
> >>> vendors to deliver IPv6 as a product.  This is not to say that every
> >>> vendor deployed all the parts of the protocol properly but they
> >>> existed.
> >> 
> >> This is only true for dual-stacked networks. I just tried to set up an 
> >> IPv6-only WiFi network at my house recently, and it was a total fail due 
> >> to non-implementation of relatively new standards... starting with the 
> >> fact that my Juniper SRX doesn't run a load new enough to include RDNSS 
> >> information in RAs, and some of the devices I wanted to test with 
> >> (Android tablets) won't do DHCPv6.
> > 
> > You can blame the religious zealots that insisted that everything
> > DHCP does has to also be done via RA's.  This means that everyone
> > has to implement everything twice.  Something Google should have
> > realised when they releases Android.
> 
> Actually, no.
> 
> In this case, the problem isn’t the things RA does, but the things his
> implementation of RA doesn’t do (RDNSS).
> 
> Without RDNSS, android would still be brain-damaged and unable
> to figure out what an IPv6 nameserver is. The only way it would be
> able to talk to the IPv6 internet was if it got nameservers from DHCP4.
> 
> At least with RDNSS, a thin lightweight client can get nameservers on IPv6.
> At least with RDNSS, a network administrator that doesn’t want to have
> to do DHCPv6 doesn’t have to in most cases.
> 
> >> The XP box is in an even worse situation if you try to run it on a 
> >> v6-only network.
> > 
> > Which is fixable with a third party DHCPv6 client / manual configuration
> > of the nameservers.
> 
> Nope… XP’s resolver is utterly and completely incapable of transmitting
> an IPv6 DNS request.
> 
> You _HAVE_ to have an IPv4 resolver reachable to the box or forego any
> idea of using DNS.
> 
> Owen
> 

Re: Remember "Internet-In-A-Box"?

[Mark Andrews]

In message <20150716060336.ga4...@bamboo.slabnet.com>, Hugo Slabbert writes:
> --snip--
>
> >You can blame the religious zealots that insisted that everything
> >DHCP does has to also be done via RA's.  This means that everyone
> >has to implement everything twice.  Something Google should have
> >realised when they releases Android.
>
> oi...do we want to go down that road[1][2] again?

Once you have two methods of doing things, neither of which is
manditory to implement, you can only get interoperate with everything
if you implement both.  The whole "we can't open a second socket"
to do DHCP + SLACC because it is "too complicated" or "we don't
want to run a second server" was nonsense.  The direct consequence
of doing that was Android not working on networks that supply other
config over DHCP.

We ship servers that speak multiple protocols on one multiple ports
in the one binary.  It isn't and never has been hard to do that.

> --
> Hugo
>
> h...@slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319
> 1D77 9AB1 0FFD B178 313E
>
> (also on textsecure & redphone)
>
> [1] http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html
> [2] https://code.google.com/p/android/issues/detail?id=32621
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Dual stack IPv6 for IPv4 depletion

[Mark Tinka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/Jul/15 17:49, valdis.kletni...@vt.edu wrote:
>
> There isn't any technical reason that an organization can't fix its edge
> so it doesn't urinate bad IPv6 traffic all over the Internet.

Some hardware does not support uRPF, for example.

ACL's would work, but there are administrative scaling issues. Still,
better to have that than nothing at all.

Mark.
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJVp6IxAAoJEGcZuYTeKm+G8v4P+QE2PylGp9jDuThry8d4a1OD
8d6+8cKvgf0EG2Jg+Vm076JV6lwNFKRrf2i36AA0F3o2+cFFhFfbM5eUB+4HXGia
UQtvEclba8CeTQHdxFAZDCOfXSxUT9bhTt4Uc9kplAY+BoF7yGyk6U2KxG45T+Fd
4kXlwXqSZmFqRsH4oRNPPvVKQsfj5VFz90iPW6Qh8gCawcH9sDU3d4esEemwGArz
3v79a+qlrNFgbv/C4soTyIveAE1BJ6lI1c0UQA0cGc+pbRvk/LByG5Ep+gD9Rsvc
xjApdnmDSMw8qLMpn4zvtjYeKpaeaVuwsyr+iokYPOOi/uU3EB/rk7wobXCtdb2j
tUqVtnbJocLhdmmPh90JDK0TNEaJLOY9H3dOfmOrIPCIg7jY9+4EW/+ivL1bARi/
0iWpASGhJhLqaBhGay7pGgQA+2lf2DhHyLqRZd2hhQNZWrf5eEfY44ZzZSqezURD
fV25Uf33HCEgV2M+Hqmmj83CFpSkt0gdjrBCp3FlcLesKJPr8+tSyerGdzCLSPlp
q4kTV2rgXtLXmKm5ElsLlEgsrNEyDW1cZZj3ES35D7aDNzDH19uGd492nrIq2U6z
0Yk1ZUz3s6Ohxfmnhs8ompFGPoII2jEoZTIcVpdM71gLwwIMzSg4a3HoQ88mCCZT
yxYaKw3YmjS8BhkbfaEJ
=7ivn
-END PGP SIGNATURE-

Re: Dual stack IPv6 for IPv4 depletion

[Jared Mauch]

On Wed, Jul 15, 2015 at 08:13:52PM -0400, Joe Maimon wrote:
> Because by doing so, you guarantee failure.

I'll take personal responsibility for the class
E space not working if that makes you feel better.

I suspect it would be easier to get 0.1.0.0-0.255.255.255
to work than 240-254 space.  Think of the children with
tablets/devices that can't be upgraded due to orphaned software
by Android and Apple.  The list goes on and on..

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

ISP in NYC

[Dovid Bender]

Hi,

We are looking to peer with another ISP in NY. My options are:
Telia
Tata
Cogent

We currently have (and will keep):
HE
NTT
TELX (They use NTT and HE and we are looking to replace them).

We need an ISP that has a good peering/connectivity in Europe and Asia
(Israel specific).

Any advice on who to go with?

Re: Remember "Internet-In-A-Box"?

[Hugo Slabbert]

On Thu 2015-Jul-16 21:19:54 +1000, Mark Andrews  wrote:



In message <20150716060336.ga4...@bamboo.slabnet.com>, Hugo Slabbert writes:

--snip--

>You can blame the religious zealots that insisted that everything
>DHCP does has to also be done via RA's.  This means that everyone
>has to implement everything twice.  Something Google should have
>realised when they releases Android.

oi...do we want to go down that road[1][2] again?


Once you have two methods of doing things, neither of which is
manditory to implement, you can only get interoperate with everything
if you implement both.  The whole "we can't open a second socket"
to do DHCP + SLACC because it is "too complicated" or "we don't
want to run a second server" was nonsense.  The direct consequence
of doing that was Android not working on networks that supply other
config over DHCP.

We ship servers that speak multiple protocols on one multiple ports
in the one binary.  It isn't and never has been hard to do that.


Not disagreeing with you.  The discussion was just exhaustively expounded 
in that thread over (by my count) 182 messages, with very little to show 
for it.  We can take another run at flinging words on the topic and trying 
to get Google to implement a DHCPv6 client in Android, but I have my doubts 
about how effective that will be.




--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319
1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)


signature.asc
Description: Digital signature

Re: Dual stack IPv6 for IPv4 depletion

[Joe Maimon]

Doug Barton wrote:



Joe,

In this post, and in your many other posts today, you seem to be
asserting that this would work if "$THEY" would just get out of the way,
and let it work. You've also said explicitly that you believe that this
is an example of top-down dictates. I know you may find this hard to
believe, but neither of these ideas turn out to be accurate. A little
history ...

In 2004 I was the manager of the IANA. Tony Hain came to me and said
that he'd been crunching some numbers and his preliminary research
indicated that the burn rate on IPv4 was increasing fairly dramatically,
and that runout was likely to happen a lot sooner than folks expected it
would. Various people started doing their own research along similar
lines and confirmed Tony's findings.

So amongst many others, I started taking various steps to "get ready"
for IPv4 runout. One of those steps was to talk to folks about the
feasibility of utilizing Class E space. Now keep in mind that I have no
dog in this hunt. I've never been part of an RIR, I've never worked for
a network gear company, I'm a DNS guy. To me, bits are bits.

I was told, universally, that there was no way to make Class E space
work, in the public Internet or private networks (because the latter was
being considered as an expansion of 1918). There are just too many
barriers, not the least of which is the overwhelming number of
person-years it would take to rewrite all the software that has
assumptions about Class E space hard coded.

Further, the vendors we spoke to said that they had no intention of
putting one minute's worth of work into that project, because the ROI
was basically zero. In order for address space to "work" the standard is
universal acceptance ... and that was simply never going to happen.
There are literally hundreds of millions of devices in active use right
now that would never work with Class E space because they cannot be
updated.

Of course it's also true that various folks, particularly the IETF
leadership, were/are very gung ho that IPv6 is the right answer, so any
effort put into making Class E space work is wasted effort; which should
be spent on deploying IPv6. On a *personal* level I agree with that
sentiment, but (to the extent I'm capable of being objective) I didn't
let that feeling color my effort to get an honest answer from the many
folks I talked to about this.

But all that said, nothing is stopping YOU from working on it. :)  The
IETF can't stop you, the vendors can't stop you, no one can stop you ...
if you think you can make it work, by all means, prove us all wrong. :)
  Find some others that agree with you, work on the code, do the
interoperability tests, and present your work. You never know what might
happen.

In the meantime, please stop saying that not using this space was
dictated from the top down, or that any one party/cabal/etc. is holding
you back, because neither of those are accurate.

Good luck,

Doug




Thanks for the this.

To clarify, my criticism of top down is specifically in response to the 
rationale presented that it is a valid objective to prevent, hinder and 
refuse to enable efforts that "compete" with ipv6 world-takeover resources.


I have no intention of using Class E. I have no intention of developing 
code that uses Classe E. I will note that the code involved that is 
publicly searchable appears to be simple and small, the task that is 
large is adoption spread.


But perhaps we can all agree that standards should be accurate and 
should not be used to advance uninvolved agenda. And class E 
experimental status is inaccurate. And keeping that status serves 
nobody, except those who believe it helps marshal efforts away from 
IPv4. And that is top down.


Burn rate is specious. Applying liberally constrained green-field 
burn-rate as a projection of ROI on brownfield space likely to be 
heavily constrained by market force if nothing else is wholly 
inapplicable and inaccurate.


Joe

SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers

[Matthew Huff]

Just ran into this issue this morning. The SEC requires companies to file EDGAR 
reports on https://edgarfiling.sec.gov. The newer versions of Firefox won't let 
you access the webpages without manually going into about:config and 
re-enabling the weak ciphers. Given the recent issue with the OPM, I would 
think this would be a very bad follow-up if the SEC got hacked.

SSLLabs gives the website an "F". IE 11 won't work either (for other reasons).  
https://www.ssllabs.com/ssltest/analyze.html?d=edgarfiling.sec.gov

The website looks like it was designed in the '90s. I've tried to reach out to 
their contacts (webmaster, oig, etc...) but haven't gotten a reply yet. It's 
possible that I might get a reply eventually, but does anyone have any direct 
contacts at the SEC?



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

Re: Speaking of NTP...

[Rafael Possamai]

Depending on how exactly you have these servers configured with relation to
one another, small variations from one single source can be augmented down
the line.

https://en.wikipedia.org/wiki/Propagation_of_uncertainty



On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff  wrote:

> We have 5 NTP server:  2 x stratum 1 rubidium oscillator time servers with
> GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external internet
> based NTP stratum 1 servers. We monitor our NTP environment closely, and
> over the last 10+ years, normally all of our NTP servers are sync'ed within
> +/- 2 msec. Starting last Friday, we started seeing some remote NTP servers
> with GPS reference consistently offset by 10 msec.
>
> Any one else seeing this?
>
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
>
>

RE: Dual stack IPv6 for IPv4 depletion

[Jacques Latour]

Hi,

Dual stack is where we need to go 'now', but we need to think about the future 
where we run an IPv6 only stack and stop thinking how to leverage, extend, 
expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose 
well, thank you. We need a date where IPv4 is no longer routed on the Internet. 
I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the date 
and drive toward a common goal for a better Internet.

My 2 Canadian cents :-)

Jack


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Maimon
> Sent: July-16-15 11:24 AM
> To: Doug Barton; nanog@nanog.org
> Subject: Re: Dual stack IPv6 for IPv4 depletion
> 
> 
> 
> Doug Barton wrote:
> 
> >
> > Joe,
> >
> > In this post, and in your many other posts today, you seem to be
> > asserting that this would work if "$THEY" would just get out of the
> > way, and let it work. You've also said explicitly that you believe
> > that this is an example of top-down dictates. I know you may find this
> > hard to believe, but neither of these ideas turn out to be accurate. A
> > little history ...
> >
> > In 2004 I was the manager of the IANA. Tony Hain came to me and said
> > that he'd been crunching some numbers and his preliminary research
> > indicated that the burn rate on IPv4 was increasing fairly
> > dramatically, and that runout was likely to happen a lot sooner than
> > folks expected it would. Various people started doing their own
> > research along similar lines and confirmed Tony's findings.
> >
> > So amongst many others, I started taking various steps to "get ready"
> > for IPv4 runout. One of those steps was to talk to folks about the
> > feasibility of utilizing Class E space. Now keep in mind that I have
> > no dog in this hunt. I've never been part of an RIR, I've never worked
> > for a network gear company, I'm a DNS guy. To me, bits are bits.
> >
> > I was told, universally, that there was no way to make Class E space
> > work, in the public Internet or private networks (because the latter
> > was being considered as an expansion of 1918). There are just too many
> > barriers, not the least of which is the overwhelming number of
> > person-years it would take to rewrite all the software that has
> > assumptions about Class E space hard coded.
> >
> > Further, the vendors we spoke to said that they had no intention of
> > putting one minute's worth of work into that project, because the ROI
> > was basically zero. In order for address space to "work" the standard
> > is universal acceptance ... and that was simply never going to happen.
> > There are literally hundreds of millions of devices in active use
> > right now that would never work with Class E space because they cannot
> > be updated.
> >
> > Of course it's also true that various folks, particularly the IETF
> > leadership, were/are very gung ho that IPv6 is the right answer, so
> > any effort put into making Class E space work is wasted effort; which
> > should be spent on deploying IPv6. On a *personal* level I agree with
> > that sentiment, but (to the extent I'm capable of being objective) I
> > didn't let that feeling color my effort to get an honest answer from
> > the many folks I talked to about this.
> >
> > But all that said, nothing is stopping YOU from working on it. :)  The
> > IETF can't stop you, the vendors can't stop you, no one can stop you ...
> > if you think you can make it work, by all means, prove us all wrong. :)
> >   Find some others that agree with you, work on the code, do the
> > interoperability tests, and present your work. You never know what
> > might happen.
> >
> > In the meantime, please stop saying that not using this space was
> > dictated from the top down, or that any one party/cabal/etc. is
> > holding you back, because neither of those are accurate.
> >
> > Good luck,
> >
> > Doug
> >
> 
> 
> Thanks for the this.
> 
> To clarify, my criticism of top down is specifically in response to the 
> rationale
> presented that it is a valid objective to prevent, hinder and refuse to enable
> efforts that "compete" with ipv6 world-takeover resources.
> 
> I have no intention of using Class E. I have no intention of developing code 
> that
> uses Classe E. I will note that the code involved that is publicly searchable
> appears to be simple and small, the task that is large is adoption spread.
> 
> But perhaps we can all agree that standards should be accurate and should not
> be used to advance uninvolved agenda. And class E experimental status is
> inaccurate. And keeping that status serves nobody, except those who believe it
> helps marshal efforts away from IPv4. And that is top down.
> 
> Burn rate is specious. Applying liberally constrained green-field burn-rate 
> as a
> projection of ROI on brownfield space likely to be heavily constrained by
> market force if nothing else is wholly inapplicable and inaccurate.
> 
> Joe

Re: Dual stack IPv6 for IPv4 depletion

[Barry Shein]

Yeah wow 127/8, that one always amazed me, 16M addrs because it was
computationally cheap to test for ((0x7f & addr) == 0x7f).

I wonder what are the most 127.* addrs ever used by one site? I know
there are some schemes which blackhole to 127.0.0.n incrementing n so
the number of hits on each blackhole can be counted separately (more
or less) but 16M? I doubt even 254 were used in those schemes very
often.

WWWT? (What Were We Thinking?)

Oh well water under the bridge.

On July 15, 2015 at 17:53 jfb...@gmail.com (Ricky Beam) wrote:
 > On Wed, 15 Jul 2015 17:34:13 -0400, Owen DeLong  wrote:
 > > That covers multicast and RFC-1918. Are there any other IPv4  
 > > segmentations that you can think of?
 > ...
 > > Given that we came up with 3 total segmentations in IPv4 over the course
 > 
 > #1-3,#4 RFC-1918 is 3 "segments" and we recently added a 4th (for CGN).
 > #5 Localhost (127/8)
 > #6 Multicast (224/4)
 > #7 "Class E" (240/4)
 > #8 0/8
 > #9 255/8 (technically, part of class e, but it's called out specifically  
 > in various RFCs)

-- 
-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: 'gray' market IPv4

[Bryan Fields]

On 7/15/15 9:59 AM, Lee Howard wrote:
> Price varies significantly by prefix length, and somewhat by region.
> Regional variance may not be as much as it used to be.

Does legacy space command a premium in this?

What's the going rate to lease space (say a /20 or /19 for discussion)?

-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net

Re: Dual stack IPv6 for IPv4 depletion

[Lee Howard]

On 7/16/15, 11:24 AM, "NANOG on behalf of Joe Maimon"
 wrote:

>
>
>To clarify, my criticism of top down is specifically in response to the
>rationale presented that it is a valid objective to prevent, hinder and
>refuse to enable efforts that "compete" with ipv6 world-takeover
>resources.

I don¹t see anybody hindering any efforts; I don¹t see any efforts.

>
>I have no intention of using Class E. I have no intention of developing
>code that uses Classe E. I will note that the code involved that is
>publicly searchable appears to be simple and small, the task that is
>large is adoption spread.

So this argument is moot?

>
>But perhaps we can all agree that standards should be accurate and
>should not be used to advance uninvolved agenda. And class E
>experimental status is inaccurate. And keeping that status serves
>nobody, except those who believe it helps marshal efforts away from
>IPv4. And that is top down.

So, you would like to update RFC 1112, which defines and reserves Class E?
That¹s easy enough. If somebody had a use in mind for the space, anybody
can write such a draft assigning space, which is, I believe, how to
direct IANA to do something with it.

If you want to direct IANA to distribute Class E space among the RIRs,
there¹s more process, because you would also have to develop a global
policy (no problem, we get the NRO NC to write it and get consensus at
all the RIRs), and then each RIR would need to develop a policy under
which to allocate it. I¹d be surprised if all that could happen in
less than three years.

In any of these processes, nothing will move forward until there is
consensus, and I don¹t think there¹s consensus. If you think your
argument can be persuasive, let¹s write an internet-draft and get it
into the process.

Lee

>
>Joe
>

Re: 'gray' market IPv4

[Lee Howard]

On 7/16/15, 12:47 PM, "NANOG on behalf of Bryan Fields"
 wrote:

>On 7/15/15 9:59 AM, Lee Howard wrote:
>> Price varies significantly by prefix length, and somewhat by region.
>> Regional variance may not be as much as it used to be.
>
>Does legacy space command a premium in this?

>From what I understand, and I have not been a party to any transactions,
there are differences in transaction where the space looks ³cleaner.² That
is, space that has been less delegated, and has never appeared an a spam
blacklist. I don¹t know whether that translates to higher prices, or
whether buyers just won¹t buy questionable space.

>
>What's the going rate to lease space (say a /20 or /19 for discussion)?

Leases aren¹t worth the trouble, because sellers believe that the only
reason for a temporary lease is to originate spam, following which the
address space is worthless. So if you can find a lease at all, it is
likely to cost as much or more than buying outright. Personally, I
wouldn¹t lease space at all, because I wouldn¹t want my organization¹s
name anywhere near it when the bad stuff started happening.
The ipv4auctions.com site lists prefixes that large; recent /20s have been
$7.45-$8.00 per address.

Bear in mind that I¹m essentially a researcher, and have no direct
experience. You might want to talk to a broker or three.

Lee

>
>-- 
>Bryan Fields
>
>727-409-1194 - Voice
>727-214-2508 - Fax
>http://bryanfields.net
>

RE: Speaking of NTP...

[Tony Hain]

I have had a consistent 10ms offset on a set of servers for the last 5 years. 
After extensive one-way tracing, it turns out there is a 20ms asymmetry 
"within" the Seattle Westin colo between HE & Comcast, causing all the IPv6 
peers appearing over the HE tunnel to be 10ms offset from everything else. 
There may be other instances of indirect peering causing a static asymmetric 
path delay, and NTP will report that as an offset of half of the difference. 

Tony


> -Original Message-
> From: NANOG [mailto:nanog-bounces+alh-ietf=tndh@nanog.org] On
> Behalf Of Rafael Possamai
> Sent: Thursday, July 16, 2015 8:53 AM
> To: Matthew Huff
> Cc: nanog@nanog.org
> Subject: Re: Speaking of NTP...
> 
> Depending on how exactly you have these servers configured with relation
> to one another, small variations from one single source can be augmented
> down the line.
> 
> https://en.wikipedia.org/wiki/Propagation_of_uncertainty
> 
> 
> 
> On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff  wrote:
> 
> > We have 5 NTP server:  2 x stratum 1 rubidium oscillator time servers
> > with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external
> > internet based NTP stratum 1 servers. We monitor our NTP environment
> > closely, and over the last 10+ years, normally all of our NTP servers
> > are sync'ed within
> > +/- 2 msec. Starting last Friday, we started seeing some remote NTP
> > +servers
> > with GPS reference consistently offset by 10 msec.
> >
> > Any one else seeing this?
> >
> > 
> > Matthew Huff | 1 Manhattanville Rd
> > Director of Operations   | Purchase, NY 10577
> > OTA Management LLC   | Phone: 914-460-4039
> > aim: matthewbhuff| Fax:   914-694-5669
> >
> >

Re: Speaking of NTP...

[Matthew Huff]

Thanks. We have always had a few outliers, but we have never had a large number 
of external NTP have a consistent offset, and not one as big as 10ms. Something 
changed last Friday, probably at some peering point that caused the issue. 
Maybe a symmetric path got created to route around some outage. Maybe some MPLS 
circuit got introduced into the mix that hides the underlying path/latency. 
Glad to know someone else has seen something like this.

Our 3 NTP servers that sync from external sources have at least 5 upstream 
stratum 1 servers and are peered to each other . They have settled on  a sense 
of time that is good within +/i 1 msec of our strata 1 clocks, so all is good, 
but it was a stage occurrence after we had been good for so long. Each of our 
servers are clients of our 2 x strata 1 servers and 3 x strata 2 NTP servers. 
They all look good now.

 


> On Jul 16, 2015, at 3:24 PM, Tony Hain  wrote:
> 
> I have had a consistent 10ms offset on a set of servers for the last 5 years. 
> After extensive one-way tracing, it turns out there is a 20ms asymmetry 
> "within" the Seattle Westin colo between HE & Comcast, causing all the IPv6 
> peers appearing over the HE tunnel to be 10ms offset from everything else. 
> There may be other instances of indirect peering causing a static asymmetric 
> path delay, and NTP will report that as an offset of half of the difference. 
> 
> Tony
> 
> 
>> -Original Message-
>> From: NANOG [mailto:nanog-bounces+alh-ietf=tndh@nanog.org] On
>> Behalf Of Rafael Possamai
>> Sent: Thursday, July 16, 2015 8:53 AM
>> To: Matthew Huff
>> Cc: nanog@nanog.org
>> Subject: Re: Speaking of NTP...
>> 
>> Depending on how exactly you have these servers configured with relation
>> to one another, small variations from one single source can be augmented
>> down the line.
>> 
>> https://en.wikipedia.org/wiki/Propagation_of_uncertainty
>> 
>> 
>> 
>> On Mon, Jul 13, 2015 at 8:17 AM, Matthew Huff  wrote:
>> 
>>> We have 5 NTP server:  2 x stratum 1 rubidium oscillator time servers
>>> with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to external
>>> internet based NTP stratum 1 servers. We monitor our NTP environment
>>> closely, and over the last 10+ years, normally all of our NTP servers
>>> are sync'ed within
>>> +/- 2 msec. Starting last Friday, we started seeing some remote NTP
>>> +servers
>>> with GPS reference consistently offset by 10 msec.
>>> 
>>> Any one else seeing this?
>>> 
>>> 
>>> Matthew Huff | 1 Manhattanville Rd
>>> Director of Operations   | Purchase, NY 10577
>>> OTA Management LLC   | Phone: 914-460-4039
>>> aim: matthewbhuff| Fax:   914-694-5669
>>> 
>>> 
> 

Re: Dual stack IPv6 for IPv4 depletion

[Joe Maimon]

Jacques Latour wrote:

Hi,

Dual stack is where we need to go 'now', but we need to think about the future 
where we run an IPv6 only stack and stop thinking how to leverage, extend, 
expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose 
well, thank you. We need a date where IPv4 is no longer routed on the Internet. 
I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the date 
and drive toward a common goal for a better Internet.

My 2 Canadian cents :-)

Jack



Just as nobody is preventing you from going ipv6 only right now, I 
advocate against hindering anybody going ipv4 only for as long as they 
want/can.


You may not like the results, but that does not make a top down approach 
any better a choice.


Joe

Re: Dual stack IPv6 for IPv4 depletion

[Joe Maimon]

Lee Howard wrote:



I don¹t see anybody hindering any efforts; I don¹t see any efforts.


There were efforts in the past. I am highlighting our malfeasance as a 
community in our past behavior. I have little hope of it changing in the 
future, but I can vent about it every couple years or so.


You take the un-initiated and explain to them the actual utilization 
percentage of the bitspace and then you explain why they should trust us 
with bitspace management the second time around.





So, you would like to update RFC 1112, which defines and reserves Class E?
That¹s easy enough. If somebody had a use in mind for the space, anybody
can write such a draft assigning space, which is, I believe, how to
direct IANA to do something with it.



nope

http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/

All the same rationals, including how it might be bad for ipv6, its too 
late, its too hard, its too little were trotted out then, just as now.


The only use I have in mind for the space is for it to cease being 
classified as experimental and therefore treated as invalid.



If you want to direct IANA to distribute Class E space among the RIRs,
there¹s more process, because you would also have to develop a global
policy (no problem, we get the NRO NC to write it and get consensus at
all the RIRs), and then each RIR would need to develop a policy under
which to allocate it. I¹d be surprised if all that could happen in
less than three years.


I would not care about that, so long as the impediment, the experimental 
status was removed. Let the stakeholders have a real shot.




In any of these processes, nothing will move forward until there is
consensus, and I don¹t think there¹s consensus. If you think your
argument can be persuasive, let¹s write an internet-draft and get it
into the process.

Lee



Joe

Re: Dual stack IPv6 for IPv4 depletion

[Mark Andrews]

In message <55a812a1.6020...@ttec.com>, Joe Maimon writes:
> 
> 
> Jacques Latour wrote:
> > Hi,
> >
> > Dual stack is where we need to go 'now', but we need to think about the fut
> ure where we run an IPv6 only stack and stop thinking how to leverage, extend
> , expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose 
> well, thank you. We need a date where IPv4 is no longer routed on the Interne
> t. I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the d
> ate and drive toward a common goal for a better Internet.
> >
> > My 2 Canadian cents :-)
> >
> > Jack
> >
> 
> Just as nobody is preventing you from going ipv6 only right now, I 
> advocate against hindering anybody going ipv4 only for as long as they 
> want/can.

There is nothing stopping you experimenting with class E addresses
behind a NAT.  Talk to your vendors to lift the restrictions and
route the packets as unicast packets.  Note this really doesn't
help with the global shortage.

> You may not like the results, but that does not make a top down approach 
> any better a choice.

Turning Class E into global unicast is nearly as big a project as
getting IPv6 deployed everywhere.  There is lots of equipement that
can't make the jump.  Even starting 15 years ago we would still not
be in a good faith position to hand the addresses out to be used
by anyone to talk to anyone.  Both end boxes have to support it and
all the routers in between have to support it.  It's not just about
being able to assign the address locally.  Its about everything
involed in the path being able to route to/from the addresses.

Keeping IPv4 going longer required more publically routeable IPv4
space and class E was never it.

> Joe
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

IPv6 CPE best practices

[Chuck Church]

So, I've been following this IPv6 discussion for a while now.  Putting much
more thought into it than ever before.  What I've gathered so far:

 

We need both SLAAC and DHPCv6 on CPE router to support all end clients.
Android and some other platforms still have some issues with a v6-addressed
DNS server (or don't use DHCPv6 at all), so you really need your
v4-addressed DNS server to hand out both  and A records together.  Is
that close?

 

So giving each customer a /48 is the way to go.  How does one go about
configuring CPEs for devices to use this?  I'm aware of how DHCP-PD can dish
out a /48 of a larger block.  Should I move to a standard CPE that supports
DHCP-PD (here is a list:  https://getipv6.info/display/IPv6/Broadband+CPE ,
some mention PD)?  Or should I just allow them to use any IPv6 compatible
router, and issue each customer a /48, but only configure a /64 of that
block for each CPE's inside interface (manual config).  Is there anything
other than DHCP-PD that can do this auto-magically?

 

I support a small WISP occasionally, it's all wireless and Ethernet.
Several hundred small business customers.  Nothing super complicated.  Been
playing with an HE tunnel the last few days and found my netflow collector
works fine with FNF and IPv6, so making some progress.  Just wanting to
avoid any big mistakes when we think about getting some customers on it.

 

Thanks,

 

Chuck

 

Re: Dual stack IPv6 for IPv4 depletion

[John Levine]

>Just as nobody is preventing you from going ipv6 only right now, I 
>advocate against hindering anybody going ipv4 only for as long as they 
>want/can.

Nobody's hindering you.  You can get NAT boxes of all shapes and sizes.

If you want to mess around with class E addresses on your own network,
go ahead, nobody's hindering you there, either.

But you're asking other people to spend their own time and money to
change their equipment to handle class E.  For reasons discussed at
length, no.

If you're offering to pay their costs, on the other hand, ...

R's,
John

Re: IPv6 CPE best practices

[Mark Andrews]

In message <02d301d0c012$b4f39130$1edab390$@gmail.com>, "Chuck Church" writes:
> So, I've been following this IPv6 discussion for a while now.  Putting much
> more thought into it than ever before.  What I've gathered so far:
> 
>  
> 
> We need both SLAAC and DHPCv6 on CPE router to support all end clients.

Yep.

> Android and some other platforms still have some issues with a v6-addressed
> DNS server (or don't use DHCPv6 at all), so you really need your
> v4-addressed DNS server to hand out both  and A records together.  Is
> that close?

Only for really old clients or stupid clients that don't support
both.  DHCPv6 has supported handing out nameserver addresses for
over a decade (2003) so all clients SHOULD support this.  RDNSS was
only defined in 2010.

> So giving each customer a /48 is the way to go.  How does one go about
> configuring CPEs for devices to use this?  I'm aware of how DHCP-PD can dish
> out a /48 of a larger block.

The DHCPv6 client on the upstream interface requests a PD.

> Should I move to a standard CPE that supports
> DHCP-PD (here is a list:  https://getipv6.info/display/IPv6/Broadband+CPE ,
> some mention PD)?  Or should I just allow them to use any IPv6 compatible
> router, and issue each customer a /48, but only configure a /64 of that
> block for each CPE's inside interface (manual config).  Is there anything
> other than DHCP-PD that can do this auto-magically?

The CPE divides the /48 up for local use and further assignment via
PD from its DHCP server.  If there is a CPE to old to do this you
may need to do manual assignment.  Your DHCP server should be able
to do both static and automatic PD.

Also see the homenet IETF working group.  It is working on providing
a standard home route that does this and source/destination based
routing so that homes can have multiple PA prefixes with traffic
going out the correct exit.  There are OpenWrt based routers that
implement this today.

Business class routers may not support fetching the prefix delegation
via PD but they are usually paying you more.

> I support a small WISP occasionally, it's all wireless and Ethernet.
> Several hundred small business customers.  Nothing super complicated.  Been
> playing with an HE tunnel the last few days and found my netflow collector
> works fine with FNF and IPv6, so making some progress.  Just wanting to
> avoid any big mistakes when we think about getting some customers on it.
> 
>  
> 
> Thanks,
> 
>  
> 
> Chuck
> 
>  
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Dual stack IPv6 for IPv4 depletion

[Joe Maimon]

John Levine wrote:

Just as nobody is preventing you from going ipv6 only right now, I
advocate against hindering anybody going ipv4 only for as long as they
want/can.






But you're asking other people to spend their own time and money to
change their equipment to handle class E.  For reasons discussed at
length, no.


All I am advocating is that if ever another draft standard comes along 
to enable people to try and make something of it, lead follow or get out 
of the way.




If you're offering to pay their costs, on the other hand, ...

R's,
John

Re: Dual stack IPv6 for IPv4 depletion

[Baldur Norddahl]

On 17 July 2015 at 00:29, Joe Maimon  wrote:

> All I am advocating is that if ever another draft standard comes along to
> enable people to try and make something of it, lead follow or get out of
> the way.
>

If I understand correctly you want someone (not you) to write a RFC that
changes the word "experimental" to "something else". But you do not want
IANA and the 5 RIRs to implement policies to hand out this space. Nor do
you expect any vendor to change anything?

May i then suggest that "something else" could be "junk" or "useless" ?

Fact is that it is junk. It is probably not even routable in the default
free zone.

Nobody is going to want a class E address. Even if your own equipment was
updated to allow it, you would not be able to communicate with most of the
internet. Tell me, in what timeframe do you expect that would change, if
someone did write that RFC and got it approved?

What everyone here is trying to tell you is that the consensus is that
timeframe would be very long indeed. There are people using routers with
10+ year old firmware and you just wouldn't be able to communicate with
these guys. There would be no transition plan. No NAT64, no dualstack nor
any other mechanism that would save the day. Your customers would be very
unhappy with your service.

If YouTube had their servers on a class E address, my smart TV would stop
being able to play YouTube. Samsung stopped making updates to that TV long
ago. NAT wont do anything to help my TV as NAT only maps my internal
network (192.168.x.y) and not the external IP (the class E address of say
YouTube).

Lets say we declare that 10 years has to pass and then it is my problem if
I am still hanging onto such an old TV. But honestly, in 10 years nobody is
going to care. It is all IPv6 by then. And the few things that are not is
all taken care of by various transition technologies.

You got it all wrong when you believe it is a top down decision. It is the
opposite. You are fighting _consensus_. Nobody wants to change the status
of class E because it would not work and would only confuse.

Regards,

Baldur

RE: Remember "Internet-In-A-Box"?

[Keith Medcalf]

Internet in a box.

Wasn't that the Japanese thing with the Woody Woodpecker logo and the 
(translated) English text:  "Touch Woody, the Internet pecker"?

Didn't go over to well in English speaking parts as I recall ...

Re: Remember "Internet-In-A-Box"?

[Ricky Beam]

On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews  wrote:

You can blame the religious zealots that insisted that everything
DHCP does has to also be done via RA's.


I blame the anti-DHCP crowd for a lot of things. RAs are just dumb.  
There's a reason IPv4 can do *everything* through DHCP -- hell, even boot  
menu lists are sent in dhcp pakcets.



The XP box is in an even worse situation if you try to run it on a
v6-only network.


Which is fixable with a third party DHCPv6 client / manual configuration
of the nameservers.


Just like no "IP stack" was fixable in the 80's. No. Just, No. There are  
millions upon millions of internet users I wouldn't trust to double click  
setup.exe.



None of which is the fault of the protocol.


Actually, it's 100% the fault of the protocol. IPv6-only networking has  
been a cluster-f*** from day one. And it still doesn't f'ing work today.  
Until there is *A* standard to implement, that stands still for more than  
an hour before something else "critical" gets bolted on to it, people are  
going to continue to ignore IPv6.


Yes, my XP machines work fine with IPv6... on a network using SLAAC, where  
IPv4 (DHCPv4) is still enabled and providing the various bits necessary to  
do anything other than ping my gateway.

Re: Remember "Internet-In-A-Box"?

[Dave Pooser]

>Internet in a box.
>
>Wasn't that the Japanese thing with the Woody Woodpecker logo and the
>(translated) English text:  "Touch Woody, the Internet pecker"?
>
>Didn't go over to well in English speaking parts as I recall ...

But it eventually evolved into ChatRoulette.
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com

Re: Dual stack IPv6 for IPv4 depletion

[Valdis . Kletnieks]

On Thu, 16 Jul 2015 18:29:48 -0400, Joe Maimon said:

> All I am advocating is that if ever another draft standard comes along
> to enable people to try and make something of it, lead follow or get out
> of the way.

The problem is that if everybody gets out of the way and doesn't follow,
your class E address is still *worthless*, because only "lead" and "follow"
result in people updating their gear to support it.

As I sit here:

traceroute -A www.ttec.com
traceroute to www.ttec.com (216.222.148.100), 30 hops max, 60 byte packets
 1  gateway (172.30.42.65) [*]  1.572 ms  1.942 ms  3.574 ms
 2  73.171.122.1 (73.171.122.1) [AS7922]  12.148 ms  17.771 ms  18.312 ms
 3  68.86.127.121 (68.86.127.121) [AS7922]  16.262 ms  21.193 ms  22.037 ms
 4  ae-18-0-ar02.charlvilleco.va.richmond.comcast.net (68.86.173.213) [AS7922]  
40.610 ms  27.332 ms  27.655 ms
 5  he-1-1-0-0-10-cr02.ashburn.va.ibone.comcast.net (68.86.91.53) [AS7922]  
34.854 ms he-1-1-0-3-11-cr02.ashburn.va.ibone.comcast.net (68.86.94.21) 
[AS7922]  36.627 ms he-1-1-0-1-11-cr02.ashburn.va.ibone.comcast.net 
(68.86.95.69) [AS7922]  33.868 ms
 6  he-0-10-0-1-pe07.ashburn.va.ibone.comcast.net (68.86.83.70) [AS7922]  
32.243 ms  16.216 ms  27.123 ms
 7  50-248-119-82-static.hfc.comcastbusiness.net (50.248.119.82) [AS7922]  
27.405 ms  33.886 ms  43.109 ms
 8  100ge5-1.core1.nyc4.he.net (184.105.223.166) [AS6939]  36.571 ms  37.881 ms 
 37.290 ms
 9  209.51.164.26 (209.51.164.26) [AS6939]  40.093 ms 209.51.164.27 
(209.51.164.27) [AS6939]  38.234 ms 209.51.164.26 (209.51.164.26) [AS6939]  
38.647 ms
10  noc08rt08-p1-16.noc08.chl.net (216.222.144.33) [AS21719]  46.120 ms  46.462 
ms  42.743 ms
11  * * *
12  webserver.ntcnct.net (216.222.148.100) [AS21719]  33.937 ms  28.058 ms  
30.344 ms

You're on the hook for 3 boxes.  Can you get the software vendors for all three
to *not* be in "get out of the way"? (Remember how many years a lot of vendors
spent playing "get out of the way" on IPv6 support, and how many are still
doing it *now*...)  Oh, and don't forget whatever webserver software and web
authoring/management software...

And the 9 boxes in between apparently belong to Comcast and HE, both of which
have drunk the IPv6 koolaid.  What's the business case for them to add Class E
support to their networks?

Yeah.  There's a whole lot of motivation to get out of the way here, because
most of the path thinks IPv6 is the right answer,  and not much business case
for any of the companies or vendors to either lead or follow on a class E
repurposing...







pgpPSSU6KU2Vy.pgp
Description: PGP signature

Re: Dual stack IPv6 for IPv4 depletion

[Lee Howard]

On 7/16/15, 4:32 PM, "Joe Maimon"  wrote:

>
>
>Lee Howard wrote:
>>
>> So, you would like to update RFC 1112, which defines and reserves Class
>>E?
>> That¹s easy enough. If somebody had a use in mind for the space, anybody
>> can write such a draft assigning space, which is, I believe, how to
>> direct IANA to do something with it.
>>
>
>nope

“Nope?”
You mean you don’t want to update RFC1112?
Or it’s not possible for somebody to write a draft telling IANA to assign
space
for an experiment? Somebody has to write a draft in order for the IETF to
consider it, and there has to be IETF consensus for it to get published as
an
RFC. 

>
>http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-
>addresses/
>
>All the same rationals, including how it might be bad for ipv6, its too
>late, its too hard, its too little were trotted out then, just as now.

I don’t see the relevance. Nobody there proposed reclassifying the space.
Nobody had a proposal for an experiment. Nobody wanted an assignment from
it.


>
>The only use I have in mind for the space is for it to cease being
>classified as experimental and therefore treated as invalid.

You want the word “RESERVED” for some entries on this page changed:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
What do you want it changed to?

>
>> If you want to direct IANA to distribute Class E space among the RIRs,
>> there¹s more process, because you would also have to develop a global
>> policy (no problem, we get the NRO NC to write it and get consensus at
>> all the RIRs), and then each RIR would need to develop a policy under
>> which to allocate it. I¹d be surprised if all that could happen in
>> less than three years.
>
>I would not care about that, so long as the impediment, the experimental
>status was removed. Let the stakeholders have a real shot.

There’s more to it than that.
How would people who want to use it get assignments?
Right now, there’s no policy for assigning that space.


You’ve told other people that there shouldn’t be a top-down restriction on
this space; but there’s no top: it’s all consensus. The consensus here is
very clear. You are welcome to try to change it, and a couple of us are
trying to should you the processes (IETF, IANA, RIR) to do that.


If all you want to do is vent, we’ll just move on to another thread.

Lee

Re: Dual stack IPv6 for IPv4 depletion

[Owen DeLong]

> On Jul 16, 2015, at 15:29 , Joe Maimon  wrote:
> 
> 
> 
> John Levine wrote:
>>> Just as nobody is preventing you from going ipv6 only right now, I
>>> advocate against hindering anybody going ipv4 only for as long as they
>>> want/can.
> 
> 
> 
>> 
>> But you're asking other people to spend their own time and money to
>> change their equipment to handle class E.  For reasons discussed at
>> length, no.
> 
> All I am advocating is that if ever another draft standard comes along to 
> enable people to try and make something of it, lead follow or get out of the 
> way.

Sometimes good leadership is knowing when to say “not just no, but hell no.”

Owen

Prefix-Hijack by AS7514

[Jürgen Jaritsch]

Hi,

does anyone else see some prefix hijacks from AS7514? They started to announce 
some of our /24 


Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Re: Prefix-Hijack by AS7514

[Hugo Slabbert]

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being 
accepted by 2497.


--
Hugo Slabbert
Stargate Connections - AS19171

-Original Message-

Date: Fri, 17 Jul 2015 06:15:36 +
From: Jürgen Jaritsch 
To: "'nanog@nanog.org'" 
Subject: Prefix-Hijack by AS7514

Hi,

does anyone else see some prefix hijacks from AS7514? They started to announce 
some of our /24 


Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

AW: Prefix-Hijack by AS7514

[Jürgen Jaritsch]

We already informed AS2497 but I have no idea if they we'll cooperate.


Best regards


Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at 
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] 
Gesendet: Freitag, 17. Juli 2015 08:23
An: Jürgen Jaritsch 
Cc: 'nanog@nanog.org' 
Betreff: Re: Prefix-Hijack by AS7514

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being 
accepted by 2497.

--
Hugo Slabbert
Stargate Connections - AS19171

-Original Message-
>Date: Fri, 17 Jul 2015 06:15:36 +
>From: Jürgen Jaritsch 
>To: "'nanog@nanog.org'" 
>Subject: Prefix-Hijack by AS7514
>
>Hi,
>
>does anyone else see some prefix hijacks from AS7514? They started to announce 
>some of our /24 
>
>
>Thanks & best regards
>
>Jürgen Jaritsch
>Head of Network & Infrastructure
>
>ANEXIA Internetdienstleistungs GmbH
>
>Telefon: +43-5-0556-300
>Telefax: +43-5-0556-500
>
>E-Mail: j...@anexia.at
>Web: http://www.anexia.at
>
>Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>Geschäftsführer: Alexander Windbichler
>Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>

Re: Prefix-Hijack by AS7514

[Hank Nussbacher]

At 06:15 17/07/2015 +, Jürgen Jaritsch wrote:

Hi,

does anyone else see some prefix hijacks from AS7514? They started to 
announce some of our /24 


Worldwide.

-Hank




Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Re: AW: Prefix-Hijack by AS7514

[Seiichi Kawamura]

I contacted 7514. They are aware.

-Seiichi

On 2015/07/17 15:23, Jürgen Jaritsch wrote:
> We already informed AS2497 but I have no idea if they we'll cooperate.
> 
> 
> Best regards
> 
> 
> Jürgen Jaritsch
> Head of Network & Infrastructure
> 
> ANEXIA Internetdienstleistungs GmbH
> 
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
> 
> E-Mail: j...@anexia.at 
> Web: http://www.anexia.at
> 
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
> Geschäftsführer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
> 
> -Ursprüngliche Nachricht-
> Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] 
> Gesendet: Freitag, 17. Juli 2015 08:23
> An: Jürgen Jaritsch 
> Cc: 'nanog@nanog.org' 
> Betreff: Re: Prefix-Hijack by AS7514
> 
> Seeing the same; a /19.
> 
> BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being 
> accepted by 2497.
> 
> --
> Hugo Slabbert
> Stargate Connections - AS19171
> 
> -Original Message-
>> Date: Fri, 17 Jul 2015 06:15:36 +
>> From: Jürgen Jaritsch 
>> To: "'nanog@nanog.org'" 
>> Subject: Prefix-Hijack by AS7514
>>
>> Hi,
>>
>> does anyone else see some prefix hijacks from AS7514? They started to 
>> announce some of our /24 
>>
>>
>> Thanks & best regards
>>
>> Jürgen Jaritsch
>> Head of Network & Infrastructure
>>
>> ANEXIA Internetdienstleistungs GmbH
>>
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>>
>> E-Mail: j...@anexia.at
>> Web: http://www.anexia.at
>>
>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>> Geschäftsführer: Alexander Windbichler
>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>>
> 

AW: AW: Prefix-Hijack by AS7514

[Jürgen Jaritsch]

Hi,

we also sent them an mail, but their MX is not reachable for us :(


best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at 
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp] 
Gesendet: Freitag, 17. Juli 2015 08:29
An: Jürgen Jaritsch ; Hugo Slabbert 
Cc: 'nanog@nanog.org' 
Betreff: Re: AW: Prefix-Hijack by AS7514

I contacted 7514. They are aware.

-Seiichi

On 2015/07/17 15:23, Jürgen Jaritsch wrote:
> We already informed AS2497 but I have no idea if they we'll cooperate.
> 
> 
> Best regards
> 
> 
> Jürgen Jaritsch
> Head of Network & Infrastructure
> 
> ANEXIA Internetdienstleistungs GmbH
> 
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
> 
> E-Mail: j...@anexia.at 
> Web: http://www.anexia.at
> 
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
> Geschäftsführer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
> 
> -Ursprüngliche Nachricht-
> Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] 
> Gesendet: Freitag, 17. Juli 2015 08:23
> An: Jürgen Jaritsch 
> Cc: 'nanog@nanog.org' 
> Betreff: Re: Prefix-Hijack by AS7514
> 
> Seeing the same; a /19.
> 
> BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being 
> accepted by 2497.
> 
> --
> Hugo Slabbert
> Stargate Connections - AS19171
> 
> -Original Message-
>> Date: Fri, 17 Jul 2015 06:15:36 +
>> From: Jürgen Jaritsch 
>> To: "'nanog@nanog.org'" 
>> Subject: Prefix-Hijack by AS7514
>>
>> Hi,
>>
>> does anyone else see some prefix hijacks from AS7514? They started to 
>> announce some of our /24 
>>
>>
>> Thanks & best regards
>>
>> Jürgen Jaritsch
>> Head of Network & Infrastructure
>>
>> ANEXIA Internetdienstleistungs GmbH
>>
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>>
>> E-Mail: j...@anexia.at
>> Web: http://www.anexia.at
>>
>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>> Geschäftsführer: Alexander Windbichler
>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>>
> 

Re: AW: Prefix-Hijack by AS7514

[Hank Nussbacher]

At 06:23 17/07/2015 +, Jürgen Jaritsch wrote:

We already informed AS2497 but I have no idea if they we'll cooperate.


All prefixes I see have the first octet as being 2 digits rather than 
3.  That is common among about 30 different alerts I have 
received.  Curious if this is common worldwide.


-Hank



Best regards


Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Hugo Slabbert [mailto:hslabb...@stargate.ca]
Gesendet: Freitag, 17. Juli 2015 08:23
An: Jürgen Jaritsch 
Cc: 'nanog@nanog.org' 
Betreff: Re: Prefix-Hijack by AS7514

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being
accepted by 2497.

--
Hugo Slabbert
Stargate Connections - AS19171

-Original Message-
>Date: Fri, 17 Jul 2015 06:15:36 +
>From: Jürgen Jaritsch 
>To: "'nanog@nanog.org'" 
>Subject: Prefix-Hijack by AS7514
>
>Hi,
>
>does anyone else see some prefix hijacks from AS7514? They started to 
announce some of our /24 

>
>
>Thanks & best regards
>
>Jürgen Jaritsch
>Head of Network & Infrastructure
>
>ANEXIA Internetdienstleistungs GmbH
>
>Telefon: +43-5-0556-300
>Telefax: +43-5-0556-500
>
>E-Mail: j...@anexia.at
>Web: http://www.anexia.at
>
>Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>Geschäftsführer: Alexander Windbichler
>Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
U63216601

>

AW: AW: Prefix-Hijack by AS7514

[Jürgen Jaritsch]

Hi,

all affected prefixes starts with 37... no other prefixes from AS42473 are 
affected.


Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at 
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Hank Nussbacher [mailto:h...@efes.iucc.ac.il] 
Gesendet: Freitag, 17. Juli 2015 08:33
An: Jürgen Jaritsch ; Hugo Slabbert 
Cc: 'nanog@nanog.org' 
Betreff: Re: AW: Prefix-Hijack by AS7514

At 06:23 17/07/2015 +, Jürgen Jaritsch wrote:
>We already informed AS2497 but I have no idea if they we'll cooperate.

All prefixes I see have the first octet as being 2 digits rather than 
3.  That is common among about 30 different alerts I have 
received.  Curious if this is common worldwide.

-Hank


>Best regards
>
>
>Jürgen Jaritsch
>Head of Network & Infrastructure
>
>ANEXIA Internetdienstleistungs GmbH
>
>Telefon: +43-5-0556-300
>Telefax: +43-5-0556-500
>
>E-Mail: j...@anexia.at
>Web: http://www.anexia.at
>
>Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>Geschäftsführer: Alexander Windbichler
>Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>
>-Ursprüngliche Nachricht-
>Von: Hugo Slabbert [mailto:hslabb...@stargate.ca]
>Gesendet: Freitag, 17. Juli 2015 08:23
>An: Jürgen Jaritsch 
>Cc: 'nanog@nanog.org' 
>Betreff: Re: Prefix-Hijack by AS7514
>
>Seeing the same; a /19.
>
>BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being
>accepted by 2497.
>
>--
>Hugo Slabbert
>Stargate Connections - AS19171
>
>-Original Message-
> >Date: Fri, 17 Jul 2015 06:15:36 +
> >From: Jürgen Jaritsch 
> >To: "'nanog@nanog.org'" 
> >Subject: Prefix-Hijack by AS7514
> >
> >Hi,
> >
> >does anyone else see some prefix hijacks from AS7514? They started to 
> announce some of our /24 
> >
> >
> >Thanks & best regards
> >
> >Jürgen Jaritsch
> >Head of Network & Infrastructure
> >
> >ANEXIA Internetdienstleistungs GmbH
> >
> >Telefon: +43-5-0556-300
> >Telefax: +43-5-0556-500
> >
> >E-Mail: j...@anexia.at
> >Web: http://www.anexia.at
> >
> >Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
> >Geschäftsführer: Alexander Windbichler
> >Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
> U63216601
> >

Re: AW: AW: Prefix-Hijack by AS7514

[Paul S.]

I let IIJ know too, hopefully they'll filter it soon.

On 7/17/2015 午後 03:30, Jürgen Jaritsch wrote:

Hi,

we also sent them an mail, but their MX is not reachable for us :(


best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp]
Gesendet: Freitag, 17. Juli 2015 08:29
An: Jürgen Jaritsch ; Hugo Slabbert 
Cc: 'nanog@nanog.org' 
Betreff: Re: AW: Prefix-Hijack by AS7514

I contacted 7514. They are aware.

-Seiichi

On 2015/07/17 15:23, Jürgen Jaritsch wrote:

We already informed AS2497 but I have no idea if they we'll cooperate.


Best regards


Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: Hugo Slabbert [mailto:hslabb...@stargate.ca]
Gesendet: Freitag, 17. Juli 2015 08:23
An: Jürgen Jaritsch 
Cc: 'nanog@nanog.org' 
Betreff: Re: Prefix-Hijack by AS7514

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being
accepted by 2497.

--
Hugo Slabbert
Stargate Connections - AS19171

-Original Message-

Date: Fri, 17 Jul 2015 06:15:36 +
From: Jürgen Jaritsch 
To: "'nanog@nanog.org'" 
Subject: Prefix-Hijack by AS7514

Hi,

does anyone else see some prefix hijacks from AS7514? They started to announce 
some of our /24 


Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Re: ISP in NYC

[Jared Geiger]

HE uses Telia for Transit. So you won't gain much redundancy there. I would
go with Cogent if you have lots of European customers and North American
business customers. One not on your list is Level3. They would be strong in
that blend too.

You might also try joining a peering point. You'll gain a lot by just
peering with the route servers.

On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender  wrote:

> Hi,
>
> We are looking to peer with another ISP in NY. My options are:
> Telia
> Tata
> Cogent
>
> We currently have (and will keep):
> HE
> NTT
> TELX (They use NTT and HE and we are looking to replace them).
>
> We need an ISP that has a good peering/connectivity in Europe and Asia
> (Israel specific).
>
> Any advice on who to go with?
>